High-Quality Software Engineering (2007)
lurklurk.org
High-Quality Software Engineering (2007)
1–10 of 43 posts
Re: High-Quality Software Engineering (2007)
#2I 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?”)
Re: High-Quality Software Engineering (2007)
#3I 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 w…
> 10 engineers would give you 10 different opinions about the same piece of code
It's kinda like ice cream. You can argue if you prefer vanilla or chocolate, but everyone will agree when they're eating shit.
Now business takes this and runs with it: you can't even agree on if vanilla is better than chocolate, so go eat this pile of shit.
Re: High-Quality Software Engineering (2007)
#4I 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 w…
Different ideas are of course important. But companies that take every idea seriously usually have as many ridiculous problems as there are ideas. So not every idea may be really good. Accepting this liberates a person.
Re: High-Quality Software Engineering (2007)
#5I 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 w…
> 10 engineers would give you 10 different opinions about the same piece of code It's kinda like ice cream. You can argue if you prefer vanilla or chocolate, but everyone will agree when they're eating shit. Now business takes this and runs with it: you can't even agree on if vanilla is better than chocolate, so go eat this pile of shit.
You can't even agree on if vanilla is better than chocolate, so go find a way to let us sell this pile of shit to customers!
Re: High-Quality Software Engineering (2007)
#6I 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 w…
[flagged]
Re: High-Quality Software Engineering (2007)
#7I 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.
Re: High-Quality Software Engineering (2007)
#8I 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 w…
> 10 engineers would give you 10 different opinions about the same piece of code It's kinda like ice cream. You can argue if you prefer vanilla or chocolate, but everyone will agree when they're eating shit. Now business takes this and runs with it: you can't even agree on if vanilla is better than chocolate, so go eat this pile of shit.
Trying to get 10 people to agree which is the best chocolate ice cream is closer to the quality problem.
I appreciate the scatological approach, though. And most of the time when I hear the word "quality," it's said in anger that could easily be communicated by flinging poo . . .
Re: High-Quality Software Engineering (2007)
#9I 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 w…
[deleted]
Re: High-Quality Software Engineering (2007)
#10I 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 expl…
When I started at Oracle yonks ago, there was a bizarre bug management system.
When a bug was found, it was assigned to the next available developer in the team. It didn't matter who wrote the code and created the bug - there was no feedback to them unless they happened to be the one who picked up the bug report.
The bug reports were printed out and stood in a tall pile on a manager's desk.
Quality was, as one might imagine, terrible. Junior developers had no idea what a bad job they were doing - senior developers spent their days fixing stupid bugs they would never have caused themselves.
The solution, blindingly obvious, was to start assigning bugs to the developer who caused them. The improvement was instant, because most people actually want to do a good job, and to be seen doing a good job. The pile of bug reports literally shrank before people's eyes.
The current industry seems to have moved back to these bad old days but on a longer timescale.
Resume-driven development abounds. Developers move on to the next gig before the impact of their decisions becomes obvious and quality plummets accordingly.