Managing Negative Development

In software development, there is little analytics on this while there are hundreds of open source and other tools which can provide fancy dashboards and stats around anything – from the time required for processing a build in the CI - CD pipeline to the processor power required to run a java script function in a mobile browser. But often we miss out monitoring the true cost and waste in the software development process – Cost of Quality

One of the principles is around LEAN development . A developer who creates a complex function when the same processing can be achieved by much simpler (read a few lines of code) makes impact on two counts. First is the time spent on completing the feature, which in most cases can be anything from few hours to a couple of days. The second impact is the cascading effect of any defect arising out of the complex code that requires other developers more time to read, understand and correct the implementation later. The situation is worse when standard coding practices are not followed. Combined these factors take up a significant portion of overall effort in the development life cycle.

In Agile development, there are ways to handle this.  Second one is simpler to solve - The fundamental principle of tagging and tracing makes it possible to identify the exact portion of code that has unwanted complexity, deviations from coding & security standards and integrating this with a proper defect tracking tool allows to trace the time spent on refactoring and fixing this portion at any stage of development and deployment (even from production). This also allows to have a view on who are the negative developers who eats up time of others and pulls back the progress of a product delivery and adoption.

To address the first, we may need to have a slightly more disruptive approach. One of the suggested method is to adopt Pair Programming.

• Do pair programming pragmatically. 60% of features are simple and references are available in developer resources on web and most developers are comfortable cross checking the implementation and making the right design approaches. It is a waste if resources are paring on simple tasks as technically it cost the double. In developing complex features, this reduces to approximately 15% additional cost, but the benefits of better quality, knowledge and skill development across team, developer satisfaction etc far outweigh this marginal increase in cost.
• Do catch up for full stack of code in the 60% slice, similar to peer review but with on the fly enhancements and refinements for the tasks developed by individual developers.
• Generally, pair a great programmer with a learning programmer. Depending on the task sometimes it may need two experienced developers or two junior developers to pair. Let the choice be made by the team.
• Do your sanity checks periodically. There can be always things that are missed out. Do the dashboard checks to cover broader areas. If Chief engineers review code most of their time, they are not focusing on what they are expected to do – Create designs that are efficient and solves the business need in hand. The developers are to be empowered to do the review.
• Avoid back seat mentality especially when experienced developers are pairing with junior people.  Ideally provide both with keyboards and there are technologies that allow this. Though Navigator mode works in some areas, it may not be required in all cases.
• Celebrate Success. When pairs achieve breakthrough, or develop innovative ways of handling logic, have a 10 minute stand up and share the insights with other team members. This will go a long way in motivating and effective skill sharing that others can adopt in tasks that will come up in future.