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

The economics of software correctness

drmaciver.com

Post reply on HN
Print view View original

31–40 of 54 posts

Re: The economics of software correctness

#31

Post by nostrademons »

jaggederest wrote: post #4

I think one of the other problems is that people value the economics of software correctness using their gut, rather than empirical analysis. https://en.wikipedia.org/wiki/Hyperbolic_discounting Everyone knows that bugs are problematic eventually, it just seems that they can't put that on a level playing field with the up front costs, be they in terms of time, features, or effectiveness. As an example, if you asked H…

Hyperbolic discounting is rational when the availability of resources increases exponentially, as it often does for products that catch on.

A company that comes to market with a product that is useful but buggy will attract the attention of venture capitalists & other investors. It will receive user feedback from its existing user base. It will find it easier to hire top talent. It will be able to use collected data to make better products. All of these factors are in proportion to the company's size, which tends to make growth rates exponential.

It's pretty standard practice in the tech industry to bring a buggy, barely-working product to market; use interest in that to raise money; use money to hire engineers; and use the engineers to fix the bugs. You could even look at this as a net benefit to society, as long as existing customers would rather use the product in its buggy, incomplete state than go without it.

Re: The economics of software correctness

#32

Post by InclinedPlane »

hyperpallium wrote: post #28

What about reducing bugs through code reuse, in the form of libraries and frameworks? Because they have more users, more bugs have been found, reported and fixed. e.g. using standard libraries instead of writing your own.

That works only when the quality of the libraries and frameworks are high. When they are crap, you just spread the pain around and you've made things worse.

Re: The economics of software correctness

#33

Post by huherto »

davidw wrote: post #8
a3voices wrote: post #7

Earlier quoted context omitted.

It's mostly based on the skill and experience of the developer. Of course there is probably some asymptote in the quality and delivery time that is impossible to surpass, like the 3 minute mile. Human brains are not without limits and we didn't evolve to write software.

It's not at all about developer skill. It's about methods and process. Ok, you don't want to have a bunch of total bozo developers, or the time to get anything useful done will stretch out to infinity, but still, it's not about just 'being good'.

In my own experience. It is about skills. But if you don't have the skills you need more methods and process. The less skilled is your team, the more processes you need.

Re: The economics of software correctness

#35

Post by socceroos »

cyan_atrus wrote: post #27
meatysnapper wrote: post #22

Earlier quoted context omitted.

Management has two goals: 1) Make themselves look like they contribute value: Micro-manage projects, track time spent, etc. Even if there's nothing achieved, they can claim to be doing something and organizing meetings. 2) Swap out programmers like cogs in a machine. 3) There is no incentive to have good quality code because chances are everybody will be off the project in a year or so, so you take credit for the suc…

i think you might be misunderstanding the point of managers..

True, but he does paint an interesting, if not accurate picture of a significant proportion of the managers out there.

Re: The economics of software correctness

#36

Post by WalterBright »

pm90 wrote: post #20
eCa wrote: post #19

Earlier quoted context omitted.

> People often underestimate the difficulties of getting a hack to work and overestimate how long doing something correctly will take. Yes. And sometimes one of those people is your boss.

Most of the times, I would say. Perhaps the biggest tragedy of Software Development today is how few managers actually do/have done enough software development to qualify managing those who do.

Part of the job as a software engineer is to inform your manager as to the tradeoffs and the correct solution. Especially if well paid.

Surely, there are bosses who won't listen. But of the ones I've worked for, nearly all would listen to a reasonable explanation of how best to achieve the goals, and would approve recommendations from below.

If you've got a track record of being right, that helps a lot :-)

Re: The economics of software correctness

#37

Post by zappo2938 »

Joel Spolsky published a blog post in 2000 named "Things You Should Never Do" (http://www.joelonsoftware.com/articles/fog0000000069.html)

It's about why Microsoft with IE6 won the browser war against Netscape who made the single worst strategic mistake a software company can make by rewriting Netscape 6.0 throwing out all the code from Netscape 4.

Netscape was working with extremely buggy and convoluted code in the older version and trying to save the development community from the nightmare that is IE6, ended being late to the market with a superior product. Joel makes a very good observation that often people want to throw out old code because they think it's a mess, but the truth is counter intuitive that the old code contains vast amounts of knowledge.

A company can be first, best, or cheat and in this case while Netscape was trying to be best, Microsoft was first.

This is the reason iterative code development is best. Speed of iteration beats quality of iteration 9 out of 10 times. Boyd's Law of Iteration (http://blog.codinghorror.com/boyds-law-of-iteration/) The best software is software that released most often, not released the most correct.

If I was to release a browser in say 2008 to compete with the dominance of IE, what is the single most important feature I could put into that browser? I'd put a feature for forcing iteration, so that the browser can automatically update on the client finishing a development cycle rather than release the update preinstalled unable to remove on newly bought computers.

Re: The economics of software correctness

#39

Post by davidw »

huherto wrote: post #33
davidw wrote: post #8

Earlier quoted context omitted.

It's not at all about developer skill. It's about methods and process. Ok, you don't want to have a bunch of total bozo developers, or the time to get anything useful done will stretch out to infinity, but still, it's not about just 'being good'.

In my own experience. It is about skills. But if you don't have the skills you need more methods and process. The less skilled is your team, the more processes you need.

I think that's going down the wrong path: you can get "pretty good" software if you get the best people and just let them work on it. But it'll still have bugs. You need more process and stuff like verifiable software and all that kind of overhead to really start getting close to bug free.

Re: The economics of software correctness

#40

Post by danjayh »

zappo2938 wrote: post #37

Joel Spolsky published a blog post in 2000 named "Things You Should Never Do" ( http://www.joelonsoftware.com/articles/fog0000000069.html ) It's about why Microsoft with IE6 won the browser war against Netscape who made the single worst strategic mistake a software company can make by rewriting Netscape 6.0 throwing out all the code from Netscape 4. Netscape was working with extremely buggy and convoluted code in the…

Funny thing is, Microsoft did almost the same thing with Windows NT. However, unlike Netscape, they had the resources to keep iterating their old junk while they worked on the totally new version.
Post reply on HN