As an individual developer working on a personal project, you tend to have a very clear vision and understanding of what you’re working on but the moment another developer joins, everything changes. You are suddenly faced with the challenge of making sure that this new developer understands as much as you do and that they get the whole picture.
Clients that need software built always want to know how much it will cost them, and a lot of times (at least as we have experienced at Intellectual Apps) they want to have this information before work begins. In order to get a “realistic” estimate of how much it will cost to build the piece of software, agencies would elicit the requirements and then based on that come up with an estimate of the cost. Client has a cost for getting their software built while the agency is happy they got the project. Great!
The software developer’s brain works just like a computer, it has a RAM! When working on a product, the software developer has the product clearly in her RAM ranging from the tasks she has to do, the tasks other team members have to do to the general direction of the product.
Another thing that the developer has clearly in her mind is the structure of the code she is working on and all the little nifty bits and corners of the codebase. Something else which is true about the work a developer does is that things in the software development space change often, and in addition to that, this same developer may be involved with different teams and working on different products. She needs to always be in the “flow”.
This article is a summary of my presentation at the O’Reilly Software Architecture Conference in London.
Maintaining an API gateway these days generally involves handling different types of user facing apps such as a web, mobile (of different platforms) and IOT devices. The Backend for Frontend (BFF) pattern specifically addresses this aspect of software solutions.
At Intellectual Apps we build software solutions, and in creating solutions for our clients we frequently get to build web and mobile apps within a single solution. This often means that we have a single API gateway for all the apps to communicate through. Over numerous clients/projects/products we started to notice a lot of repetition in the modules we built into software solutions, so naturally we sort to find a way we could share functionality across solutions in an easy way and this lead us to start experimenting with microservices.
We need to build ABC, so that our client can do 123. Developers nod their head in confirmation that they understand what needs to be done. Been there before?
What usually follows is the lack of shared understanding between the team members, this means that everyone has their own idea of what ABC is and how it should get implemented. So being that the awesome development team understands what needs to be done, they go straight to implementation and after that all they’ll need to do is test the product and deliver to the client. Saving time right?
Every year is full of ups and downs and my 2016 was full of extremes. From traveling to places I had never been to before to picking up some habits I wish I had developed earlier. One of such habits is reading books and that is exactly what this post is about. Before now I hardly read books and even when I do it’s mainly for some technical reference or something similar. I read more books this year than any other year.
I was in New York on the 12th of April to deliver a talk at the O’Reilly software architecture conference on how my team and I built a report-casting mobile app for the 2015 Nigeria elections.On the surface, the talk was just about how we, as a team, built two mobile apps with a shared REST API running in the cloud. It was also about how we used an agile approach for the first time. In a real sense though, my talk was actually about how software development is inherently a social activity; the effect of corporate culture on software development (Conway’s law) and the pains associated with software development.
We had always wanted to build something relevant for elections in Nigeria and we had a lot of talk around this subject in 2011 when the last general elections in Nigeria were held but never did anything more than just talk about it. So when the 2015 elections were around the corner again, the talk came back but this time we were determined to get something done, anything!It all started with an excel sheet containing around 118,000 records, polling unit records from all across Nigeria. Since each polling unit record had a geographic coordinate, we were able to plot all the records on a map. Here is a map of Nigeria showing all the polling unit data (Google maps):