Why Software Engineering Isn’t Engineering

I like that he included the counterpoint to his position early on in the article (Cleanroom etc). The article is correct that our type of engineering is a bit different with all the interactions between components and the fact that they're often different. Yet, there's a subset of the field that counters these problems through choice of development style (eg Cleanroom) with well-understood components with consistent interfaces. The style is fairly easy to pick up but the good components are built up incrementally over time.

Truth is, manager's and developer's choices are why most of this isn't the case. Management might push use of a problematic technology, give too little time to assure quality, and so on. Developers might care little about making things maintainable, prefer a style which impedes it, or use fad technologies with tons of unknowns. The combination led to pervasive issues in the industry the article references.

The solution is for quality-centric IT shops to differentiate by going in the opposite direction. The same for FOSS projects. Fortunately, we see a little bit of this here and there. Altran-Praxis was delivering engineered software via Correct by Construction methodology. One student's combination of Python and Cleanroom was promising. Ada and Eiffel communities are using Design-by-Contract to aid predictability/maintenance. So, we see pieces of how vanilla IT shops & FOSS can raise the bar closer to engineering. We just need courageous groups to jump and grab it.

What will be the incentive of a start up company to follow these new rigorous software engineering practices? How many other engineering disciplines could get away with cutting those types of corners for a first version of a product? Perhaps people put planks over gaps when the standard for bridges was lower. It's hard for me to imagine a world where customers demand a product built with strict software engineering practices. Though, that would be nice if that happened, as a user.

You have a good point about timing. I often bring this up myself. The major fields of engineering have hundreds to thousands of years of work that went into them. They also went in the same direction more. I challenge any architect that mocks our work to build his next house using methods that existed in their first 100 years then live in it.

None have taken me up on the offer.

I don't think it uses science, other than scientifically studied development processes, and how many start ups use thast? If you count computer science, I'd kick the can down the road and ask if computer science is a real science? Does it use the scientific method? It seems more as applied mathematics.

Do we?I thought there were clear differences between web dev, in-house corporate data mining, mobile dev, scientific computing, NLP, DSP, infosec and crypto, and so on.

Management doesn't really care what tools or environment you're working in as long as things get built, and they (mostly) work.

You could argue that the more rigorous the math, the more "engineeringy" the programming. So DSP and crypto are very mathematical, data mining and machine learning have strong elements of pure math, and so on.

But what about web UX/UI? The reason they seem lacking in rigour is because they are. There's the infrastructure layer which is usually an ad hoc collection of bolted-together toolkits imported from elsewhere, with varying amounts of glue logic. And there's the user layer which is supposed to create a persuasive customer experience.

Ad hoc infrastructure is hard to formalise because the technology keeps changing. It's not like materials science and structural engineering, which have a core that hasn't changed for maybe a century and are - relatively - trivial to model.

At the top level, creating experience is what the arts do. So you're not going to get much mileage out of expecting them to be amenable to formal methods.

So in fact there's no such thing as software engineering. There are a lot of slightly overlapping disciplines that happen to use code as a raw material, all of which use different models and techniques and have different requirements. There's actually no equivalent to materials science, because the best you can hope for are a few standardised best-of-breed algorithmic solutions to common problems, like search/sort/learn.

But more, when you build something out of atoms, it stays put. Chances are you know the range of temperatures/pressures/forces and other conditions under which it has to work. So you have a well-defined problem.

Code is always a symbolic processing machine, and the range of possible inputs, and the timing relationships, are practically infinite. You can only build a full model when the range of inputs is very constrained - like DSP, which takes an array of floats and produces an array of floats, but doesn't work so well with text strings.

If you're dealing with general user input, it's impossible to build a general model, because you always have to account for as many inputs as possible - explicitly. Some of the inputs may be malicious.

It would be like trying to build a bridge that spent most of its time dealing with cars and foot traffic, but everyone so often someone would try to spill a truckload of acid in the middle, or a nuclear war would break out, or someone who was wearing the wrong kind of shoes would make all the cables snap on Thursdays only, because one of the developers forgot to guard against that brand of problem shoe leather.

It's a completely different class of problem. The reasons it's not rigorous is because it's impossible to be rigorous when your inputs can be infinitely variable, but you still have to account for as many as you can.