Comparing software development to “building a house” is one of those analogies that sets my teeth on edge. It oversimplifies everything that goes into designing and building a good product, and it also creates some unrealistic expectations in terms of estimation and effort, both for development and testing. I heard it yet again recently, and it just shocked me that it’s still being bandied about these days. C'mon, don’t act so shocked, you probably have said it yourself or heard it said at some point. I know I have, on both accounts. And you know what, it's OK, I’m not here to judge you. Unless you are still saying it, then I will judge you quite harshly :)
There was a time when this was far more true of an analogy than it is today. As someone whose original passion was "architecture", as in, creating blueprints for houses, it made a lot of sense. Plans are good, and who doesn't like structure and rules? You see, there was a time when software was created by pouring over designs for the right "feel", sometimes for days or weeks to establish a solid foundation. Remember when SOA and OOP were the hot new things? Before a single line of code was written we had UML diagrams and if we were really fancy stubbed out methods for the developers. And sure, when building a house every angle is inspected, measured and re-measured, the location and size of every supporting wall is verified, every window placement is compared to housing codes, all before a single piece of wood was sawn or hammer was swung. Then contractors are set loose with the specs to build the house according to a well laid out plans. Except what if by the time it was delivered, the homeowners didn’t want to actually live in the house they asked for in painful detail without some major rehab? The colors are all wrong, the yard is too small, the garage is too narrow, there aren’t enough bedrooms. Could you imagine?! In home construction, nobody sane would do that, and yet it happens all the time with software. Well, there you have it, the analogy is already somewhat blown. But there's more.
You know you've been on THAT project. You know the one - late, way over budget, customers are screaming that it isn't what they asked for even though you have signed requirements specs that say it is. Heck, even if you are just NOW getting into software development you're probably going to experience this still at some point. Particularly if you work someplace that is still stuck in a Project Plan driven mentality, a.k.a. "Waterfall" ::cue dramatic music:: Who just let out a little shudder? Now don't misunderstand, I'm not a hater, waterfall-based methodologies can work well in some scenarios, but generally even waterfall enthusiasts are not following a strictly traditional waterfall approach. And to be fair, even "real" waterfall, as I learned it back in college in the late 90's, dictated iterative practices. But often that little nugget gets lost in translation in favor of forever marching forward through a seemingly unending tunnel of quality gates, attempting to hit arbitrarily established milestones. So back to my original point. Building software is not just like building a house, or maybe the more correct way of conveying my thoughts is that building software SHOULD not be like building a house. And if it is at your company, I do not want to work there. Unless you're looking for me to facilitate an intervention of sorts. Let me explain...
Imagine you want to have a custom house built. And let's say you already know more or less what you want. Tudor style, 3 bedrooms, 2.5 bathrooms, eat-in kitchen, with a detached 2 car garage. Maybe you even have an existing blueprint because plenty of houses like that already exist, so why re-invent the wheel right? Work begins, and the house starts becoming real. But even after several weeks of work, while things may start to look like a solid shell of a structure, you cannot live in it. Well, not legally anyway. There is probably no plumbing yet, certainly no electricity, perhaps the roof is not even yet in place. You also cannot decide you now want something more Spanish style, single storied and sprawling, with an attached garage and a courtyard garden in the center. Well, technically you COULD decide to do that but it would require MASSIVE structural rework, new permits, perhaps a different construction crew, and of course SIGNIFICANTLY more time and funding to complete. OK, so I suppose this is one parallel you can draw to software development, but again this is more of an issue in waterfall shops, particularly if you are already deep into development before someone realizes a much earlier decision was a poor one. Many thousands of man-hours will get wasted, people may lose their jobs, customers will be unhappy, and you likely will end up with a Spanish tiled, Tudor style home with a semi-attached 2 car garage that has a courtyard in the center of it. So with building a house, you will not realize the value of the product and be able to use it until the last finishing nails are hammered into the last room, and major feature change requests will almost always be unfeasible to honor even early on in the construction process without MASSIVE negative consequences. Do you want to build or pay for software that is built that way? I certainly don't.
I don't see housing contractors ever building homes one fully functional room at a time, allowing the home owners to live in it long before it is finished. I do not see them redesigning the blue prints and only ordering enough supplies for each room about to be built to incorporate changing design trends, evolving safety codes, nor do I see them accommodating the ever-changing whims of the owners. "Oh. You've decided you want an open floor plan instead of separate kitchen and dining rooms? No problem, we're just finishing the main bathroom and haven't even framed the rest of the first floor yet..." Yeah, no. I also do not see those contractors getting the homeowner's signoff on each finished component before moving on to the next one, incorporating feedback and change requests, continuing this iterative process until the house is complete. Maybe you're thinking, "well, we don't have the ability to do any of those things today when we design, code, test, and deliver software either". I'm sorry to hear that. We should talk, there's a 12 step program to help you, and you've already admitted you have a problem which is the first step to recovery. Well, there ISN'T a program, sadly, but I often joke that there *should* be.
Now this is an easier problem to solve in software. Software teams CAN be flexible, adapting to changing needs of end users. Software can be delivered in small, working, usable pieces to deliver value as soon as a few weeks after the project begins. And it doesn't have to cost more. It can actually cost FAR less if you do it right. This is part of the reason I am such a proponent of Agile and Scrum. But honestly that is another topic and this post is already long enough so we'll defer that conversation for now.
So here is one place where building a house and building software ARE remarkably similar. Estimates. Regardless of what a contractor tells you, no one knows for sure exactly how long building a house (or software) will take. Sure we can ballpark it, but every job is different. People will sometimes push back and call that a copout consulting answer, but it's the truth, and I try not to make a habit of lying to the people paying me to work for them. And if you demand exact delivery dates, are unwilling to compromise on features (maybe the rotating shoe rack in the closet really isn't NECESSARY), and have immovable end dates, well, you may want to refer back to the 12-step program that I mentioned earlier. No one can account for bad weather, people getting sick, catastrophic hardware failures, or that the latest version of the .NET framework that was just released has added complexities that cause even the most experienced programmers to take 50% longer to get things done for a few weeks. Should you go so far as to expect the team to commit to dates, deliverables, AND cost - to the point they take a hit if any of those things slip - well, prepare yourself for a sandbag big enough to hold back a hurricane, or to have people eventually seek alternate employment. NO ONE wins. And yet these kinds of unrealistic expectations reoccur everywhere I turn in the tech world. Maybe someday more software teams will be able to hold stakeholders and end users accountable for the quality of requirements, and refuse to take on change requests after work has begun without serious concessions, seems logical and fair. Ahhh, dare to dream :)
So now can we stop comparing software to building houses? Please and thank you.