11–20 of 100 posts
When software is created without a profit motive, then it is to coolness of the idea that motivates the creators. Focusing on quality would only slow down the "creative" process.
I working in consulting, and in a lot of cases while we're well intentioned in delivering quality software, we're forced to fight against clients in time, budget, scope creep etc. Sadly, things sometimes get rushed out the door and it's not until some time has passed that they realise the enormous tech debt they've incurred.
Software is not made by grownups. And for the most part the development is not managed by grownups. The problem is that so many can get away with childish behaviour.
But this is certainly not the majority.
Basically it comes down to management that is willing and able to tell a client no, or convince the client to budget to do things right, and not management like my current company, which has in the past threatened to disallow even unit test writing and code review as slowing the process down too much.
"Code quality is time and money you're saving your future self" is an argument that only makes sense to people who write code, apparently, until you actually lose a client to avoidable problems.
When developers talk about "quality," they mean tech debt. Addressing tech debt is problematic for businesses because it's something that never ends. You allocate one month for tech debt and the devs will ask for two. Allocate two and they will ask for three. There is no agreed-upon standard at which devs will stop and say, "Now our code is clean."
Add to this the fact that there are many developers who just always seem to have an agenda about the code they're working on. They never work a project except they're dying to add some pattern or change some aspect of the code, even if it's something that they used to favor a year ago.
Software development is, apart from a few rare outposts like GOV.UK, conducted in the private sector for a profit. That means that the number one consideration for the software is profitability. For internal-only software, this means that cost is the prime consideration. In support of that, often software startups are trying to capture a winner-takes-all market, so time-to-market is critical. Thirdly, consumer protec…
* Defect rate (does it do what it's meant to do?)
* Does it do what the user wants? (not always the same as the above...)
* Is it pleasant and efficient to use (definitely not the same as either of the above).
* Is it developed in a way the management are comfortable with? (which often seems to lean towards sufficiently "under control", replaceable developers).
How do you balance these? The answer will be quite different depending on whether you're landing on Mars or writing a free-to-play game.