3 ms·

The lack of mathematical rigour is what kills it. The software industry is the one where we do not learn from past mistakes or successes, we rarely measure impo

by omouse 17y ago

The lack of mathematical rigour is what kills it. The software industry is the one where we do not learn from past mistakes or successes, we rarely measure important things or when we do benchmark, it's to focus on stupid things like the overall performance of specific language implementations or how much RAM Firefox is using instead of figuring out how to eliminate whole classes of problems. We can be artists and creative people just as mathematicians and physicists are. I'm reading about John Nash and holy shit, Princeton gathered some of the smartest people together and told them not to worry about grades, just worry about research. Nash himself would just wander around the halls and just think. The papers written may seem formal but the way the ideas were generated was highly informal, with random meetings and discussions in hallways and common rooms and walking about lost in thought. What struck me as most interesting and applicable to software development is that Von Neumann and the others at RAND were applying somewhat pure/abstract mathematics to specific problems in other fields. So why don't we take a page from them and apply some more rigour to measurement, and why don't we learn some management skills and develop useful metrics for software development, so that we can stop letting the marketing people and the snakeoil consultants from monopolizing our field and turning it into a wasteland of overly expensive unfinished projects.

akeefer 17y ago
What would those metrics be, though? Pretty much every metric anyone has ever come up with to "measure" software development has been worthless, and it doesn't look like that trend is going to be broken soon. It's like trying to apply metrics to writing a novel. After a certain point, if something doesn't work you have to accept that maybe it's just a bad idea, and I think we're well past that point with software development and metrics. About the only useful metrics I know of are all end-state sorts of things: bug counts and regression rates, number of satisfied users versus dissatisfied users, number of successful implementation projects versus failed implementations, and whether you can generate real revenue or business value. As soon as you start trying to look at things like number of lines of code, "function points" implemented, coupling metrics, test coverage metrics, etc. it tends to start distorting your development efforts, and the harder you push on formalisms and hard metrics the worse it gets. Pretty much any metric in software is really a way to get at some unmeasurable underlying thing like "quality" or "rate of progress," but they're always easily gamed. It's like standardized tests and education: the more you push on "accountability" and standardized test scores, the more teachers teach strictly to the test, and the less the kids actually learn. Similarly, of the best ways to destroy a software project is to guide the development based on metrics. I think you get much better results if you approach software as a design process, which is inherently unpredictable and non-repeatable, instead of as a manufacturing process where predictability and repeatability are the desired goals. As much as the word "agile" has come to be almost meaningless these days, that's really the original insight behind it: on a fundamental level, software development is an unpredictable, non-repeatable design process, and so the best you can do is to expect that to happen and build in ways to deal with that, rather than instead trying to exert more control.
- shpxnvz 17y ago
  It's like trying to apply metrics to writing a novel. Oh, that's not hard to do. The only one that matters in the marketplace for software is the same one that matters to most novel publishers - does it make money. That's a simple metric to measure and it's one that corporations instinctively understand, both in software and in novel publishing. Monetarily successful software publishers, just like novel publishers, know very well what the quality sensitivity of their customer is, and produce accordingly. The metric (and the audience quality sensitivity) is obviously quite different when you are talking about niche product, be it aircraft control software or a mathematics textbook.

by omouse 17y ago

akeefer 17y ago

What would those metrics be, though? Pretty much every metric anyone has ever come up with to "measure" software development has been worthless, and it doesn't look like that trend is going to be broken soon. It's like trying to apply metrics to writing a novel. After a certain point, if something doesn't work you have to accept that maybe it's just a bad idea, and I think we're well past that point with software development and metrics. About the only useful metrics I know of are all end-state sorts of things: bug counts and regression rates, number of satisfied users versus dissatisfied users, number of successful implementation projects versus failed implementations, and whether you can generate real revenue or business value. As soon as you start trying to look at things like number of lines of code, "function points" implemented, coupling metrics, test coverage metrics, etc. it tends to start distorting your development efforts, and the harder you push on formalisms and hard metrics the worse it gets. Pretty much any metric in software is really a way to get at some unmeasurable underlying thing like "quality" or "rate of progress," but they're always easily gamed. It's like standardized tests and education: the more you push on "accountability" and standardized test scores, the more teachers teach strictly to the test, and the less the kids actually learn. Similarly, of the best ways to destroy a software project is to guide the development based on metrics. I think you get much better results if you approach software as a design process, which is inherently unpredictable and non-repeatable, instead of as a manufacturing process where predictability and repeatability are the desired goals. As much as the word "agile" has come to be almost meaningless these days, that's really the original insight behind it: on a fundamental level, software development is an unpredictable, non-repeatable design process, and so the best you can do is to expect that to happen and build in ways to deal with that, rather than instead trying to exert more control.

shpxnvz 17y ago
It's like trying to apply metrics to writing a novel. Oh, that's not hard to do. The only one that matters in the marketplace for software is the same one that matters to most novel publishers - does it make money. That's a simple metric to measure and it's one that corporations instinctively understand, both in software and in novel publishing. Monetarily successful software publishers, just like novel publishers, know very well what the quality sensitivity of their customer is, and produce accordingly. The metric (and the audience quality sensitivity) is obviously quite different when you are talking about niche product, be it aircraft control software or a mathematics textbook.