OSNews

Engineering – as construction engineering – is „easy to do“ in a sense that construction engineering builds on physical laws.

You've got a fundamentally mistaken notion of "meat-space" engineering. Engineering is governed by physical laws, yes, but the hard part of engineering is dealing with the fact that most of our knowledge of those laws is incomplete. Take, for example, air turbulence. Nobody has an equation for turbulent airflow. There are various probabilistic models, but nothing that's terribly accurate, much less actually representative of the underlying physical processes. Yet, every airplane engineer has to take turbulent flow into account in designing their products. That's why we have engineers at all, to deal with the imprecision in our knowledge of the real world.

Meanwhile, programmers work in a world of mathematical precision. They not only have a rich, well-defined framework of theory within which to work, but they also are free of the extreme limitations imposed by physical reality. The closest they come to limitation is NP-completeness or undecidability, and even then they have heuristics that can give highly precise conservative solutions.

Basically construction engineer can ask itself a „will this work“ question and find a answer without actually building end product.

Hardly. Most of the interesting questions are way too hard to answer from physical laws alone. Engineers rely heavily on statistical data, past experience, and heuristics to answer such questions. You know how most airplanes are designed? By starting from an existing one that is known to work!

there isn't any way to formally test code on bugs and „will it work“ question will remain unanswered until you actually build end product.

You're right that building the product and testing it is the only way to know that it really works. Which is a strong argument against too much process in programming!

Process is not a tool to improve quality. You don't prove that something works by following a particular process, but by building it and testing it. Instead, process is a tool to manage risk. Engineers use lots of process because of the enormous costs of building, testing, and experimentation in "meat-space". Programmers aren't subject to the same sorts of limitations. Building, testing, and rebuilding are relatively cheap in programming. Ergo, a highly process-oriented development methodology isn't necessary for programming, and indeed actively hinders the activity.

Ok. It true that turbulences are quite wild. Heisenberg itself had a figure-out-turbulence project during his studies. He give up stating that it is mind boiling and 6 months later created quantum physics.

However you could hardly pick up more extreme example of engineering project. Large scale airplane project (civil or military) are $10+ billion projects. That is quite more than average space project (ESA has budget of one third of it).

Anyway you don't even need turbulences to see those problems. Even simple construction problems are unsolvable by analytic methods inspite of knowledge of all laws governing it. Like resonance frequencies of beam supported by two fixed sides.

However when mathematics fails both problems have relatively cheap solutions – the experiment. That’s why airplane engineers have prototypes and wind tunnels. For fraction of cost of all project they can measure and see will it work.

It doesn't work with software. The closest to verifying its design is peer review of your colleague.



It's funny that you think that software is virtually unlimited peace of design. Math is unbounded disciple. Software is bounded by performances, time, tools, customer desires, skills and money.

For example right now I have extreme problems with 32k size limitation of CICS commarea..

And it doesn't change the fact that you will not know does it work until you build the whole thing.



Indeed it isn't. Quality comes from individuals involved. However it is a thing to lesser communication overhead and open space for more productive development. What’s your idea of development process? Bunch of managers telling everyone how to write a code?



Do you know how much time does it take just to analyze problems before coding in software development? In good managed project it's about half of all wasted time. Compare that to no more than 10% for typical engineering discipline and 90% of time is spent on building. In software building eats no more than 10% of time for application software and presents no more than one ninth of money spend. On system software (drivers, kernels) it is even far less. Testing of system software is really really expensive.

And why do you thing that software is cheap? Did you know that third of cost of B2 (US stealth bomber) is in software? Other airplane project - Grippen fighter, stalled on software errors, not on turbulences.

On mine current project, for debugging time spent on one processor of zSystem one could buy a luxurious over-the-top BMW every month. That’s a fraction of total cost, east-european wages and mid sized project by western standards.



Yes – if you are building the next Tetris or your aunts videostore application. It is completely opposite when problems aren't trivial. What do you think how much money would Linux-like fat kernel tend to cost when developed by some company? My judgment is no less than $200 million of dollars and that’s optimistic.

I don't know if you are aware of it, but software development exponentially slows with its size. Linux is system software with something about 6-7 milions LOC's. Thats expensive. Extremely expensive.