[HN Gopher] High-Quality Software Engineering (2007)
___________________________________________________________________
High-Quality Software Engineering (2007)
Author : rhim
Score : 41 points
Date : 2024-05-15 05:39 UTC (1 days ago)
(HTM) web link (www.lurklurk.org)
(TXT) w3m dump (www.lurklurk.org)
| tkiolp4 wrote:
| 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?")
| bcrosby95 wrote:
| > 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.
| datadrivenangel wrote:
| 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!
| drewcoo wrote:
| 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 . . .
| pictur wrote:
| 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.
| ChrisMarshallNY wrote:
| 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.
| abraae wrote:
| 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.
| MarlinTheWiz wrote:
| It doesn't help that most of the career advice out there now
| is to move to a new role every 2 years if you want to get
| underpaid. Developers don't have the opportunities (or don't
| give it to themselves) to see how well what they build stands
| against the test of time.
| chrisweekly wrote:
| "move to a new role every 2 years if you want to get
| underpaid"
|
| missing "don't"
| didgetmaster wrote:
| '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.
| bee_rider wrote:
| Dogfooding is good, but I wonder to what extent it has become
| the case that problems that programmers have (solved by
| software that programmers will use and can easily evaluate how
| it works) are already solved pretty well by open source
| programs. I mean, imagine trying to sell a compiler. Good luck.
|
| If you want to sell software, maybe one of the biggest markets
| to play in is software that programmers don't find interesting
| to write and use?
|
| There's clearly not a 100% overlap between problems that
| programmers find interesting and open source projects. But it
| is applying not so favorable filter, right?
| baetylus wrote:
| Another underappreciated effect of dogfooding may be its
| reduction in bloated functionality.
|
| If you're not dogfooding, you rely harder on a mental user
| model. Just conjecturing -- not only does that model diverge
| across your organization, but it could result in more top-down
| decisions about what a user wants, which probably creates more
| politics and friction all around your teams.
| w10-1 wrote:
| 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
|
| - ...
___________________________________________________________________
(page generated 2024-05-16 23:01 UTC)