Responding to “Are bugs and slow delivery ok?”

Some people hear it and think it means highly-structured abstraction towers vs low-structure imperative-heavy code. Some think about horrible spaghetti with 16 levels of indentation and 1-letter variable names (moving on to 2-letter once you exhaust the first 26) and if-statements whose predicates span twelve lines. Some people think about feature completeness and bugginess (or, rather, lack thereof).

I think they're dangerous over different time horizons and you can't just prioritize over all time horizons.

Spaghetti is dangerous in the short-term - it makes small changes difficult and unsafe. You'll end up tied by your own shoestrings and not even finish the project. Luckily if this is the only problem, it's also the easiest to clean up. (But it's not usually the only problem).

Less-structured code is good for when you don't understand your requirements well. (Which you typically never will a-priori, even if you think you do). It's easier to add more layers of abstraction than it is to change or remove them. If you prematurely build an abstraction tower, you will suddenly find yourself having to plumb information up and down the entire tower as the abstractions prove to leak or not be completely perpendicular to the kinds of features you need to add. But if you wait too long, you have too much unstructured code to refactor and you're now "chasing" people adding new features to the system while you try to refactor the system underneath them. So there's just some engineering gut-sense that's important to know when to stop and codify the patterns you've seen emerge into a useful, tight abstraction.

And then of course there's features and bugginess. It's possible for the shittiest code to have very few bugs and please users. The worst thing about the worst code I've ever seen in my career is that it worked - so it was hard to want to mess with it when it was so easy to ignore! And it doesn't help that what is intractable code to some people is only a little complicated to others. Especially if you use a big language and are combining a lot of esoteric/complex features, or have a complicated logical expression and you are a logician and others are not.

I've seen projects become unchangeable because the code was spaghetti. I've seen them become unchangeable because there was too much abstraction. I've seen them become unchangeable because there was too little abstraction. I've seen awful code make big impact and I've seen excellent code flop because it wasn't competitive with "worse" but more complete offerings.

(All of this reinforcing, of course, that it's impossible to estimate how long software will take..... all of it relies far too heavily on the intuition of your mid+senior engineering talent).

Agile, for example, suggests that decreasing the cost of change at the expense of certainty of cost will increase the total chances of delivery within cost and date. Outsources are (implicitly) arguing that the decrease of total costs are worth the other friction in the organization.

This all goes back to return on investment. In the most simplistic case, if I have ten people working on this task now, and this software will allow me to reduce that to six, then that's four people I don't have to pay for that task. If those four people are making $100,000 a year, and the software lasts 10 years before having to be replaced, that's 4 million dollars. The software plus maintenance needs to cost less than 4 million dollars to make sense. We all know the simplistic case.

But if I can trade $100,000 dollars in guaranteed cost for a reduction of $500,000 in risk in making that goal, I can trade cost for certainty and that's going to be a good trade. Now, as developers we know that these numbers are often fudged, but everyone realizes this is inexact and just the best we all can do. We need to know how to think about these in terms of arguing against bad investments and steer toward good investments by knowing how the tradeoffs works.

Bugs are inevitable, but that doesn't make them OK.

But that's not the point the article is making. They're talking about whether or not bugs and slow delivery will break a company. Obviously it won't, because both have been a part of what the industry releases since the start.

Although when it comes to software that market is quite heavily skewed by the VC funding effect. If "the market" is getting something free or cheap as a loss leader because it's really the VC money that is paying the bills for a few years then end users are going to be much more tolerant of junk for a while.

In the VC model it's boom or bust so quality and coding for the long term might not be business priorities. In the short term unless you're so bad that it's outweighing the sales and marketing push to drive that rapid growth you can get away with a lot. In the long term you don't care so much about maintaining the early code because by the time a big exit is a realistic outcome you have the resources to throw things out and rebuild from the ground up if you need to.

Of course none of that means you're actually providing a good experience to your users during those early years or that they'd be willing to pay enough for what you're offering or stay with you for long enough to sustain and grow your business independently. You're still shipping junk and your users still don't like it. You just don't care because your bills are really being paid by someone whose interests barely align with your users in those early years and the bill payer also doesn't care because they're only interested in the big exits and expecting to write off all their other investments anyway.

If you're a software developer who does want to build good products and have happy users benefitting from them then this kind of market is toxic. If you're a user who just wants good software to do its job so you can get on with yours then this kind of market is toxic. Eventually maybe the potentially paying customers will get wise to the startup game and start avoiding it in favour of alternatives made by smaller companies that bootstrap and aim to build steady and sustainable products and businesses. But there's been so much money splashing around in VC world for so long now that a lot of people just can't think outside the box.