We must ship now and deal with consequences

Aaron about 1 hour later:

• • Question: Suppose a DP decision has been made, such as your FitNesse HTML frames, at what point do you pay the interest? Is it preferred to address the design issue immediately after the release so the next release does not suffer from the issue, or is it better to wait until the next story to address fixing the issue?

  • It seems in your example that being proactive would have been a loss, especially since there has not been demand to fix the issue. Leaving poorly designed code in the system rubs the wrong way, but seems like better way. Additionally by waiting the correct design may appear from another area of development which would be reusable to correct the design issue.

Uncle Bob about 2 hours later:

• • • Aaron about 1 hour later:

    • Question: Suppose a DP decision has been made, such as your FitNesse HTML frames, at what point do you pay the interest?

  • The good thing about the Frames solution was that there is almost no interest to pay. The code for this feature is way off to the side, and would be trivial to remove. So the interest cost is virtually zero.

  • When interest is higher (i.e. you can feel the impediment of the suboptimal design every day that you write code) then it is really important to reduce either the interest or the principle as rapidly as you can. You reduce the interest by decoupling from the suboptimal design. You pay down the interest by improving the suboptimal design.

R Hayes about 9 hours later:

• • Deliberate Prudent debt is not nearly so rare as you think. If you are chasing a large opportunity with a short half-life, it is imprudent not to accept this debt. If you’re not ready to make hay when the sun is shining, you’re not going to make hay at all.

  • An excellent example of deliberate technical debt in the real world is Formula One racing. Those cars are a combination of the world’s best technology … and duct tape. If the car has a problem that causes a part to wear out every third race, who cares? The engine gets overhauled more often than that. The car has to finish the race 95% of the time. More than that is probably costing you races.

  • An example in the programming world is statistical arbitrage algorithms. The framework they sit in may be perfectly engineered, but the implementations of the algorithms rarely are. That additional time is money lost. Worse yet, most of the opportunities they chase evaporate as soon as other people start imitating the strategy.

Keith Nicholas about 10 hours later:

• • “Writing bad code never increases your net worth;”

  • this is wrong.

  • I’ve seen people launch businesses based on their bad code! through the will to get something working they make their code do what they want.

  • I think the relationship between code quality and net worth is pretty complex.

  • for instance, anyone who has worked with a mathematician or scientist who have crafted a piece of code to solve a hard problem, often its a mess, but it solves the problem. Money in the bank. It doesn’t mean you can’t improve it, and that there aren’t consequences to having messy / bad code.

  • You can certainly make the statement for a number of common cases that many people are involved with, but “never” is too strong.

Jaap Beetstra about 10 hours later:

• • Daniel: I would say Technical Foreclosure is when you lose to the competition due to inability to deliver quality features on-time.

  • R Hayes: I don’t think F1 racing is an example of technical debt. Part of the specification is: A part must last 1 race or more. If a part wears out every third race, that is acceptable. If the part fails in 33% of the races, it is completely unacceptable. Failure must be predictable in F1.

skyivben about 13 hours later:

• • Agile Principles, Patterns, and Practices in C# Chapter 6: A Programming Episode

  • Game.cs refactoring:

  • // Game.cs —-—-—-—-—-—-—-—-—-—-—-——

  • public class Game { Scorer scorer = new Scorer(); }

  • public int Score { get { return ScoreForFrame(10); } }

  • public void Add(int pins) {   scorer.AddThrow(pins); }

  • public int ScoreForFrame(int theFrame) {   return scorer.ScoreForFrame(theFrame); }

MikeT about 14 hours later:

• • Also, the left hand tree at fitnesse.org doesn’t show up in Google Chrome.

Jon B about 14 hours later:

• • • You can certainly make the statement for a number of common cases that many people are involved with, but “never” is too strong.

  • To me there are two reasons why its worth saying never even if never is too strong.

  • The problem with not saying never is that it’s virtually impossible to distinguish between bad code thats benign and bad code thats eating away your net worth until the problem has gotten out of control.

  • The other reason is that when something inevitably does go wrong there’s a greater space where there could be a problem. If i have lingering doubts about part of my code i’m going to have to spend some time sifting through the chaff to make a decision on whether its the bad code going malignant or if it’s something external. The bad code acts as a fog, making the problem harder to find simply by its presence.

  • There was a statement I got from an agile diary that was posted on Ron Jeffries’ XP Mag. “To me NO quality means that I cannot guarantee a working application”. If you start accepting bad code you’re not moving down a couple of steps on the quality ladder, you’re saying “I no longer have control” and letting go of the wheel.

  • So while you may believe ‘Never’ is too strong, it’s more valuable to cultivate an instinct of never than attempting to identify which cases are the exceptions. The smallest benefit of which is that the more experienced at clean code you get the easier it becomes.

