When something is supposed to be easy, we say: “That ain’t exactly rocket science!”. It must be easier than Rocket Science, since Rocket Science is hard!
Yes, rocket science is pretty hard. It is the art of filling a metal tube with super-combustible material, shoving a payload on top, setting fire to it, and hoping it manages to leave earth’s atmosphere in one piece. And then there is all that stuff about getting into the right orbit and delivering the payload.
That is no easy feat. And that is the analogy I think we should be using when describing the difficulty of software development, because it has implications that I will explain later in this article.
But first, let’s have a look at the thing we normally compare software development with: The construction of buildings, with, uh, foundations and, well, pipes and stuff. Complex software is supposed to be like building a high-rise building..
I honestly believe that it is a completely broken comparison.
Building construction is a method refined over hundreds of years that ensures that even though most buildings are full of faults, mismatched parts, corrected mistakes and bits of shoddy craftsmanship, they still stand. We have figured out the physics and know how much material we must use to tolerate a certain amount of mistakes. We then cover most of the shoddy stuff behind plastered walls.
Very seldom do we hear of buildings collapsing or people not getting into their house because of bad planning. Buildings tolerate a certain amount of leeway, and we have over time figured out just how much.
Software on the other hand does not tolerate a lot of mistakes. One mistake is enough to break most programs. There is no building of solid foundations and then slapping the rest on top and fixing stuff as you go along. Your program only works when all the bits work. You might have missing features, but anything worse than that, including text errors, could have severe consequences. If your software touches any critical infrastructure, one bug could put your whole company at risk.
Just like a rocket. One mistake and the whole thing blows up, with your mission, your money and your reputation. It might explode on take-off, your payload gets misplaced in orbit, or the rocket explodes on re-entry carrying precious cargo. There are many ways it could fail.
This is what company owners, managers and project leaders should be thinking of when they build software. They should be telling themselves: “This stuff is rocket science, and we better do a bloody good job of it.” Then they should think of exploding rockets!
If building software is rocket science, then you want the best rocket builders. You want people who are dedicated and smart, and you want to keep them around because they have the knowledge of how to build your rockets. Any person that quits takes with them some of that knowledge, and a new employee has to gain that knowledge. Minimize churn.
Your business people might know what they want and how it will make money, but the software guys have to understand how anything new fits into the existing system, down to the most minute detail, and then put it together in a way that doesn’t make everything explode.
Most companies are turning into software companies without even knowing it. They are totally dependent on software, but they think software development is constructing buildings, not building rockets. They think the software department is a naughty expensive step-child that can be starved and outsourced, when in reality the developers are the ones with the most complete domain knowledge.
Think about this for a moment: Every bank and every insurance company is a software company. Almost all customer interaction is through software, most internal routines are chaperoned or automated by software, and most of it is custom built for their requirements. That sounds like a software company. The main difference between these companies is the products they sell.
Of course a bank needs to know banking and an insurance company needs actuaries. But this knowledge is being embedded into software, and the developers are doing this embedding.
I have seen software developers help business people understand how something worked because they implemented it and retained the knowledge, while the insurance expert had forgotten the details. That is domain knowledge.
Traditional non-software companies that have been eaten by software often have managers that do not understand software development. This is becoming a problem for these companies, in large part because of faulty analogies.
In my opinion software development is at least as hard as rocket science, and treating it like anything less will weaken your company, cripple your software and most likely make something explode in a very bad way.
Oh, by the way: Rockets also need software. =)
Please, more on Darkfall tech someday! Please! 🙂