Hacker News Reader

Comment by wmt | Hacker News Reader

That's actually the problem! Many current engineering disciples were before handled by craftsmen until scientific principles were applied to it, making it engineering.

There have been very few scientific studies about the basics of building software, like how much unit tests really affects the bug density, and those few studies go often unnoticed when teaching future software engineers.

It would require a major effort to first study the existing emergent software craftsmanship practices to find common patterns and to scientifically evaluate their effectiveness, and the results would have to be taught in the hypothetical future curriculum where future software engineers would be made. Then we might have software engineering instead of just software craftsmanship.

It's almost a bit amazing that software "engineers" who can be very obsessive about getting the data or A/B-testing will craft software based on methods they have no data about.

View on HN

> There have been very few scientific studies about the basics of building software...

There hasn't been a lot of great quantitative scientific study on how to productively do science either. Academic science is a craft, and is more or less learned through apprenticeships.

I'm trained as a physicist, and I'm certainly a fan of quantitative scientific methods, but I think it's important to realize that there are some areas where quantitative science is effective and rewards the required work well, and other areas where it is largely an ineffective waste of time.

I suspect trying to quantitatively study things like "how much unit tests really affects the bug density" is one of these cases with a poor reward to effort ratio.

There's a danger in trying to apply quantitative science to complex phenomena, when many or most relevant factors are actually uncontrolled and unmeasured. Once you have a number--any number--the tendency is to fetishize it at the expense of broader thinking. Make no mistake: quantitative measurements of the behavior of people performing complicated tasks do not carry the same epistemological force as quantitative measurements of the magnetic dipole moment of the electron.

Scientists themselves more typically try to understand their own craft through case studies and "professional wisdom" passed down from practicing experts to apprentices. Software developers would probably do well to (continue to) do the same.

It's not just that not a lot of science is applied to the craft of programming. It is that many programmers are actively hostile to the concept. For example, the rules of programmers.se forbid asking for statistics. So if you want to know objective facts about the craft of programming, you're forbidden from asking for it on the most popular forum about that craft. When I asked why this rule was in place, it became apparent that the only real reason was an irrational dislike of statistics. With that kind of attitude our craft will never become an engineering discipline..

You should ask: do I want it to be an art, or merely a discipline?

> When I asked why this rule was in place, it became apparent that the only real reason was an irrational dislike of statistics.

Can you reference those claims? If I ever repeat this claim, I would prefer to be able to link to the administrators' statements directly.

Maybe that future isn't too far away! Have you checked out Code Complete? My university used it as a textbook for a Software Engineering course. To borrow your example, it cites multiple studies about the effectiveness of unit testing on errors, as well as many other software engineering topics.

Reply on news.ycombinator.com