“The wise speak only of what they know.”
They say hindsight is 20/20, you always know what the right approach could have been in retrospect. That is where the value of experience comes in. In our capstone project we are learning a lot of valuable lessons, ones that have probably been learned many times over by professionals already in the industry. The most important lesson learned recently is planning for program intersections. Or, figuring out how everything talks to each other.
We are young professionals. We have an academic understanding of how to implement frontend frameworks and RESTful APIs. So we were excited to work with them. How the restful API will work was a good portion of conversation, coupled with what technology we were going to use on the front end. What we didn’t pay as much attention to was how these two pieces were going to talk, where they intersected. Which is arguably, the most important part of it all.
There are endless ways to correctly program a RESTful server (endless wrong ones too). There are a million plus ways to design a front end application correctly. But if attention isn’t being paid to how they communicate with each other, or the structure of the program intersections. Then you can end up with two programs that are supposed to be part of a whole, but are not working together.
When I talk about the program intersections, I mean the structure of the GET/POST requests. Are you using JSON, if so what is the structure? What work is being done in what part of the program? The way the applications communicate in this space directly impacts how they are both built. If it is not talked about ahead of time, then chances are someone is going to have to redo their work. Different assumptions made by different team members can be a dangerous thing!
Luckily in our group we caught this early on. It became very obvious once we saw it, so it didn’t pose a major problem. Still, it gave us all something to think about for our future projects. We chatted for a bit about what would have happened had we not caught this early on. What is the worst case scenario when two halves of a project show up for deployment and they aren’t even speaking the same language.
Even writing about this blog post, this feels like it should have been more obvious than it was. But that is the nature of things. You spend so much time thinking about how you are going to spend your time building the part you are responsible for, that you don’t think about how it will correlate with the parts of your team members. Software development in a team is a collaborative process, and if you lock yourself away and focus on your responsibilities, chances are you are missing part of the full picture you are working on.
