Responding to “Are bugs and slow delivery ok?”

The real problem is that management think they can directly constrain those kinds of variables but in reality they are not inputs they're outputs. The real inputs are things you can actually control like what you're building and which of your team you assign to build which parts of it at which times. That might come in on time and under budget or it might not but shortening a timeline or decreasing a budget won't change how long it takes or what it costs.

Of course that sucks for managers who want to make informed decisions like whether to go ahead with a project that will require an uncertain amount of investment to complete but needs to generate more return than some threshold to be worth doing. Now the managers have to find a way to guess what the important outputs like cost and timescales will be as some sort of probability curve so they can make a rational decision based on the best but still incomplete information they have available. And even then a lot of managers insist on trying to be absolute about things like time and money when the actionable decisions they need to make are more often whether to start some project at all or which ongoing projects currently have the greatest need for any additional resources that are available.

* software quality is (more) important

* software quality is not (very) important

* bugs are not important (aka "i don't test, but when I do, it's in production")

* the less bugs you have the better, but they're not gonna kill you

* bugs are safety-critical

* slow delivery is fine

* slow delivery is not fine

In the last 20 or so years working as software developer professionaly, in various teams and quite different projects, I've noticed that:

* people (decision makers, software buyers/clients) always say they want higher quality

* same people very rarely want to back that up with their budget

* people almost always prefer more features to more quality (even when explicitly told that more feature is not a good thing for eg. MVP stage of a startup)

* most people except dedicated QA engineers can only think of a happy path (if everything works the ideal way); this includes not only other engineers (who try to think up failure scenarios but often miss important ones), but also designers (when have you ever seen a design mockup for "DNS lookup failure connecting to the server" case?), and definitely product owners or clients (in context of a dev agency)

* I have never worked on a nontrivial software project that didn't change requirements/scope

Myself, as with many other software developers who chose this field out of passion and not stratospheric wages, was for a long time appalled by this apparent lax approach to quality? Don't you want to have the best possible product?

But working with a lot of diverse clients while doing dev agency work, and running several startups myself, has taught me that software quality is not, and (it pains me to write this) should not be, the top priority. Product-market fit, treating your customers well, having a sustainable monetization strategy, marketing and sales ... if you don't execute well on those, nobody will notice the (lack of) quality[0].

In most organizations (except the ones that are swimming in cash) it's a tough act to balance all of the above. While I wish for all the projects I work on to be the best they can be, a programming work of art if you will, I can certainly empathize for people who must prioritize otherwise.

[0] unless the quality is safety critical, in case I need to point this out explicitly.

There is no organization. There is only people. Some of those people, like your boss or your investors, may want you to burn yourself out or do unethical things to your customers so they can make more money. It's your prerogative to tell them to fuck off, and go work somewhere else if you don't get your way. Some people don't have that capacity. Software developers generally do.

Perverse organizational incentives will pressure you to be bad. Refuse.

Yes, that's the promise. I've seen it tried as earnestly as possible over the past 20 or so years since the term became popular, but I've never seen it deliver on its promises either. I suspect that a lot of that is psychological - risk-averse management hears "on time and on budget" and consciously or unconsciously starts steering the development process back to a more predictable seeming waterfall style that negates the supposed benefits of "agile" development.

I assert, however, based on 30 years of observation, that no matter how carefully you follow an agile delivery framework, whatever that may be, actual delivery and cost will have no relationship whatsoever on your estimated cost and date.

But I also predict that you and I will continue to smile and nod when they insist that it must be finished by such and such date.