"Con Kolivas is a prominent developer on the Linux kernel and strong proponent of Linux on the desktop. But recently, he left it all behind. Why? In this interview with APCMag.com, Con gives insightful answers exploring the nature of the hardware and software market, the problems the Linux kernel must overcome for the desktop, and why despite all this he's now left it all behind."
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2007-04-17
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.
Member since:2005-07-06
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.
Turbulence is an extreme example, but it's not the only one. There are almost no interesting problems in atmospheric flight that are simply described in terms of physical laws. Structural mechanics? Anything that isn't a simple geometry (brick, beam, sphere), is analyzed in terms of simple geometries (finite elements). Aerodynamics? Its impossible to work at the physical level (motion of molecules in air), so you make all sorts of assumptions to derive approximate models (eg: low-subsonic continuous flow systems). Thermodynamics? There are some beautiful equations based on conservation laws, but the minute you hit something as complex as a compressor you're back to empirical models.
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.
This is dead wrong. Experimentation in software is enormously cheaper than experimentation in engineering. A commercial-grade wind tunnel can cost tens of millions of dollars, and thousands per hour to operate. A high-fidelity wind tunnel model will run you hundreds of thousands of dollars or more. It's also very difficult, pain-staking work, because the solution-space is enormous (tens of gradiations in tens of dimensions even for a small system). Just running the simulations to evaluate a small range of configurations can take a day of processor time. Software developers don't have nearly the same level of cost constraints.
What’s your idea of development process? Bunch of managers telling everyone how to write a code?
Seems to me like this is exactly what a process-heavy style often gives you. I don't have the experience to know what's effective in managing a large project, but in my experience programming in a research setting, I think a good model is thus: get working code as soon as possible, iteratively refine to add features and refactor existing code, and test at every step to ensure that there are no regressions. Add architecture only as necessary, make it a point to use good tools, and build-in a strong framework for debugging and experimentation from the very beginning.
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.
This is process at fault, saying that the problem should be fully analyzed before work starts. This is necessary in engineering, but rarely necessary for most programming projects.
And why do you thing that software is cheap?
I never said software is cheap. I said the relative cost of experimentation in software is cheaper than the relative cost of experimentation in engineering projects.
There is also a cost-benefit issue to consider here. The software environment is what it is. The budgets are a given and the ever-changing requirements are a fact of live. *Given* those constraints, what's the best way maximize the quality of software? The methodology used for aerospace-grade software is not appropriate for most software. The budget isn't there, the requirements-stability isn't there, and the extensive safety-requirements aren't there.
On mine current project, for debugging time spent on one processor of zSystem one could buy a luxurious over-the-top BMW every month.
You could buy a BMW with how much it costs to run a wind tunnel for a day or two.
What do you think how much money would Linux-like fat kernel tend to cost when developed by some company?
Whatever it was, I think it would've been higher, with no improvement in quality, if a traditional, process-heavy development methodology been used.
Member since:
2005-07-06
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.