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

31–40 of 43 posts

Re: High-Quality Software Engineering (2007)

#31

Post by routerl »

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…

> Write the code. Make sure it passes some tests. Move on to the next project.

Let's mention the missing step: don't even bother to run the code.

I'm simply embarrassed to admit how often I've been in teams that not only "don't use the software" (i.e. no dogfooding) but even "don't run the program". It's embarrassing. These types of teams miss bugs that get shipped because not one of the people involved in making that software has ever even actually run the damn app, let alone actually used it for any length of time.

This is shameful and embarrassing. Our profession is a joke. How can we even call ourselves professionals?

Re: High-Quality Software Engineering (2007)

#32

Post by routerl »

userbinator wrote: post #30
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 was popularised by Microsoft, which AFAIK is still doing it, but it seems these days it's more like they're just being force-fed the dogfood without having any actual power to change it.

One of the main problems with Facebook's metaverse was precisely that none of the developers working on it actually wanted to use it, to the point where it had to be mandated by management.

Like, guys, when even the people who are making your product don't want to use it, this counts as data about how successful the product will be. If you have to force paid employees to use the product, then you'd have to pay users to use it too: there's no profit margin here, there's no user base.

Re: High-Quality Software Engineering (2007)

#33

Post by ambicapter »

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…

Seems like building and selling your own software (aka solopreneur) would help you to build capital at the same time as it also forces you to write good code.

Re: High-Quality Software Engineering (2007)

#34

Post by eschneider »

eBombzor wrote: post #26
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…

Sounds obvious in theory but the majority of applications are targeted for a very specific audience, i.e. banking, freight forwarding, CRM even. Not to mention if you work at a mid+ size company you'll be working on a piece of the application. Good luck trying to use that in your day to day life.

If you're writing software to automate a business process, you're well advised to spend some time learning how to do the job you're automating so you some idea if what you're making is shit or not.

Re: High-Quality Software Engineering (2007)

#35

Post by recursivecaveat »

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…

It's maybe no coincidence that some of the biggest companies that actually sell software (as opposed to user data) that I can think of are Epic, Salesforce, and Intuit. Imagine spending your evenings on volunteer work for a CRM system, bleh.

Re: High-Quality Software Engineering (2007)

#36

Post by theonething »

tkiolp4 wrote: post #2

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

> 10 engineers would give you 10 different opinions about the same piece of code

This plays out in code review in a way that drives me insane. So much back and forth and time spent/wasted because there's always that one person or small group of people who insist their way is the one true one.

Re: High-Quality Software Engineering (2007)

#37

Post by euroderf »

eschneider wrote: post #34
eBombzor wrote: post #26

Earlier quoted context omitted.

Sounds obvious in theory but the majority of applications are targeted for a very specific audience, i.e. banking, freight forwarding, CRM even. Not to mention if you work at a mid+ size company you'll be working on a piece of the application. Good luck trying to use that in your day to day life.

If you're writing software to automate a business process, you're well advised to spend some time learning how to do the job you're automating so you some idea if what you're making is shit or not.

Or you could just write ERP software, secure in the knowledge that the customer organisation will be bent to conform to the ERP model.

Re: High-Quality Software Engineering (2007)

#38

Post by ChrisMarshallNY »

ambicapter wrote: post #33
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…

Seems like building and selling your own software (aka solopreneur) would help you to build capital at the same time as it also forces you to write good code.

Yes. That’s pretty much what I do. There are a couple of issues with this, though:

1) It’s difficult to do this, unless you already have a lot of experience, writing good code.

2) There’s a ceiling to what we can do, as individuals. I have heard tales of Linus, The Miracle Coder, who can write an entire operating system, as well as an industry-changing VCS, on his own; but I only know of one cranky Finn that seems to fit that description. Otherwise, most of us mortals need to work in teams, to achieve ambitious goals, and that brings its own set of challenges.

Re: High-Quality Software Engineering (2007)

#39

Post by lloydatkinson »

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…

How did he react? I imagine he was horrified.

Re: High-Quality Software Engineering (2007)

#40

Post by lloydatkinson »

routerl wrote: post #31
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…

> Write the code. Make sure it passes some tests. Move on to the next project. Let's mention the missing step: don't even bother to run the code . I'm simply embarrassed to admit how often I've been in teams that not only "don't use the software" (i.e. no dogfooding) but even "don't run the program". It's embarrassing. These types of teams miss bugs that get shipped because not one of the people involved in making th…

I agree with this so much. Only yesterday someone picked a ticket off the backlog to change a minor detail on a feature I've been working on. Rather than getting me to do it (a ten second job) this person made the change and also made unrelated changes. Now the user may proceed to the next step and bypass all the validation errors in fields they forgot to put values in.

If they'd ran it, they'd have seen how broken it is. But they didn't run it, and just merged the branch.

Post reply on HN