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

21–30 of 43 posts

Re: High-Quality Software Engineering (2007)

#21

Post by ChrisMarshallNY »

roncesvalles wrote: post #18
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.

This is true, but it is also only one axis. Once we have been at it for a while, respect, work-life balance, and job satisfaction are also very important variables.

I will bet that the top companies are able to provide all of these, and keep people, but I suspect that many companies have terrible managers that can’t keep a decent work environment going, so compensation is the only variable that matters.

The company I worked for, didn’t pay especially well, and I worked very hard to treat my employees well. It seemed to work. It wasn’t a case of greedy managers, making money off the backs of peons. None of us made that much, but the work was deeply satisfying. We worked with the top engineers and scientists in the world (in our field). Our business cards opened a lot of doors.

Re: High-Quality Software Engineering (2007)

#22

Post by pjm331 »

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.

was just having a chat about this in a recent 1:1

I've been at my current role for almost 7 years. Many of the best lessons I've learned have come from the pain of maintaining and fixing my own mistakes.

Sometimes it can take 2 years just to tell if a decision you made was good or not.

Re: High-Quality Software Engineering (2007)

#23

Post by betenoire »

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…

I agree, and take it a little further. 10 engineers couldn't agree on the _point_ of quality code to begin with, let alone define how to get there. Consider two programs:

1. The spaghetti mess, half-done abstractions, inconsistent uses of anything everwhere. But accomplishes the users expectations perfectly 2. A beautiful codebase, clean abstractions, tests and documentation everywhere. But the user hates it. It's slow, requires some domain knowledge of how to drive and get result.

Two very contrived examples, but not unrealistic examples.

Intuitively, better cabinet quality leads to a better cabinet experience. Does better code quality lead to a better product? It should, that's what quality is about. And if not, is "quality" even the right word?

Whenever I hear an engineer talk about quality, I clarify. What kinda of quality are we talking about?

Re: High-Quality Software Engineering (2007)

#24

Post by DavidPiper »

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…

An issue I've encountered is that all of those non-developer people you mentioned generally don't eat the dogfood, even if they push the idea of dogfooding themselves.

They assume (or don't even pause to think about it) that developers eating the dogfood is enough.

At larger companies, "eating your own dogfood" only works well if people with power to make roadmap and time-allocation decisions also eat it.

Re: High-Quality Software Engineering (2007)

#25

Post by DavidPiper »

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

Do you have any links, books or resources handy that you rate highly for those solutions?

Re: High-Quality Software Engineering (2007)

#26

Post by eBombzor »

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.

Re: High-Quality Software Engineering (2007)

#27

Post by ffitch »

betenoire wrote: post #23
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…

I agree, and take it a little further. 10 engineers couldn't agree on the _point_ of quality code to begin with, let alone define how to get there. Consider two programs: 1. The spaghetti mess, half-done abstractions, inconsistent uses of anything everwhere. But accomplishes the users expectations perfectly 2. A beautiful codebase, clean abstractions, tests and documentation everywhere. But the user hates it. It's sl…

good point. perhaps code quality and product quality are different things.

Re: High-Quality Software Engineering (2007)

#28

Post by betenoire »

ffitch wrote: post #27
betenoire wrote: post #23

Earlier quoted context omitted.

I agree, and take it a little further. 10 engineers couldn't agree on the _point_ of quality code to begin with, let alone define how to get there. Consider two programs: 1. The spaghetti mess, half-done abstractions, inconsistent uses of anything everwhere. But accomplishes the users expectations perfectly 2. A beautiful codebase, clean abstractions, tests and documentation everywhere. But the user hates it. It's sl…

good point. perhaps code quality and product quality are different things.

Right, and they are, that's my point. Quality isn't a single attribute of a system, it's a judgement call based on objectives.

The objectives of a business selling software, and that of engineers is something else. Sometimes maintenance, sometimes extensibility, sometimes exploration, sometimes just seeing if something is possible. Quality correlates to the objective, and in my experience, many software engineers have a hard time seeing their code through other perspectives.

Re: High-Quality Software Engineering (2007)

#29

Post by doctor_eval »

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

Re: High-Quality Software Engineering (2007)

#30

Post by userbinator »

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.
Post reply on HN