Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

High-Quality Software Engineering (2007)

lurklurk.org

Post reply on HN
Print view View original

11–20 of 43 posts

Re: High-Quality Software Engineering (2007)

#11

Post by didgetmaster »

'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.

Re: High-Quality Software Engineering (2007)

#12

Post by w10-1 »

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

- ...

Re: High-Quality Software Engineering (2007)

#13

Post by MarlinTheWiz »

beachy wrote: post #10
ChrisMarshallNY wrote: post #7

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 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…

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.

Re: High-Quality Software Engineering (2007)

#14

Post by bee_rider »

didgetmaster wrote: post #11

'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 g…

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?

Re: High-Quality Software Engineering (2007)

#15

Post by chrisweekly »

MarlinTheWiz wrote: post #13
beachy wrote: post #10

Earlier quoted context omitted.

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…

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.

"move to a new role every 2 years if you want to get underpaid"

missing "don't"

Re: High-Quality Software Engineering (2007)

#16

Post by baetylus »

didgetmaster wrote: post #11

'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 g…

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.

Re: High-Quality Software Engineering (2007)

#17

Post by [deleted] »

bee_rider wrote: post #14
didgetmaster wrote: post #11

'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 g…

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 inter…

[deleted]

Re: High-Quality Software Engineering (2007)

#18

Post by roncesvalles »

ChrisMarshallNY wrote: post #7

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 expl…

Devs leave in 18 months because their market value increases faster than their pay at their current company.

You can give devs a vested interest in their work by making sure compensation tracks/exceeds what they can get outside, because it would give them a vested interest in remaining employed with the company.

Re: High-Quality Software Engineering (2007)

#19

Post by roncesvalles »

w10-1 wrote: post #12

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 - ...

I Cmd+F'd "mono" and got no hits. Then I exited the page.
Post reply on HN