Uncle Bob about 18 hours later:

• • • R Hayes about 9 hours later:

    • Deliberate Prudent debt is not nearly so rare as you think.

  • I know it’s not rare. I wish it was rarer.

    • If you are chasing a large opportunity with a short half-life, it is imprudent not to accept this debt.

  • That’s a false dichotomy. It suggests that debt is the only way to go fast. Generally, technical debt is a good recipe for going slow, even in the short term. There are exceptions; but you have to be very careful about them.

    • If you’re not ready to make hay when the sun is shining, you’re not going to make hay at all.

  • By all means make hay while the Sun shines. But cut that hay to nice even lengths, bale it up nice and tight and square, and stack those bales evenly. Otherwise it’ll all fall apart before you get it to market. You can’t make hay by making a mess.

Uncle Bob about 19 hours later:

• • • Keith Nicholas about 10 hours later:

    • “Writing bad code never increases your net worth;”

    • this is wrong.

    • I’ve seen people launch businesses based on their bad code! through the will to get something working they make their code do what they want.

  • I’ve seen that too. I’ve also seen some of those businesses stagger, crash, and burn because they could not manage the founder’s code.

  • Again, it is a false dichotomy to suggest that it is faster to write messy code. In fact it’s faster to write clean code.

    • for instance, anyone who has worked with a mathematician or scientist who have crafted a piece of code to solve a hard problem, often its a mess, but it solves the problem. Money in the bank. It doesn’t mean you can’t improve it, and that there aren’t consequences to having messy / bad code.

  • There is a difference between code written carefully by an inexperienced programmer (e.g. your scientists), and code written carelessly by someone in a rush. The first may have some deficits in terms of coding style; but it is not likely to become the seed of a disaster. The second, if pervasive enough, will cause unpredictable crashes, and inadvertent breakage, that will slow the development asymptotically to zero.

    • You can certainly make the statement for a number of common cases that many people are involved with, but “never” is too strong.

  • I disagree. Bad code, code written carelessly, never increases you net worth.

Torbjörn Kalin about 20 hours later:

• • Uncle Bob: I wouldn’t call your Frames solution technical debt. It’s just a different way to solve the problem. After all, ten years ago frames was as cool as you could get. Just because a cooler technology has now entered the scene doesn’t make the old technology become a debt.

  • Technical debt for me doesn’t have to do with what technology you use. It has to do with how you use it.

  • Also, I would say the difference between reckless and prudent deliberate debt is that, if you have a plan to deal with the debt it’s prudent, otherwise it’s reckless. That is, it’s (sort of) ok to create a mess before the Friday deadline if you clean it up on Monday morning.

  • Apart from that, a very good post!

Jon B about 20 hours later:

• • After thinking about the original Martin Fowler article, I get the feeling that Martin would completely agree with you Uncle Bob.

  • Specifically “A mess is a reckless debt”, no prevarication or wiggle room there. If there’s a code smell then it’s a reckless debt. The only thing left to talk about is was it unintentional (in which case, it’s a learning experience) or deliberate (i’ll leave the consequences as an exercise to the reader).

  • To me the prudent debt axis talks more about sub-optimal design decisions.

  • To borrow an example from “Agile Software Development” (p103-108), We’ve got good clean code to draw shapes regardless of type. While waiting near the water cooler for the build server to give the code the all clear, coder 1 turns to his pair and says “You know we’d probably be better off with a data-driven table based approach. We know we’ve got that ‘draw all circles before squares’ story later in the pipeline. why don’t we just implement that now.” to which coder 2 says “YAGNI. We’ll do that when we come to it”.

  • Is this a debt? I’d certainly argue that it is, even if it’s probably not valuable to present to the customer in that way. We’re borrowing against future work to maintain the simplicity of the system (or alternatively to defer a decision until the last responsible moment). This is what i’d categorise as a deliberate/prudent debt. Deliberately accepting a less than optimal but still viable(i.e. no code smells) system design.

  • The interesting question to me is then “Is it better to maintain this kind of debt or spend the time to eradicate it immediately”?

Luca Minudel 5 days later:

• • > Bad code is always imprudent.

  • When we as developers write bad code, is not because it is faster ann we are late. This is just a lie we tell to ourself. In reality it is because we are not able to wrirte better code!

  • Writing good code do not require more time, it just require more skills.

  • That’s the point. Plain simple.