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

Notes on Software Quality

anthonyhobday.com

Post reply on HN
Print view View original

11–20 of 82 posts

Re: Notes on Software Quality

#11

Post by pydry »

manoDev wrote: post #2

> Some people don’t care enough > > The more people you hire, the more likely you are to hire people who don’t care enough about good interface design. Good interface design needs to be valued by everyone who can affect the work. That includes developers, designers, product managers, and often the CEO. I know where you're going with this, but here's a twist: A CEO who cares about interface _design_ is path to microma…

>A CEO who cares about interface _design_ is path to micromanaging and pain.

That's how Apple blew up into a trillion dollar company.

Re: Notes on Software Quality

#12

Post by LoganDark »

chickensong wrote: post #10

I assume this is written by a UI designer or something, and it certainly feels like "notes" and not a cohesive article. Claiming "The six signals of quality in software" and then listing only user-facing concerns and including subjective items like "Beauty: Is the software as aesthetically pleasing as possible?" is questionable. I'm interested in quality, but I didn't find these notes enlightening, and couldn't even…

Yeah, when a software focuses on beauty I only have to wonder what they sacrificed to achieve it.

Re: Notes on Software Quality

#14

Post by Arainach »

pydry wrote: post #11
manoDev wrote: post #2

> Some people don’t care enough > > The more people you hire, the more likely you are to hire people who don’t care enough about good interface design. Good interface design needs to be valued by everyone who can affect the work. That includes developers, designers, product managers, and often the CEO. I know where you're going with this, but here's a twist: A CEO who cares about interface _design_ is path to microma…

>A CEO who cares about interface _design_ is path to micromanaging and pain. That's how Apple blew up into a trillion dollar company.

...while being a painful place to work at, so not really disproving the point.

Plenty of other CEOs have thought the secret to Apple's success was micromanaging like Steve Jobs and been proved very wrong.

The best CEOs hire people smarter than them (in their respective disciplines) rather than assuming they always know best.

Re: Notes on Software Quality

#15

Post by chrisweekly »

pydry wrote: post #11
manoDev wrote: post #2

> Some people don’t care enough > > The more people you hire, the more likely you are to hire people who don’t care enough about good interface design. Good interface design needs to be valued by everyone who can affect the work. That includes developers, designers, product managers, and often the CEO. I know where you're going with this, but here's a twist: A CEO who cares about interface _design_ is path to microma…

>A CEO who cares about interface _design_ is path to micromanaging and pain. That's how Apple blew up into a trillion dollar company.

Also how countless other companies didn't.

Re: Notes on Software Quality

#17

Post by amarant »

I disagree with the initial premise

>Quality is the absence of problems

A low quality code base can be problem free if surrounding circumstances are forgiving enough. Conversely, a high quality codebase can have a lot of problems in difficult circumstances.

I haven't thought about it long enough to have a definition of quality that I'm really happy with, but I think a "resilience to hardships" would be a better definition of quality. Hardships can come in many forms, and often you're prepared for some of them but not all. Occasionally you'll be prepared for hardships that never occur. There is something to be said for being resilient against the correct kinds of hardships, which is why I'm not entirely pleased with my definition either.

But absence of problems is not it. That might be entirely circumstantial and is therefore orthogonal to quality.

Re: Notes on Software Quality

#18

Post by quietkoala »

amarant wrote: post #17

I disagree with the initial premise >Quality is the absence of problems A low quality code base can be problem free if surrounding circumstances are forgiving enough. Conversely, a high quality codebase can have a lot of problems in difficult circumstances. I haven't thought about it long enough to have a definition of quality that I'm really happy with, but I think a "resilience to hardships" would be a better defin…

I think you're circling the definition I most closely align with which was coined by Gerald Weinberg - "Quality is value to some person". You can have the best looking interface and the cleanest codebase, but if nobody is getting value from your software, who cares? If somebody is getting a ton of value from your software they're more forgiving of defects they run into.

There isn't some intrinsic value to software, it's gotta be used by somebody

Re: Notes on Software Quality

#19

Post by MaxBarraclough »

amarant wrote: post #17

I disagree with the initial premise >Quality is the absence of problems A low quality code base can be problem free if surrounding circumstances are forgiving enough. Conversely, a high quality codebase can have a lot of problems in difficult circumstances. I haven't thought about it long enough to have a definition of quality that I'm really happy with, but I think a "resilience to hardships" would be a better defin…

> I think a "resilience to hardships" would be a better definition of quality

Does this refer only to program behaviour? I figure readability should count toward quality, but it doesn't directly affect program behaviour.

Re: Notes on Software Quality

#20

Post by chasd00 »

amarant wrote: post #17

I disagree with the initial premise >Quality is the absence of problems A low quality code base can be problem free if surrounding circumstances are forgiving enough. Conversely, a high quality codebase can have a lot of problems in difficult circumstances. I haven't thought about it long enough to have a definition of quality that I'm really happy with, but I think a "resilience to hardships" would be a better defin…

> But absence of problems is not it.

i disagree, think about what defines a problem. Not being maintenable, readable, performant etc could be problems or may not be depending on the software requirments.

> Occasionally you'll be prepared for hardships that never occur.

this over-engineering and just as bad as failing to meet a requirement, you're wasting resources that could be spent on something else. In fact, meeting the requirements and only the requirements is requirement #1 ;)

Post reply on HN