The Software Development Process: Building a House or Building a Car for Mars?

Some say software development is like building a house. I disagree — a house doesn’t move, isn’t expected to perform outside of staying upright and weatherproof in a storm (which is very important, don’t get me wrong), and is built on a foundation of knowledge that has been evolving over centuries. I think software development is more like trying to build a car that will do 0 to 60 in under 2.3 seconds…on Mars.

Why would I say 0 to 60 in less time than a Bugatti Veyron or a Porsche 911 Turbo? When was the last time you started a substantial project with the mindset, “As long as it’s somewhere between sub-par and acceptable, that’s fine with me.” People want their software development projects to be amazing — the solution needs to be fast, high-quality, optimized for search engines, fully functional, and stable. And, of course it needs to be at the forefront of cutting edge technology because the second you start the project, the clock is ticking on that technical solution becoming outdated.

But why does it need to be built to be driven on Mars? Simple, while the technology behind building a car has been evolving for over a century, there are things that can be assumed with a fair amount of certainty about building a car to be driven on Earth — you know what components you’ll need, the effect of the Earth’s gravity, how the car will behave in the environment and weather conditions, etc.

However, if you’re building a car to be driven on Mars, there are many more factors to consider — the Martian terrain is going to be different from most driving conditions on Earth — your suspension will have to be completely different, the heating/cooling system will need to be pretty robust to keep the driver comfortable (…and alive), and you’re going to need some sort of system to supply breathable air to the driver. You’re also going to have to make assumptions on the environment (gravity, surface composition, etc.) based on research that has already been done and information that has already been gathered by those who’ve explored the environment ahead of you.

Building a House vs. Building; a Martian Car
But the biggest difference between building a house on earth and building a car on Mars is that technology for building a Martian car is going to change rapidly as more is learned about the environment and new innovations are made. As soon as you start the project, you’ll be trying to hit a moving target while the overall goal remains the same — 0 to 60 in under 2.4 seconds and do it on Mars. While you can plan for changes to occur and set the project up to be able to handle the new information that comes in, you’re still going to have an ever-changing environment and list of requirements for building this car that wouldn’t be an issue if you were building the car to drive on Earth.

Much like a Martian car, building software is often like chasing a moving target. New technologies, enhancements to programming languages, and other developments are constantly bombarding the software industry. Since you want to incorporate the most up-to-date information and features into your solution, the scope and requirements are bound to change as the project progresses to ensure you end up with the very best possible product. You just need to structure your project in a manner that supports and allows for changes throughout the development cycle and the best way to do that is to break it down.

Break Up the Project
By breaking the project into smaller pieces, you’re giving yourself the opportunity to interact with individual pieces to test their feasibility in the bigger picture. You wouldn’t commit to driving a newly-built car on Mars without thoroughly testing each of the individual components, would you? If you’re going to be the one driving the car, you want to see that the heating/cooling system is functioning, the drivetrain is working, and the tires have been tested to ensure they will maintain traction over the Martian surface. You’re not going to put the car together, drive it through an off-road course one time, and load it onto a rocket — you will test each and every component before you even consider testing the final product. As you interact with each component, you may find that certain things you thought would work in the planning phase, won’t work in reality. By doing this, you’re finding issues early enough in the project to adjust course rather than finding out at the very end when changes are more difficult to make.

Scenarios like these come up all the time in software development. As a project progresses, if it isn’t tested at regular intervals, the risk of finding something that doesn’t work the way you thought it would is much greater, regardless of how much time and consideration you put into the planning phase. To make matters worse, the effort to make a change late in the game is more difficult. By breaking the project down into smaller parts and testing each one, you’ve got a greater chance of seeing your project succeed because you can catch things early in this rapidly-changing environment.

Additionally, breaking the project down into smaller pieces allows for greater flexibility when it comes to incorporating new information, requirements, or other changes into the project. Since both software development and building a Martian car both carry a high likelihood that information and requirements will change, it’s ideal to have a more flexible project structure that can accommodate the inevitable curveballs. You can prioritize the information and features so that the most important things are tackled early and with enough time to test and make any necessary adjustments.

Ultimately, the best way to tackle a project with such high potential for change is to plan ahead for that change and set up the project to incorporate the inevitable adjustments. Perhaps this is why most development teams prefer to work under Scrum and Agile practices than any other form of project structure.