back to article A developer always pays their technical debts – oh, every penny... but never a groat more

Picture the scene: you're a developer looking at someone else's code for the first time, and you can see that a lot needs changing. Performance bugs mean it won't scale for much longer. The code design makes it difficult to port to another language, which is going to cripple that Latin American business expansion. Its …

Anonymous Coward

CEOs are fed up with their jobs being at risk because some programmer screwed something up

Meanwhile, in the real world, programmers are fed up with their jobs being at risk because the CEO ... screwed the company | decides to cut costs | outsources them.

47
0

Re: CEOs are fed up with their jobs being at risk because some programmer screwed something up

But the point is that is it always someone's else fault

18
0
Silver badge

Re: CEOs are fed up with their jobs being at risk because some programmer screwed something up

Well that strategy worked well for Trump

3
3
Bronze badge

Re: CEOs are fed up with their jobs being at risk because some programmer screwed something up

Really? Just how many CEOs have been fired for reasons that could be traced to such a thing? I've never heard of it. Heck, you need to be an Experian-level ****-up to get fired at all. And anyone want to put odds on whether or not the programmers had been screaming bloody murder about problems for months or years before this went done?

7
1
Anonymous Coward

Re: CEOs are fed up with their jobs being at risk because some programmer screwed something up

It's much easier to identify a good developer than it is a good manager. We can quantify features delivered and reliability of code, but measuring the effectiveness of business decisions, that are mostly implemented by other people, is tricky.

Finding a competent team of management to work for is tricky. I found one about 15 years ago and stayed with them for 10 years. As in all areas of business, if you can find competent people you can trust to work with then stick with them!

2
0
Silver badge
Mushroom

Re: CEOs are fed up with their jobs being at risk because some programmer screwed something up

This aspect of the article goes on to say, "The liability issue makes technical debt a governance issue. "CEO jobs are on the line for something that they don't even begin to understand," Curtis points out."

Perhaps if CEOs spent a bit more time understanding how their fucking company achieves the things they bill customers for and less time on the golf course they would better appreciate what their Devs (and other employees) are up against. To moan about a CEO being blamed for something they don't understand and not holding the CEO at least mostly responsible for not understanding it in the first place is absolute bollocks.

I'm not saying a CEO in a business with many disciplines should be a crack kernel coder (nor VHDL author or whatever) but they should at least appreciate what coding involves and how Dev work their magic to write software. Only then will a CEO understand why cutting this corner or outsourcing that team causes pain far beyond saving a few beans.

At the end of the day the CEO is ultimately responsible for what happens (or not) in a company. If you, as CEO, can't explain why the merde hit the fan then it serves you right and don't let the door hit you on the arse as you leave.

0
0
Silver badge

Critical job and payment

So they do recognize that they have quasi random ppl building the critical parts of the company.. yet fail to grasp that tight control should be applied.

And worse still... the payment still goes to eh PHBs, not the architects of the company..

We obsiously have a huge disconnect.

11
0

This post has been deleted by its author

Silver badge

If it was hard to write, it should be hard to understand!

> he points out that a developer's familiarity with the code, rather than the code itself, would affect the level of technical debt based on that measurement.

The greatest amount of technical "debt" is the lack of documentation. Whether that is a complete lack of it or - often worse - stuff that is out of date but looks right. At least when you have nothing, you won't follow the assumptions implicit in what was written down. And documentation isn't just about explaining what the code does, or what the author thinks it does. It isn't even about what the designer hopes it will do.

It is also about preserving the thought process of why certain design / code / implementation decisions were made. Sometimes some unbelievably bad ( or obscure - frequently the two are indistinguishable ) hacks come about due to limitations that were discovered during development, but that nobody thought to record for posterity. And as well as describing the method that works it would be kinda handy to know what other approaches were tried and rejected.

21
0

Re: If it was hard to write, it should be hard to understand!

Nice idea but who's going to pay for all that documentation?

(not talking about comments, talking about a full description and record)

On many projects it will need to be continually updated.

Over the long run, let's say 5 years, while that cost should be justified, it does load that cost to the front of the project.

3
6
Silver badge

