Technical Debt is More Than Bad Architecture

Technical debt. In a world where technology is becoming exponentially more important every day, technical debt sounds really bad. What exactly does it mean though?
According to Wikipedia, technical debt is:
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.

Oh my!

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.

One thought on “Technical Debt is More Than Bad Architecture

  1. “it is surprising companies consistently make incorrect decisions by hiring low quality Software Engineers”

    A huge (maybe the biggest) part of the problem, that you don’t mention, is how hard it is to hire high quality software engineers. It’s not like going to the grocery store, where smart companies will pick from the “High Quality” aisle. The world is full of fast-talkers, resume padders, and people who can answer every interview question about a programming language without being able to write any code.

    Getting them to show their skills on the whiteboard can help, but you immediately cut your pool (maybe in half?) by eliminating a huge number of engineers with high levels of anxiety who can’t think on the spot but might be amazing in a seat. And learning that a person can code tells you nothing about whether the person works well with others, is open to criticism, is too lazy to write tests and properly comment except in interviews, etc.

    I think the best thing a company could do is be quick to fire engineers who aren’t a good fit. Be up-front with them at hiring time that there’s going to be some kind of trial period, during which they’ll be full employees with benefits and full salaries, and at the end of which there will be a decision regarding their continued employment. Be fair with people you decide to let go, give them a generous severance (this was your mistake, not theirs), and move on.

Leave a Reply

Your email address will not be published. Required fields are marked *