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.
The venue of the conference was the New York Hilton Midtown Hotel and my 50-minute session took place in the Regent Palor. There were several other sessions holding at the same time so I was really appreciative of those that chose to attend mine.I started the session by asking how many people in the audience currently use or had previously used the waterfall approach to building software. I also sought to know how many had transitioned from waterfall to agile methods. A third of the attendees indicated that they still use the waterfall method to build software and around half of the attendees indicated that they use agile methods, I guess the rest use a mixture of the two.Like I mentioned earlier, part of the talk was about two mobile apps we built for the Nigeria elections. We had a MySQL database for storing data and on top of that we built a REST API which exposed several functionalities. Both the API and database were hosted on the Google Cloud Platform. Another part of the talk was about how we used the agile approach to build software.Given that software development is more of a social activity than a scientific one (in my opinion) adopting agile was not that easy. First there was the issue of convincing management to allow the team to go this way, secondly there was the challenge of getting the team members to take a whole new approach to building things. Thirdly, I had to lead and make all this happen and trust me when I say convincing management and leading a team through virgin ways was not easy at all.Management along with a lot of people out there take agile methods to be a chaotic cowboy approach to building software but there is a method to this madness. I think people’s resistance to agile goes far beyond the common reasons given such as; chaos, cowboy coding, no documentation and so on. Yes, the real reason for resistance has a lot to do with change… culture change… corporate culture change. The waterfall method (which I believe a lot of software development companies in Nigeria use) has an underlying corporate culture beneath it which agile totally shatters to pieces (look out for posts on this) therefore it is very hard for a company to switch its culture just like that (I said very hard, not impossible).Luckily I had certain things in play for me. One was that the election app project was not undertaken with the goal of making money. Another thing I had to my advantage was that my manager wasn’t really concerned about the project so in the end I was able to get a go ahead to try this “wild way” of building software.Since software development is a social activity and humans have different ways of reacting to change it was not easy for my team members to flow with the agile approach. It was a bit rough in the beginning but after a couple of weeks the benefits were clear. Some of the benefits I elaborated on in my talk are as follows:
- Agile improves team morale. I say this because the team members were happy seeing people try out their app (with only one feature) within 2 weeks of commencing development and with that energy they were keen on fixing bugs and getting the app to run smoothly.
- Because we built the application in vertical slices as opposed to technology layers, everyone in the team had an idea about what each person was doing and therefore we were able to change things and features swiftly.
- Improved health. The first two points created an atmosphere where the team members were able to function under less stress. The whole application was broken into bits and for the bits we weren’t clear about we didn’t even need to think about them initially. The team did not resent change because it was easier to identify areas that needed change as opposed to our previous way of doing things.
Attendees were able to relate to a whole lot of what I had to share and they asked a lot of questions about the software development ecosystem in Nigeria.
In the end I don’t think one method of building software is superior to another, it depends on your specific situation and your overall understanding of the method. Also, it takes more than just switching from one method to another you may need to switch your corporate culture too.