Opinion: Inability to hire is an underestimated aspect of technical debt and old tooling

Opinion: Inability to hire is an underestimated aspect of technical debt and old tooling

Most developers and analysts today are fairly aware of the impacts of technical debt. As technical debt grows, it takes longer and longer to get real customer or end-user work done. Worse, more and more time is spent triaging and squashing bugs. And one interesting aspect of technical debt is old tooling.

Old Tooling

I’ve written before about modern not being a synonym for better, but there comes a point where you need to modernise your tooling, even if it seems to be doing the job.

For me, the most tell-tale sign is when the author of the tools has apparently moved on from being interested in the tool. No matter how good a tool was, it needs to keep moving forward as requirements and operating environments evolve.

I deal a lot with Microsoft applications, and I often see these signs:

  • People from the development team seem to have moved on to new jobs
  • No-one is posting blog posts about what’s happening
  • The tool stops turning up on conference sessions, Channel 9 videos, Azure Fridays, etc.
  • The flow of new features slows to a trickle or stops

If you ask the company, the tool is still supported and not going anywhere, but given the interest has moved on, you probably should too. I can only imagine that there’s a desire to avoid upsetting anyone who’s made a commitment to using the tool.

Many people refer to this type of tool as abandonware.

There are times though, when sudden spurts of life appear. A classic example is the work that was done on SQL Server Reporting Services in the 2016 edition. (I’ll write more about SSRS another day)

Finding Staff

What I really wanted to mention today though is another nearly-hidden downside of using old tools, as a form of technical debt. And that’s your ability to find staff. You do not want to underestimate the impact of this.

Today, I was reading about a large company in Europe with untold millions of lines of classic ASP code, embedded with VB. They can’t work out how to move forward now.

I feel for them. I’ve done work with customers where their entire code base was in VB.NET and ASP.NET WebForms. At least that was a step up from classic ASP. They had many hundreds of developers. Even if you’re a stalwart who loved the tooling, you need to stop and as yourself where you are going to find staff who’ll share that love.

Developers who desperately need an income (and thus a job), and are living from pay to pay, might work for you. But developers who have any options at all, aren’t likely to do that.

You’ll find it harder and harder to locate good people who want to work for you. You’ll end up paying them much, much more than would otherwise be appropriate, and you’ll end up lowering your standards for whom you’re prepared to employ.

From the point of view of a prospective staff member, do you really want to have your resume showing you starting with that code today?

[caption id=“attachment_6279” align=“alignnone” width=“520”] Awesome image by Pepi Stojanovsky[/caption]

And if you really are willing to do any coding for the pay, why not learn COBOL and cash in? It won’t take that long to learn, and there’s still plenty of work around for those wanting to write it.

2020-02-04