Re: If it was hard to write, it should be hard to understand!

"And as well as describing the method that works it would be kinda handy to know what other approaches were tried and rejected."

Probably from Dr Dobbs or the like, the rubric went something like this:

Apprentices' comments say what the code does.

Journeymens' comments say why it does it this way.

Masters' comments say why it doesn't do it some other way.

6
0
Silver badge

Re: If it was hard to write, it should be hard to understand!

"Nice idea but who's going to pay for all that documentation?"

As ever, the correct question is "who's going to pay for not having it?".

9
0
Silver badge

Re: If it was hard to write, it should be hard to understand!

> Over the long run, let's say 5 years, while that cost should be justified, it does load that cost to the front of the project.

True, but if the cost was front-end loaded, maybe we would only get software projects that were actually worthwhile?

Whether that would be a good thing - for whom: the programmers or their employers - is part of the never-ending debate

1
0
Bronze badge

Re: If it was hard to write, it should be hard to understand!

This thread seems to only accidentally touch a critical issue: documentation of code itself generally is technical debt. Allow me to explain.

One of the basic rules of XP is "Don't repeat yourself." This is a central tenant of maintainability. The code itself is already a communication. According to Knuth, successive programmers should be the primary targets of this communication. Documentation outside the code source is a second communication. This is why in much of the ruby community, documentation is considered a code smell. "If you need to explain it, you need to simplify it."

The Apprentice/Journeyman/Master distinctions matter. Documenting the business case that lead to a particular implementation is a very different matter. Doing this can help later programmers understand when things really have changed.

Of course, for real-time code, or for the implementation of complex algorithms, the balance changes. But even then, the correct solution is likely to be pointers to timing analysis work and or algorithmic descriptions.

0
0
Silver badge

Re: If it was hard to write, it should be hard to understand!

We use to run projects based on the "Rule of Two":-

Write code be twice as easy to understand than the team is capable of producing. Never put two or more expressions in the same line. Never write a function that addresses two or more business rules. Always write at least two lines of documentation for every function (Or, even every line of code). Always wait for at least version two of the tools that you are going to use to put software into a production environment. Stop writing code at two o'clock in the afternoon, then use the next two hours to check it (Then, if necessary, have a meeting about it - Which will be short because everyone wants to go home/down the pub).

2
0
Anonymous Coward

Re: If it was hard to write, it should be hard to understand!

"Nice idea but who's going to pay for all that documentation?"

The same people who've commissioned the software, since to any real dev, documentation is part of the product being built. I am currently working in a place where documentation is avoided - our documentation system has been down for a month and nobody (but me) cares.

"Over the long run, let's say 5 years, while that cost should be justified, it does load that cost to the front of the project."

Yes, if the person requesting the software doesn't understand that, then explain the article to them : If we do not incur this cost now, you'll incur double the cost later plus delays on any enhancements you request while we figure out what wasn't documented in the first place. Your choice, please sign here (so I can shove it in your face when you're moaning to my management about the delays to the enhancements you need 6 months from now).

4
0
Silver badge
Coat

Re: If it was hard to write, it should be hard to understand!

"One of the basic rules of XP is "Don't repeat yourself." This is a central tenant of maintainability."

Sorry, I think the word you are looking for is 'tenet'. I only point this out because another tenet of maintainability is clarity of communication.

going now...

7
0
Anonymous Coward

the ruby community, documentation is considered a code smell

How incredibly convenient for them

5
0
Silver badge

Re: If it was hard to write, it should be hard to understand!

Not the person who did not write it.. or mostly not that person.

Yo can also write useles documentation that passes al the requirements...and keeps the less skilled person in the team with a job (albeit a thankless one)

0
0
Pint

Re: the ruby community, documentation is considered a code smell

How convenient, indeed. Job Security. This whole thing about "The interest is the ongoing IT cost that those flaws are generating." is what Job Security is all about.

Well-written code with well-written documentation leads to ... wait for it ... Programming jobs becoming redundant. I've done that to myself, so I should know.

2
0
Bronze badge

Re: If it was hard to write, it should be hard to understand!

Ouch. Well and truly done, sir.

