“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 you’ve 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.