I don’t know. If I have learned something in the last decade about software engineering and quality is: business only care about revenue and speed, while engineers don’t have an objective way to define quality (10 engineers would give you 10 different opinions about the same piece of code).
The only moment I consider quality as the top priority is when I work on side projects (because there’s only one opinion about what quality means, because there’s no time pressure and because no one is asking me “are we profitable now?”)
'Eating your own dog food' is the best path to quality software in my opinion. Too many people working for a software company (developers, salespeople, product managers, etc.) never bother to use the software to do the kinds of things they expect their customers to use it for on a regular basis. Write the code. Make sure it passes some tests. Move on to the next project. This is common.
No wonder so many bugs never get reported unless many customers run into it much later. I have a project I work on regularly. I use it regularly to do productive things and I find most of the bugs just doing that. I had a couple different 'business partners' who talked a good game, but I could not get them to actually use the software and give me feedback on how to improve it. Neither one added much value to it and quickly moved on to other things.
This is really baseline software development.
What's missing are the fault models with the solutions from 15 years ago:
- how to keep code review from becoming a politicized bottleneck
- deploying continuously to avoid train schedules
- comprehensive security, for both code and process
- ...
> For example the telephone system and the Internet are both fundamentally grounded on software developed using a waterfall methodology
Is this true? I can’t speak for telco, but I thought the internet in particular was developed incrementally with a lot of experimentation. I mean, yes, the experimentation resulted in RFPs and STDs. But I thought these generally came after the software was working. And as someone who has implemented a few RFPs, I would not say my approach was remotely waterfall.
Indeed my perhaps incorrect version of events is that the waterfall approach is represented by the big loser in telco, the ISO OSI.
> Here’s a little-known secret: most six-nines reliability software projects are developed using a waterfall methodology.
I've designed and deployed Tier 1 services for a Big Tech company, and here's is a little-known secret: when nothing changes, our reliability is higher than six-nines.
Last year I measured our uptime during Black Friday for fun. Our error rate was measured in scientific notation because the number was so small. We didn't do any deployments or changes during that period.
When you operate in a steady state it's easy to achieve zero errors, and most downtime comes from random failures in hardware, i.e. servers crashing or network blips (which, operating at scale, are relatively common).
So my and other's personal experience is that most outages are due to changes in the software, dependency outages, or the rare large scale event that completely kills your SLA (e.g. a whole AWS region is down). Taming these is at the essence of reliable software.
Whoever tells you that the best software is made using waterwall methodologies from a fixed and never changing set of specifications, lives in a fantasyland alien to the vast majority of developers.
I was explaining this to a friend who's a top-shelf cabinetmaker.
He was telling me how he would sell high-quality cabinets to homeowners, basically by building a "dream kitchen," that far exceeds their budget, then backing down, by removing features, until they have something that exceeds their original budget, but would still be quite good, and that they want.
He was saying that I should use his methodology.
I explained that his sales are to the people that would actually use the cabinets, so they have a vested interest in high quality.
In my case, I would be working for a business that absolutely doesn't care about quality. They want the cheapest, shittiest garbage they can possibly get away with pushing. They don't use it, and many of them won't even be responsible for supporting it, afterwards, so there's no incentive for quality.
The same goes for corporations that don't try to retain talent. If someone is only going to be around for eighteen months, they are paid well, and they are pressured to produce a lot of "stuff," then you can expect them to produce a lot of ... stuff. They don't give a damn about supporting it, because they are already practicing LeetCode for their next gig.
I have found that giving people a vested interest in Quality is essential. That often comes from being responsible for taking care of it, after it is released, using it themselves, or having their reputation staked on it.
I don't feel the current tech industry meets any of these bars.
Most of the software I write, is stuff that I use, and I am intimately involved with the users of my work. I want it to be good, because I see them, several times a week. Also, I have a fairly high personal bar, that I won't compromise. I have to feel good about my work, and that doesn't seem to sell.