0
0
Bronze badge

Re: the ruby community, documentation is considered a code smell

Taken out of context, you can reverse meanings! Most excellent job, sir.

Now, let me say it again:

The work of simplifying code is _hard_. It requires effort and discipline. It much easier to write an explanation somewhere (and call it documentation). But... the low road is not the road to long-term success.

If your code needs an explanation, then what it really needs is to be simplified.

The above line precisely matches the pattern of "code smell".

If you disagree with the claim "simplifying code to the point that it does not require an explanation is better for code health than explaining complicated code", I would very much like to see why.

0
1

Re: If it was hard to write, it should be hard to understand!

Living this ‘dream’ now as we speak!

0
0
Silver badge

One way to avoid technical debt: experience

Essentially most things developers do in the real world are utterly trivial. There rarely is an actual challenge. That's why developers often get bored and try to solve the trivial probems in more and more complicated ways. A good example are web applications. The web was made for (quasi) static "pages" of "rich text" with hyperlinks. Somehow people now try to cram interactive applications into this. That way, things that could be done in Delphi via the built-in "create a database application" wizzard within seconds, now take months.

If you have experienced programmers, which have worked in different areas, you can reduce your technical debt. Just let them choose the propper tools for the job. Let them build prototypes so the users can already play with the product long before any details are set in stone.

9
3

Re: One way to avoid technical debt: experience

Let them Help the customer understand the importance of, and cost of, prototypes so the users can already play with the product long before any details are set in stone. FTFY

Sadly customers, especially start-ups, consider every penny spend on code as one more step on the path to glory. Diversions and dead ends don't exist because they think they cannot afford them.

2
0
Silver badge

Re: One way to avoid technical debt: experience

Well I don't think it's even possible to do decent software development in an outsouced environment. Software development without knowing in depth what the software has to do and what it's all about is utterly fruitless.

5
0

Our challenge is determining and tracking opportunity cost

I like the separation of cost into principle and interest but I think that is still missing another cost that needs to be taken into account.

Most often we need to decide how much time we invest in adding or extending the functional or non functional capability of the software.

This often boils down to where we make the change and we talk about stretching what we have to just achieve what is needed now vs significantly changing an element that will allow it to go further than is currently demanded much more easily.

In order to be worth the conversation the rebuilding cost (almost always time) needs to be markedly higher than what is needed for the stretch significantly delaying other things the team are being asked to do. Here we face two different costs, the certainty of any cost that the delay will cause vs the possible (but almost always eventually realised) cost of having to do what we could have done in the first place in order to deliver that further capability.

I am tempted to call it opportunity cost but no doubt someone else will have a better name and take on this problem.

0
0
Bronze badge

if it works

One measure of technical debt is unittest coverage and closeness to full ci cd.

However bad code is, if it works its ok until you need to change it. If it has full unittests and can be trivialy deployed. It can be changed. Therefor its debt can be paid off.

Just a metric. But test coverage + cd readiness is imho a good one.

1
4
Silver badge

Re: if it works

I would say it differently: Working unit tests means everything is fine, if you will never need to change it. If you know you will need to change the code, but you don't understand how the code currently works, then you have a problem, and working unit tests are not going to help you.

7
0

Re: if it works

"Working unit tests means everything is fine"

Working unit tests means everything that you have thought to test is fine, which is a low bar I would want to put any weight on.

13
1
Silver badge

Re: if it works

He called it a measure, not a silver bullet to fix all debt. And on that basis I think his point is strong. Quite strong.

The sorts of organisations* that don't value unit testing** are highly correlated with the organisations that are too focused on the here and now to allocate time to resolving this technical debt.

It's understandable at one level because resolving technical debt is expensive. The only thing more expensive is to not resolve it and then attempt a fix/improvement. But don't expect the business to recognise that the week spent on fixing some deficiency here has saved them two weeks on other projects over the following 6 months.

*I speak of organisations because individual developers within those organisations may well be pushing the proverbial uphill trying to get the business onboard, but if they can't be convinced of the benefits of unit testing then they are likely to see any attempt at technical debt reduction as developers taking liberties with valuable company time.

