Software Development under Duress
In early 2020 when most of the world was under Covid quarantine, a colleague and I were remotely interviewing a candidate for a Software Architect position. We discussed software development, and this individual expressed that it is acceptable to give up software discipline in the face of tight deadlines.
“Here comes the war analogy.”, texted my colleague. My colleague was one of the most experienced interviewers in the company. Sure enough, in the next 30 seconds, the candidate explained his position with a war analogy. His perception was doctors, soldiers, and other controlled professions give up many protocols during a war. So apparently, it is acceptable for software development teams to give up quality standards when under duress.
Inaccurate perceptions
Is it true that doctors give up protocols during a war? On the contrary, the medical profession undertakes determined efforts to evolve treatment methods during and after the war. Many of our modern medical methods are innovations from the battlefield. A small list of such innovations are tourniquets, treatments for antibiotic-resistant infections, vascular repair surgery, antibiotics, and reconstructive surgery. Not just in medicine, the list of inventions from just WW1 is long and surprising. Adversity brings out the best in all living beings — this is the basis of evolution.
So, why do people accept that giving up discipline is acceptable for software teams when facing adversity?
Discipline considered optional
The notion of professionalism in software development is still evolving. Books such as ‘The Clean Coder’ and the ‘Pragmatic Programmer’ explore this theme. When developers do not practice discipline as part of their training, their chances of following it are close to zero when they are under duress. This response is the opposite in the military, sports, and medicine — under pressure, they fall back to their training.
Feature pressure
Businesses are under pressure to deliver customer delight. As a result, they face trade-off decisions over introducing new features versus making existing ones better. Typically, a business is more attentive to new features than invisible attributes such as availability, resiliency, or maintainability. So, developers struggle with the same decisions and the urgent wins over the important.
Deadlines over outcomes
A startup does not need discipline because they don’t know what the customer will like if anything at all. If some features need to be dropped in the future, all that discipline will add to the wasted effort. Also, there is deadline pressure, so we have no time for discipline.
This strategy is out of place because it tries to save pennies in an endeavor that aims to make dollars. A better one would be to plan for the product to get some initial traction and have investors eager for more. You don’t want to keep customers waiting while developers “harden” the product — do you?
Let’s look at some questions to develop a “minimum viable discipline” for a team.
Do we need to write code now?
Code is a liability because maintenance is more expensive than the first release. A startup that is unsure of features that will appeal to customers is probably better off not writing code until it has a better idea of its target audience. Prototyping is essential to short circuit the build-measure-learn cycle to multiple learn-measure cycles.
Do all parts of our codebase need to be clean?
All software systems have some parts that provide unique business value, while others support these parts. Some features typically go through more churn as compared to others. These are the parts of the codebase that need more discipline than the others. An effort to keep these parts of the system easy to change, reliable, and available is more likely to meet enthusiastic business approval.
Do we need all those features at the same time?
If a team with six developers needs to deliver six features by a specific date, would you have each developer start work on each feature in parallel? How about swarming on two features at a time? This would allow the team to focus on code quality and deploy the features to production earlier in the release schedule. The overall timeline would be the same, but the small batches give the team more chances to learn and ensure that the final release results from successive deployments instead of a big-bang effort.
Are we improving our daily work?
Increasing discipline at work should be an incremental exercise. Found a bug? Write a unit test to replicate the bug, watch it fail, change the code to make it pass, and refactor. Then, try TDD or BDD for the next feature. Then, modify the Definition of Done to include code running in production or a production-like environment.
Summing-up
We need to get over our stereotypes and misperceptions. Software development teams have a professional duty to maintain a minimum level of discipline while building and delivering products.