a metaphor referring to the eventual consequences of any system design, software architecture or software development within a codebase.
When I first heard this metaphor, I liked it immediately. Being ignorant of the official definition, I thought the metaphor referred to an issue I recognized as plaguing many companies: the cost a company pays for not investing in quality Software Engineers, and for not encouraging and enabling existing Software Engineers to keep up to date and stay passionate.
My interpreted definition of Technical Debt (which in discovering is incorrect, might better be described as Software Engineering debt) points to a far worse problem, affecting and putting at risk not only a single project, but the entire company and people’s entire careers.
So what exactly should you do to invest in quality Software Engineers? We could start by describing what we should be avoiding. Unskilled, unprofessional, lazy, indifferent, obsolete, egotistical. These are the characteristics in Software Engineers you should be avoiding. Low quality Software Engineers create low quality Software, which is very expensive.
How should a company avoid this mistake of falling in to this version of Technical debt, or maybe known as Software Engineering debt? Easy. By investing in your hiring process to acquire quality Software Engineers, and by motivating and training your existing Software Engineers.
Won’t that be more expensive though? Up-front, absolutely! But the return of investment is significant. In fact, this seems so obvious, it is surprising companies consistently make incorrect decisions by hiring low quality Software Engineers.
Ask any experienced Software Engineer how much more efficient they are compared to when they started, and you will likely hear about the leaps and bounds of improvement they have made. I myself recall year after year the latest next techniques I had learned, how much better I was now because of them, and ponder about how I could have managed without them. For example, before I learned about TDD and Unit Testing, I used to create main functions in all my java classes so I could debug and step through the code in Eclipse and make sure it was working as intended.
For years, I have been driven only by my natural tendency for over-achievement, though often against the odds due to traditional conceptions of the role of Software Engineers.
Imagine then a company that actively encourages and supports the improvement of a Software Engineer. Imagine how techniques such as continuous integration and proper testing could improve the efficiency of a Software Engineer, helping to eliminate expensive bugs, and vastly speeding up removing those that do make it to production. Imagine including the client on a constant basis in the direction of the Software, ensuring the proper Software is created. Now scale this to a team of Software Engineers, and you will improve tremendously your possibilities of success.
Sounds great. So lets hire Senior Software Engineers. First, make sure these ‘senior software engineers’ are actually quality Software Engineers, and not just lazy, unpassionate Software Engineers who have been around a long time.
This isn’t the end of the story though. Once you hire quality Software Engineers, you need to create an environment where they can continue to grow. This is because the field is constantly changing and evolving. New languages and technologies are released nearly weekly. Once I joined a company that created an environment for me to grow by providing me with autonomy and purpose, I was able to truly focus my direction and start on a path to Software Craftsmanship.
Not staying up to date with these changes in the Software Engineering field will put Software Engineers and your company at a huge disadvantage to those companies who do take software seriously, likely resulting in lots of pain and your eventual failure.
There must be thousands of examples of software that failed due to to Software Engineering debt, unknown because of their failure. Likewise are hundreds of companies that had risen but failed due to Software Engineering debt (MySpace, ADP). I believe my definition of Technical Debt and lack of investment in passionate Software Craftsman is the true cause of the incredible failure rate of software projects.
So avoid my interpretation of Technical Debt, aka Software Engineering debt; please invest in your Software Engineers. Even better, invest in Software Craftsman.
I look forward to your comments.