Words of Wisdom
“The concept of technical debt is central to understanding the forces that weigh upon systems, for it often explains where, how, and why a system is stressed. In cities, repairs on infrastructure are often delayed and incremental changes are made rather than bold ones. So, it is again in software-intensive systems. Users suffer the consequences of capricious complexity, delayed improvements, and insufficient incremental change; the developers who evolve such systems suffer the slings and arrows of never being able to write quality code because they are always trying to catch up.” – GRADY BOOCH
Introspection
We are as software developers crushed in ever-shortening deadlines, ever-widening software method/patterns, ever-changing requirements leading to unmanageable complexity, and even all the while, the quality of the software needs to be a gold standard.
How do we deliver prime software in the shortest span?
That seems to be the million-dollar question for the modern technology world. I remember working for a company who had a 4-month strict deadline to deliver moderately complex software which is manageable, maintainable and what not. This challenge is what this post is going to deal with.
Mantra
AGILE(incremental) + REQUIREMENTS(substance/order) + CODE REVIEW(meticulous) + REFACTOR(bold) + Quality Assurance (manual or/and TDD).
First Things First: Requirement
I am not saying Agile can land you in the moon but it introduced the idea of incremental working software and altering the course of projects and products on the fly. Agile methodology can manage the flux of complex unpredictable curveball that the market throws at you to a certain extent. Why? Requirements are mostly the culprit for the unmanageable poor software design. The more one could control, manage and communicate the requirements, and to a certain extent predict, we are in a safe spot. Devoted backlog grooming/refinement sessions with Product Owner is more like Design Thinking sessions (Ideating and brain-storming). This rigor in the ritual can and should ideally to a large extent capture your problem areas and solution space with insight into the unknown domain. This way one is prepared ahead of time.
Next comes the code review sessions. There is a ton of literature on the internet why code review by well-trained eye can capture more than 60% of your bugs [1]. I have seen companies who care for even the utmost seemingly inconsequential naming convention or variable name and others going to another end by being a stickler to missing commas and semicolons.
Next comes the Refactoring sessions. One could opt for group refactoring like pairing with experts or one could also do it individually. Objectively seeking, refactoring is the art of behavior preserving transformation like Martin Fowler aptly describes [2]. The beauty about the refactoring is, seeking subjectively, you need to be bold or else go home. Why? I know refactoring starts with promoting a variable from local to a public or the other way but along with that, you should be ready to undertake bold transformations, like replacing a switch case with polymorphic interfaces [3]. Such redesigns need mettle and surely not for the weak.
CONCLUSION
I have worked in software production companies who don’t give importance to the methodologies but smugly content with the product, all the while quality of the product suffers. One thing I have gathered in my experience is its all connected world-when you care about a variable name, that reflects one’s commitment and gravity to something bigger than itself. What I have compiled above is not something new, it’s been out there, but the secret is, one bill doesn’t fit all. We need to adapt and that is one among the repertoire of a secret weapon in Agile.
References
[1] https://smartbear.com/learn/code-review/agile-code-review-process/
[2] https://martinfowler.com/tags/refactoring.html
[3] http://wiki.c2.com/?SwitchStatementsSmell
Predicting Change.
Design Nutcracker 