** By value, I don't mean platitudes about their merits. I mean actually invest time into doing it, as well as investing in some sort of ci that runs them on every commit, as well as actually being prepared to rewrite code so badly coupled that unit testing is nigh impossible, as well as actually using the facts about whether an individual developer is consistently decreasing coverage as a KPI at their performance reviews.

0
1
Devil

CEO jobs are on the line...

The liability issue makes technical debt a governance issue. "CEO jobs are on the line for something that they don't even begin to understand," Curtis points out.

Perhaps the board should begin to accept that the board should not be full of people who don't understand the company?

17
0

Re: CEO jobs are on the line...

Perhaps the board should begin to accept that the board should not be full of people who don't understand the company

I'm getting old now. When I started in the business, called "Data Processing" then, there was an effort to get someone with DP knowledge on the Board. I believe this was reasonably successful. Unfortunately they have all now retired and have been replaced with accountants, bankers or other non-technical bods.

12
0
Silver badge
Devil

It needs fixing – badly.

And often, if you need it done fast, and cheaply, that's what it gets: fixed, badly.

18
0
Anonymous Coward

Most of my technical debt is in code I wrote back when I first started working here and was a very inexperienced programmer. At the time I had my name on the contributor lists for a couple open source projects, just enough to prove that I did know the basics despite being self taught. 15 years and an actual CS degree later I occasionally go to update a really old project from early on and shudder at some of the naive choices I made back then.

For the record, I've stayed where I am mostly because getting a higher paying job would involve moving. There just aren't any jobs in the area for programmers - which was probably a factor in me getting this job before I had a degree - and there are half a dozen reasons I don't want to move.

Anon for, I think, obvious reasons.

10
0
Silver badge

If you don't think your early work can be improved

Then you have learned nothing.

It's a good sign when you think code you wrote a decade ago was pretty awful.

If nothing else, there's been a lot of basic algorithm research, and huge changes in the languages themselves.

3
0
Anonymous Coward

Technical Debt - Arrrrgggghhhh

One Project Manager I had the misfortune to work for on a supposedly Agile project (sic) called anthing that was identified as 'Technical Debt' as the 'Won't Fix List'.

There never was any time to go back and look at the Technical Debt before we were onto the next sprint and piling on more TD almost every day.

In the end productivity ground to a halt because of a whole raft of reasons most of which were languising on the 'Won't Fix List'.

It came back to bite the PM as he was let go (he was a contractor) and was replaced by someone who at least understood a bit about software development. In the end it was all moot as the company was taken over before the system went live and all development was shipped to India. They invented their own solution that never worked but that is another story.

Glad that I'm out of the SW Dev biz. There is no future in it in the UK.

9
1
Silver badge
Meh

Pragmatic Decisions

There is code I wrote that has been working apparently correctly for years, but looking at it now I'm frankly horrified by it. Were modifications now needed and I was to work on this again, to do the job 'properly' would require a major re-write. However, if I apply patches with extreme caution, and very very thoroughly test everything, it is likely to carry on working - apparently correctly - for many more years.

I haven't (yet) had to make such a decision.

1
0
Silver badge

Another Area of TD

One area of TD that is overlooked is when the requirements change significantly but some of the old code is still needed. You might really need to rewrite the code completely.

Another area of TD is when the system does not allow the easy solution and any working solution is nasty kludge at best.

Not all TD is due to poor programming or shaky specs.

1
0

You need good programmers, and you need to let them work

In many cases, this debt can come from decisions that require code to be out immediately. Sometimes, that's actually required for the situation, but in other situations the two days now will save two weeks later. However, in my experience this can result in a cycle of project managers messing things up, as they assume that, since working code was shipped successfully, the new features can be pushed along the same way. For an example, consider the recent MacOS releases. I think many of us can agree that 10.13 High Sierra has problems. Some of it works fine, but there have been a lot of bugs, including one that in my case cyclically bricks my laptop for a few days. That seems to be a firmware problem with their new disk format and my old machine. Even if that's just a me thing, we all remember the root password bug. These problems seem to happen rather frequently now that apple is making their developers push out a new big version every year or so, and I think the debt of this is the cause. Remember how nice 10.11 was? That was the version in which they didn't try to add as many features as they could think of, and instead focused on reliability and performance. In other words, paying down debt. A solution that does 90% of the job and crashes 0.1% of the time is better than one that does 95% of the job and crashes 10% of the time. If companies could realize that, we would have better code.

