4 ms·

See also: http://www.superwebdeveloper.com/2009/11/25/the-incredible-rate-of-diminishing-returns-of-fixing-software-bugs/ http://www.superwebdeveloper.com/2009

See also: http://www.superwebdeveloper.com/2009/11/25/the-incredible-rate-of-diminishing-returns-of-fixing-software-bugs/ http://www.superwebdeveloper.com/2009/11/25/the-incredible-r... If I recall from my Software Engineering courses this is based on research that IBM did, back when they still did research into this sort of thing. There is nothing magical about the "web-based software realm" that separates it from other sorts of software and development and allows it to bypass the issues that cause the cost of fixing a bug to sky-rocket like this the later in the process you leave it.

nostrademons 16y ago
"There is nothing magical about the "web-based software realm" that separates it from other sorts of software and development and allows it to bypass the issues that cause the cost of fixing a bug to sky-rocket like this the later in the process you leave it." Sure there is - people writing easily deployed consumer software don't write code like this. It's crazy to spend months designing software, based on things you think you know, when you could just build and release it and have far more information in far less time. Anyone who writes software where the deployment cycle is measured in minutes to hours (that's anyone on the web, or desktop or mobile apps with auto-updaters) relies on an iterative process of code -> release -> gather data from real users -> refine the product -> repeat. People who don't do this get creamed in the marketplace, because their competition does, and their competition gets far more information to build a better product through it. Most of the stuff taught in Software Engineering courses is complete bullshit when applied to the types of problems that actual practitioners face. This is because the field of software engineering is far broader than most people can imagine, and certainly more than you can teach in an undergrad education. A development cycle like you site is pretty much the norm if you're writing embedded microcontrollers for avionics (actually, the cost increases are probably even steeper). Very few people are writing embedded microcontrollers for avionics. For the majority of us, who're working on software developed and deployed over the web, the cost curve you cite is ridiculous.
- maigret 16y ago
  The cost of fixing bugs is correlated with the value your software provides. If you write any software that not much people are using and relying on it (I mean, relying on it to do their job, manage their bank account, their customers...), then a bug on a production system will probably cost you a lot. The other side of that is that code where you don't need software engineering cannot be really relied on. Hacking will help you getting a prototype fast, but if you want to scale you need software engineering. Twitter (amongst others) learned it the hard way.
- nikster 16y ago
  Meh. The best web developers I know are also the fastest I know; they write unit tests like crazy. They write good code. I guess you're assuming that writing good code takes longer, which is the basic fallacy in software engineering. Writing good code is way faster, almost from the get-go. You reap the benefits on _day two_, literally. I am not sure what they taught you in SE - I found most of what I learned to be true in the field, however, I also found it shocking how little this seemingly common knowledge is used out there. I directly benefit from the incompetence of most software engineers out there, but I much prefer to work with good people.
  - randallsquared 16y ago
    The best web developers I know are also the fastest I know; they write unit tests like crazy. They write good code. I guess you're assuming that writing good code takes longer, which is the basic fallacy in software engineering. You keep saying this as if you believe that writing unit tests automatically means you've written good code. You can possibly have good code without unit tests. You can, more importantly, have awful code with unit tests. For me, a major axis of "good" for code is maintainability. Therefore, writing good code means spending some time considering names rather than just using the first ones that pop into your head as you type. It means thinking about whether these superficially similar pieces of code are really related enough for code reuse to be beneficial, or whether it's only incidental similarity and really should exist in both places independently in your codebase. It's about writing small pieces of functionality yourself when otherwise you'd drop in a library that dwarfs your written code -- sure, dropping in the library is fast and easy, but if something goes wrong, you're now debugging 100K lines of someone else's code instead of the 1K lines of in-house code it would have taken to do just what you needed... Writing good code in this way often takes considerably longer than just cranking out something that works for now, and the largest factor is not time to write unit tests, but time to think about what you're doing rather than coding at the speed you can type.
kragen 16y ago
This is based on research IBM did back in the 1970s on mainframe applications written in COBOL and IBM 360 assembly. Since then, we have 30 years of experience and tools for making software more flexible and easier to change. It worked, although people like Barry Boehm seem not to have noticed yet. We now routinely change the requirements and design of software that has already been deployed.

nostrademons 16y ago

"There is nothing magical about the "web-based software realm" that separates it from other sorts of software and development and allows it to bypass the issues that cause the cost of fixing a bug to sky-rocket like this the later in the process you leave it." Sure there is - people writing easily deployed consumer software don't write code like this. It's crazy to spend months designing software, based on things you think you know, when you could just build and release it and have far more information in far less time. Anyone who writes software where the deployment cycle is measured in minutes to hours (that's anyone on the web, or desktop or mobile apps with auto-updaters) relies on an iterative process of code -> release -> gather data from real users -> refine the product -> repeat. People who don't do this get creamed in the marketplace, because their competition does, and their competition gets far more information to build a better product through it. Most of the stuff taught in Software Engineering courses is complete bullshit when applied to the types of problems that actual practitioners face. This is because the field of software engineering is far broader than most people can imagine, and certainly more than you can teach in an undergrad education. A development cycle like you site is pretty much the norm if you're writing embedded microcontrollers for avionics (actually, the cost increases are probably even steeper). Very few people are writing embedded microcontrollers for avionics. For the majority of us, who're working on software developed and deployed over the web, the cost curve you cite is ridiculous.

maigret 16y ago
The cost of fixing bugs is correlated with the value your software provides. If you write any software that not much people are using and relying on it (I mean, relying on it to do their job, manage their bank account, their customers...), then a bug on a production system will probably cost you a lot. The other side of that is that code where you don't need software engineering cannot be really relied on. Hacking will help you getting a prototype fast, but if you want to scale you need software engineering. Twitter (amongst others) learned it the hard way.
nikster 16y ago
Meh. The best web developers I know are also the fastest I know; they write unit tests like crazy. They write good code. I guess you're assuming that writing good code takes longer, which is the basic fallacy in software engineering. Writing good code is way faster, almost from the get-go. You reap the benefits on _day two_, literally. I am not sure what they taught you in SE - I found most of what I learned to be true in the field, however, I also found it shocking how little this seemingly common knowledge is used out there. I directly benefit from the incompetence of most software engineers out there, but I much prefer to work with good people.
- randallsquared 16y ago
  The best web developers I know are also the fastest I know; they write unit tests like crazy. They write good code. I guess you're assuming that writing good code takes longer, which is the basic fallacy in software engineering. You keep saying this as if you believe that writing unit tests automatically means you've written good code. You can possibly have good code without unit tests. You can, more importantly, have awful code with unit tests. For me, a major axis of "good" for code is maintainability. Therefore, writing good code means spending some time considering names rather than just using the first ones that pop into your head as you type. It means thinking about whether these superficially similar pieces of code are really related enough for code reuse to be beneficial, or whether it's only incidental similarity and really should exist in both places independently in your codebase. It's about writing small pieces of functionality yourself when otherwise you'd drop in a library that dwarfs your written code -- sure, dropping in the library is fast and easy, but if something goes wrong, you're now debugging 100K lines of someone else's code instead of the 1K lines of in-house code it would have taken to do just what you needed... Writing good code in this way often takes considerably longer than just cranking out something that works for now, and the largest factor is not time to write unit tests, but time to think about what you're doing rather than coding at the speed you can type.

kragen 16y ago

This is based on research IBM did back in the 1970s on mainframe applications written in COBOL and IBM 360 assembly. Since then, we have 30 years of experience and tools for making software more flexible and easier to change. It worked, although people like Barry Boehm seem not to have noticed yet. We now routinely change the requirements and design of software that has already been deployed.