Permission to Fly.

Discussions

Industry news: Permission to Fly.

  1. Permission to Fly. (3 messages)

    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 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.
  2. One minor detail:

    software is there to solve business problems.

    That includes that business IS saying where software projects are going, what problems it need to solve, etc.
    Why do you think that the business people are paying for software?

    I agree that most people know how things should go while it's completely out of their scope (e.g. business people telling how an architecture should look instead of telling what their requirements are).

    But I find that technical people thinking that they should decide what software should do is one of the biggest problems in the industry. (Technical people with a sound domain knowledge of the particular domain they're working should advice the business, but never dictate)
  3. Barre,

    using the same analogy with the flight - any software is being created for an end-user, just like the airplanes of Lufthansa or NorthWest are in the air for its passengers, not for the entertainment of a pilot. Does a passenger tell a pilot how many miles per hour should it reach before the take-off?

    "Business people" can not run the "airplane", neither are they the actual clients. What they are supposed to do - is to talk to the real clients, understand their needs, collect all this information and present in a unified, prioritized way to the technical people who are the ones to decide how to best meet these needs, what is the time needed for the task and when is the airplane ready for the flight.

    How many programs do you know that you really like? Why do you have to update your software so frequently? Why are, a lot of, commercial programs way buggier than the open-source counterparts, even though the proprietary ones are spent much more resources on?

    "Something is rotten in the state of Denmark".
  4. 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.

    Cheers,

    Barre

    p.s. as a side note on my previous post: s/business people/clients