6
0

Grammar please

;A developer always pays their technical debts...' How on earth can anyone expect any respect when their grammar is so dreadful. Illiteracy is the bane of modern journalism. It should read 'Developers always pay their technical debts'. Unbelievable.

0
7
Gold badge

Re: Grammar please

There is nothing ungrammatical about the original. "their" is a third person singular possessive pronoun.

On this subject, I was reading the biography of Helen Keller the other day (as you do) which was written roughly a century ago and I was struck by the consistent use of "him" and "his" to refer to a child when the passages, though couched in general terms, were clearly talking about Helen's childhood and Helen's teacher's particular approach to educating her. Certainly in my part of the world, such usage is now almost laughable.

3
0
Anonymous Coward

Re: Grammar please

Not to mention that it's clearly a reference to phrase "A Lannister always pays their debts" from the Song of Ice and Fire novels. Ya doofus.

1
0
Bronze badge
Paris Hilton

All words and no numbers.

The national debt of the United States of America currently stands at 21 T$. How much is their national Technical Debt? Is it included in the former figure? How much technical debt is due to Microsoft Windows? The Intel x86_64 processors? How do I calculate the technical debt of my project?

3
1
Bronze badge

It's not just experience.

Experience and skill are not strongly substitutable. The guy that's been on the project for decades might be garbage as a programmer.

A potential employer brought me in for a three day working interview. The project? Implement a script to initialize new ruby projects with a one-liner. Set up the github project, hook it to jenkins, bring in & flesh out the skeleton files.

What did I do? I implemented a platform for project initialization and a ruby module. I was hired, and over the next twenty months, we received regular requests to extend the capabilities. Java project? No problem. Scala? np. Two git repos? np. Two jenkins jobs? np. I never had to touch the core code.

The skill involved in doing that was not just programming. It certainly was not captured by tests, nor by documentation. It involved understanding that the business problem that was being addressed was only hinted at by the ticket--and architecting the code to address the business problem first.

0
2
Bronze badge

Lack of tests is not techinical debt

Look at the definition of technical debt in the article. Technical debt is about architectural and design decisions which have become outdated.

Violating fundamental principles of programming is not technical debt. It is like building a building on a foundation where the concrete has too much sand. Whomever selected that mix is going to get sued and maybe prosecuted.

Mixing data and code is not technical debt. It is programming malpractice. Promoting untested code--unless it is the only way to stop an issue which is actively being exploited by hostile actors--is not technical debt. It is programming fraud.

And if you give time estimates to program managers that do not include the time required to adequately understand the ticket and test the code, you are part of the problem. If they argue that you are taking to long, you can explain to them that the bad condition of the code is the culprit.

5
0

Re: Lack of tests is not techinical debt

I was once sacked, as a contractor, when I was "taking too long" with a job someone had estimated would take 2 days. On reading the requirements I realised that this was in fact an enterprise application integration job no one had realised at the time of the estimate, and would probably take 6 months or more. Even giving an estimate would have required at least a week's investigation of unstructured T-SQL code running into 10s of thousands of lines of code containing undocumented business rules.

5
0
Silver badge

Bah!

So, no-one writes specs any more?

Maybe that's the problem right there.

2
0

Re: Bah!

Oh yes they still write specs! Just so long as it fits on a piece of a 13.5 x 8.0 cm post it note.

0
0
Anonymous Coward

All code is written by offshore idiots to the lowest price

This shitty code is in your medical devices, cars, industrial systems, phones and most devices in your homes. It's present on every website you visit.

Insecure by negligence and stupidity, it's everywhere in your life.

But hey - psychopaths are running the companies that make this stuff & they don't give a shit. They are cutting cost to get paid. You are not the 1% so fuck you.

10
0

Page:

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Forums

Biting the hand that feeds IT © 1998–2018