My father was proud of his military service. He believed that young men and women could learn a lot not only from having served in the armed forces, but from having actually experienced the stress that comes with "taking fire."
He was not one of those war mongering types who believed everybody should experience combat. He did say, though, that even navigating what is known as "the infiltration course" - the part of training where you crawl under barbed wire while live bullets fly over your head - is something that teaches you to stay calm when all hell is breaking loose around you.
Sounds like the kind of training that would help many development teams when dealing with technical debt.
The Agile Architect, Mark J. Balbes, pointed out in a recent post over on Application Development Trends some of the less obvious effects of technical debt.
He describes a well-oiled development team that falls apart after failing to practice several of the critical software disciplines needed to create high quality, agile software. At first, they didn’t realize the cause of the strife on their team, and then it appeared – technical debt.
Technical debt manifests itself in many ways. If you put off fixing bugs or pass on automated testing – it appears. If you delay refactoring code until after a release – there it is. And then what happens? Customers start calling you about bugs, development teams take longer to build new features because you didn’t refactor. That short-cut is now costing you big-time. And there is a development team cost, too. As the team works around problems, easy tasks become more complicated. When one developer slows down, he or she forces the others to slow down too. The team gets frustrated and harried...and then the finger pointing starts.
In The Agile Architect’s example, his team inherited code with no automated tests, no manual tests, no documentation, dead code, spaghetti code and bugs that were all undocumented. The team was asked to have all of this fixed in two months, so the team got to it. Two developers decoupled the code into three major sections. The team then wrapped some sections with automated tests and refactored. Other sections they completely rewrote. They fixed bugs as they found them. By attacking the problems in pieces, they were able to ship improved versions at any time.
Taking a “divide and conquer” approach created an interesting result. Over time, software that was buggy earned a lot of attention and testing, so that at the end, the only software not tested was the original code that the team knew was stable. While the result here was positive, the accumulated technical debt created a crisis that was unnecessary. The existence of technical debt isn’t necessarily a problem; not having a handle on the amount of debt and how to control it is. Not many organizations keep close tabs on their levels of technical debt, or if they do, they measure the wrong things, such as stable legacy systems.
Projects should start with developers creating a comprehensive plan that identifies the final expected operational requirements of the software. The plan should include the overall architecture, capabilities of the main components, scaling factors and interoperability standards. Provided it is factored in as the means to complete the project, an agile development approach can then be used to deliver rules, interfaces and functional outcomes. It’s often effective to complete work in a series of two-week “sprints”; an error in approach then lasts a maximum of two weeks and the team can “fail fast and recovery quickly.” Any rework that’s required is focused on two week’s of work, not an entire project.
Despite the best-laid plans, too much technical debt sometimes still manages to accrue, but forging a strong culture can help mitigate the negative effects of technical debt and keep a talented team together. Being honest about how agile the development process really can be and knowing there is top-level support for the project contributes greatly to building a strong culture, as do open communications and incentives to disclose technical debt when it appears.
Of course, the best approach to building a strong culture is to hire strong people. There is a steep learning curve in agile development and managers should expect a high failure rate - developers who really understand agile are few and far between.
Measuring and analyzing the quality and complexity of projects through automated solutions will also contribute greatly to reducing technical debt and should be incorporated into the planning and development process.
Strong people implementing well thought out processes and measuring and analyzing code throughout development while working in a positive, communicative culture have the best chance to succeed and are less likely to have to battle significant technical debt, let alone back down "under fire."