We use many metaphors (or analogies) when trying to describe what goes into custom web development. Building a website or web application is technical, complex, and sometimes tricky. Metaphors like “building a house” are helpful in aligning expectations from sales to deployment to ongoing maintenance – but they’re never perfect.
This series will cover some of the main metaphors we use, both internally and with clients. I’ll describe some of the major and minor points that correlate – but also some of the nuances that aren’t the same. You can always jump to the other articles in the series, which compares website maintenance with owning a vehicle and the experience with a development agency to fine dining.
We’re Talking About Building a House, Not Buying
Building a house is probably the most common analogy used when describing what we do. And we don’t mean buying a house that already exists; we mean building one from scratch. Imagine all the planning and decisions which you (as the eventual homeowner) would need to provide to others so you one day take out your shiny key, unlock the front door, and step into your perfect living space.
We heavily leverage the five phases of software development with custom web development, and I’m mostly going to reference the discovery, design, and development phases.
Discovery, or Why Do You Even Want a House?
You may have already thought about blueprints as part of the analogy of building a house. Let me stop you though – we’ll get there soon.
This is the house you want, you’ve always dreamed of, made for you – you’re not picking from a few pre-existing models. How would you feel if you hired a builder, and a week later they brought you blueprints only knowing you want four bedrooms? Wouldn’t you expect to spend some time explaining as many details as you can? Wouldn’t you expect the builder to ask you questions you didn’t know you needed to answer?
This is discovery. We (as the builder in this scenario) want to know as much as we can because we want you to be thrilled with your dream home (er, website) and be proud that we built it. We want to make informed choices as we move into design.
In the sales process, you’ve told us roughly how many rooms, a square footage range, desired location, and budget. That’s great, but how do you want to use your house? Do you have a family, and if so, how big is it? Do you want to entertain? Maybe you and your partner have differing wants and goals. These are analogous to the questions we ask during Stakeholder Interviews. We want to know from the people who are most vested in the project what would mean success to them.
Let’s talk about your current house. What do you like, what don’t you like? We might use public records or have a house inspector visit to provide us more detail. This correlates to our Technical Audit, where we can review your current website, crawl public web pages, and/or have a developer or architect meet with you. You might invite us to walk through your house room by room, show us where you spend most of your time, and describe what you like and don’t like. This correlates to our Contextual Interview, where we can utilize screen sharing to watch a user use the website and ask questions throughout.
As we start understanding your goals, likes, and dislikes, we’re going to start defining a list of home features. This may grow and change as we continue to plan and build, but our designer and our architect will need this list to eventually determine all the details for your website. This is our Requirements Matrix. It’s not deep in details, but should cover the main points of the custom web development. For example, this list may indicate you want a two car garage but doesn’t indicate details like dimensions or flooring materials.
Design – or Unveiling the Blueprints
You’re ready to stop talking about your new house – you want to see something! This planning period, design, has the most obvious overlap between home building and custom web development. Hell, we share role names like designer and architect, and that’s not just coincidence. What may surprise you is what those two roles perform in these scenarios don’t match up exactly between home and website building.
You’ve seen it in film and tv plenty of times. An architect pulls a giant roll of paper from a large case of them. She rolls out a blue and white graphic that’s a few feet across in both width and height. But this time? It’s your house – the open living room with a few columns, a master bathroom with multiple windows to let in light. There are details of specific widths and general drawings for stairs, counters, and toilets. We commonly correlate this to our Wireframes. There’s no color, no ambiance – but you can now start to picture the result and you’re getting something tangible from the builder. But in our case, it’s not the architect that made these – it’s the UI designer.
What else does the designer do? The main thing you’d expect – the visual representation of your final home. The mockups. An artist’s rendering of what a photo will pretty much look like when it’s built.
But wait, what about the architect? Remember when she pulled the blueprint from a case? She has a number of other large documents that you might not ever see.
There are designs on the foundation of the house. This includes the physical foundation but also information on the land and details of the physical material expected in the build. This is akin to our Architecture Diagram, which spells out what hosting platform and services that will be used. It is commonly created by IT engineers conferring with an application architect or senior developer.
There are designs of all the pipes, wires, and anything that spans your property edges to the city or other properties. This analogy gets a little more vague, but might be attributed to any Integration Specifications if the website needs to communicate with other cloud services.
A Few Analogies in Custom Web Development
Once ground is broken and building begins on your house, there’s a lot of waiting. This is, unfortunately, very common in the custom web development space as well. You’ll be in contact with your project manager (same role name for us), and you might get occasional questions from our foreman (lead developer). We’re also orchestrating with the building crew (web development team), inspectors (quality assurance, or QA), and any others who will be necessary to successfully complete your project.
We could dive even deeper in the metaphor – how architecting and writing the code can mimic physical house structure… but that’s a wholly different article!
But not everything about building a house matches custom web development!
There’s a huge assumption being made when we correlate custom web development and building a house. That assumption is: you want to plan, estimate, build, and buy a completed house. In software development, that’s not the only path you can take.
You can use Agile Development as a methodology, which (very, very roughly) means building small pieces of your website at a time. It’s not like building one room of your house, then you move in, and then you build more rooms one at a time. That’s close, but it’s more like planning, designing, and constructing your kitchen counter, then doing the same for your cabinets, and floor; eventually, you’ll have a whole room and can keep going on the next. It honestly doesn’t fit the home building analogy at all.
Sign-offs, Implicit Acceptance, and Changing Requirements
In all phases of custom web development, we want and need your feedback! The last thing we want is for you to show up at your new house and have it look like we planned, but deep down you don’t like it… We ask for feedback, sometimes actual sign-offs, at points in the process such as at the end of a phase. There’s also “implicit acceptance” which means if we’ve been positively working with you through the planning and never received formal acceptance or rejection, we’ll continue to make progress as if it’s accepted. This is to protect all of us.
The foreman brings you on site to see the house halfway through the building process. You walk into the half-kitchen, and… oof. You saw the plans for the island, but now that you see it in person? It’s… not what you hoped. Is it your fault? Nope. Did the designer or builder do anything wrong? Nope. Can it be changed? Yes, but we don’t know how easily.
This is a great same-but-different scenario with software development. Change is inevitable, so it’s fine – just know changing plans in the middle of the initial build might be tricky! If you’ve watched any HGTV shows, you may have seen that an update may need a new design or might be changed on the fly. There’s just a cost of time, and sometimes dollars.
Next Up
I hope this article, and the others in the series, help to provide you with better context in your next custom web development or web application project. However, website projects don’t end at launch. Next in the series will be more focused on the owning / maintenance of your site.
How Building a Custom Website Is (and Isn’t) like… Owning a Car
