All of us engineers / nerds 😉 have learned and studied a lot about Software Development Processes in our schools and colleges. Fresh out of the college, we are confident enough to believe that the processes detailed out in the books will make our life easy and allow us to develop better functional and non-buggy software. But guess what, practical cases are far away from such an outcome. Reason being people and at times tools. But mostly its people. I had seen a nice picture of how a customer narates the requirements and how it gets implemented. All because of simple miscommunication. And believe me, miscommunication happens a lot in the global world mainly because of ill-conceptualized ideas as well as thoughts on how a particular thing should work. In one of my projects, I had a very deep and emotional discussions with my project manager for the module designs. I wanted to implement asynchronous callback mechanisms making the UI independent & not waiting for the core to do the job/recover whereas my manager thought that should not be a problem since execution in core should take only a little time. He totally forgot that the core makes calls to system which might take time because of resource accesses. Anyways, he was stubborn enough to not listen to me. And in the final product we had UI freeze problems and we had to implement workarounds to get around those problems.

The basic problem as I said above is people and their concepts. For some people that I have met, Waterfall model is all they know of and all they think is working! And belive me, it is happening in one of the biggest company ever. For some people, iterative and incremental development is good but still in their mindset they follow the waterfall model by expecting deliveries at the end of the project or starting testing after beta deliveries. But any kind of approach is not without its problems. A manager has to balance the pros & cons and use a methodical approach towards software development. And this just doesn’t stop at manager level, it runs all the way down on the developer desk. I for example believe that it is a developer’s job to keep the source code in his branch/workspace updated by synchronizing his branch with the latest in the main branch. Now I know a lot of developers who do not do this because they fear that their code will break and they will end up fixing bugs in others code. Of course these fears are valid. But a stricter check-in policy can ensure that such occurrences are rare if any. Again enforcement of such a policy rests on all the people in the team.

I had quite an altercation with one of the project managers recently because of these issues. We now follow SCRUMM methodology in one of our projects and I am the product owner for that project. Based on the customer updates, I decided to give priority to functional features and performance enhancements and lower the documentation scope and rebase (synchronization with the parent branch of the networking stack). The reason for doing that was that my customer wanted to make sure that our product really works on the specification model that we have promised and there were no big enhancements in the networking stack so it was not a show stopper. So he would get deliveries but not as a big chunk but in smaller pieces instead. But the project manager had a schedule with alpha-beta deliveries where he wanted certain documents just because they were a part of the traditional delivery system. And that dude never understood why he cannot expect a big bunch of stuff at the end and instead settle for regular deliveries.

Do give me your views and experiences when such collisions on thought and implementation practices occur. I still believe that the process has to be implemented by the right people on the management ladder and allowed to flow down to individuals in a very systematic manner. I will write more about what I believe in the coming articles.