Permission to Fly.
"Aircraft in position. Requesting permission to fly"
- from the radio transmission of a flight captain with an air traffic controller.
Software projects are like the airplane flights. What users see is just the end-result of the work done by a group of professionals. Users may have a clue but do not really care to understand the immense amount of work put into building the airplane, training pilots, flight-attendants, airport personnel, engineers who make sure that plane is fully ready for each flight. The only thing that really matters begins when the aircraft rolls out of the boxes, prepares for the flight and takes off. Anything else is just the preparation for that important task. There are no excuses during the flight - everything has to be perfect.
What does a software project need to take off and have a successful flight? We often focus on building the plane,itself; We have even got used to calling the process - Engineering and come up with fancy names like Software Architect, Designer yadda, yadda, yadda. But, is a good plane enough for a successful flight? No, it is not. The actual journey only begins after the take-off and that is something a lot of projects forget. Alas, most of the projects, never even get into the air, rolling, or rather crawling, on the earth like a cheap van.
Merciless laws of Physics are very clear - in order to fly, plane must reach enough speed and turn its nose to the high skies, at the right moment. How many times have we seen a software project rolling on the earth too long, reaching a dead end and crashing or having to turn around and begin the everything from zero miles per hour? Knowing when it is time and having enough guts to head up is the key to flying.
But getting into the clouds is just the beginning of the journey. What happens once we are up there? Everybody takes orders from the flight captain. There is no democracy in the air - the captain is an absolute dictator, the success of the whole flight depends on his decisions and he himself relies on the capable crew. When you are up in the sky - you really want each person to be the best of the best - any mistake is too expensive. What do we see in most of the software projects? Average developers, average QA, average analysts. And sometimes average is something we wish for a lot of the times, the people you get are the ones you get and you need to do the best with what youve got.
Would you rely on such a crew in the air? Would you entrust life of two hundred plus people to just average personnel or even worse - whatever you've got? How come the software that drives lives of thousands is less important? Is it, really?
When and how did the legendary Time to Market has become more important than the quality? How could we allow business people dictate when the project is ready to take off and how the plane should fly? Did we carelessly diminish the importance of the software project lifecycle, comparing it to building and architecting constructions that can be half-finished, re-modeled later or sold as a cheap alternative? Why do we have so many "programmers" but when we need the real ones, they are always hard to find? Why do so many software projects fail? Have we ever heard of airline manager ordering a flight captain to take half-ready plane in the air, for the sake of some "Time to Market"?
Why are open-source projects producing better software? Is it because of the less intrusion of remorseless Business? Is it because, in the open-source projects, only people who prove themselves useful are kept and there is no place for those who "we've got, so let's think, now, what to do with them"? Is it because there is much less space for the bureaucracy in the open-source projects? Or is it all just a myth?
The questions, and answers they lead to, are arguable, maybe, but when there is a question - there is uncertainty. Uncertainty allows, some of us, afford thinking a little bit differently. Maybe, just maybe, building and publishing software is more than just constructing buildings of bricks; maybe we have put the technology into too tight chains of business? Maybe we have hurried too much declaring software as another commodity?
Maybe... But one thing is clear - we need permission to fly. We need a confident captain and a capable crew. Aircraft is in position and we are requesting permission to fly - maybe it will be too late afterwards.
What I'm talking about is keeping focus on your specialism.
To keep with the flight analogy too:
The pilots should make sure that the passengers should reach their destitination in the manner that the passenger paid for (on time, with food served on board, safely, etc.).
The passenger shouldn't be bothered with altitude, speed, wind direcations, routes, etc. (though it might interest him/her), the client needs to get from A to B in the manner (s)he paid for.
It's the pilot's job to make sure that the client gets it.
The same thing goes for coding. We are there to make sure we implement what the client needs, not to tell the client what he needs (we're also here to advice, but not dictate as I mentioned before).
On the part of buggy software, welcome to the industry where time-to-market, alot of low skilled programmers and buzz-words govern.
And I don't fully agree on the resources spent on OS v.s. proprietary software; looking at the number of people contributing and version drop time-intervals I'm tending to say that the resources spent on OS development are higher (also considering testing by users/test-teams, alpha- v.s. beta- v.s. final-releases, etc.), though this is not always the case.
p.s. as a side note on my previous post: s/business people/clients