Construction metaphors are commonly used to describe the software development process to outside observers. It’s easy to see why this is a popular metaphor, it often appears like a structure being built to the outside observer. It’s not like building a house though, and describing it that way erodes confidence in the process for these outside observers, who often have a real stake in the delivery of the results of the process.
What are We Doing Day to Day?
The vast majority of people who call themselves software developers, software engineers, programmers, or any other of the myriad of terms we use to refer to ourselves, work for a company that offers a product or set of products in a competitive marketplace. As one of these people, I’ve observed a pattern in the way we work by ourselves, with our peers, with our customers and with our leaders (commonly referred to as The Business). We often conceptualize this pattern either within ourselves, or to external observers of the development process, through the use of the construction metaphor. Here’s what happens in reality, how it maps to the construction metaphor, and where the metaphor breaks down.
The Process Leading up to the Delivery of Software.
- Some requirements, requests, user stories, whatever they get called in the organization, come in from The Business about some change that needs to happen in the product on which we work, or something new that needs to be built. This is very similar to someone going to a construction company and asking them to build a house for them.
- Sometimes we know exactly what to do to solve that problem. That’s not the situation I’m talking about here. In that situation the construction metaphor holds up fine.
- The more frequent situation is that we don’t know exactly how to create what is needed yet. Now the construction metaphor starts to fall apart, because you would never hire a construction crew when you don’t have confidence that they knew exactly what they were doing. However, this is not necessary for a software development team. As software developers we have internalized the reality of not knowing everything we need to know, because it’s impossible. There’s too much for one person, and things change very quickly. What we know now will not be relevant forever. As a result, we focus on improving our ability to learn what we need to know quickly enough to be effective in delivering it. Somewhere else, someone is doing the same thing and we know that if we go long enough without improving our knowledge, that person will eventually replace us. This is the first hint that we are competitors and not construction workers.
- If The Business has some level of understanding of this, we can be honest with The Business about what we know and what we need to learn. If not then we often pretend like we already know what to do because that’s what The Business expects.
- Either way, The Business wants to know when they can expect to see results and we are obliged to give them some insight into that through estimates. These are often Real-Time estimates (give them a completion date) or Level of Effort estimates (These are the things we have to finish to get there.) This part of the process usually reinforces the usage of the construction metaphor because it asks people to visualize it in a linear fashion. If we do this first, then this, then this, it will be done after all of those steps. Just like building a house. However, we know that most software doesn’t get delivered in a linear fashion. Small, incremental changes to every level of the stack are necessary throughout the entire development lifecycle.
- Once The Business has confidence in what to expect and when, they usually leave the development team to do it’s thing. Sometimes they don’t interact again until the promised date, sometimes they interact on a monthly/weekly/daily schedule to get regular updates.
- Now we actually begin the process. With room to work, we set out learning what we need to know in order to solve the problem. This is usually done with a great amount of intensity and focus. After all, you can’t have confidence in any estimate or strategy before you learn what you need to know.
- Now the next step can also feel like it fits nicely into the construction metaphor. As we learn, we produce artifacts than can be seen by The Business. Same is if the home owner drove past a building site and saw the foundation being poured for their house, or the framing being constructed. Unlike construction, a fundamental component of the structure of software can easily be torn out and replaced. For example, you can’t replace the foundation of a building without destroying the rest of the building, but you can replace the operating system that your application runs on, with some other constraints, without having to destroy your entire application and build it from scratch. So the construction metaphor here again falls apart. From the outside looking in on a software project, it may appear more complete on day 10 than on day 15.
- Regardless of how we choose to think of what we’re doing, or how we attempt to explain it to The Business, we create small pieces of code, put those pieces of code through varying degrees of process, then integrate them into our code base. We also pull out pieces of code. This creates a vastly different visual representation than seeing the foundation, then framing, then roof, etc., etc. go up as a house is built. If you’re looking at a software development project in the early stages, it may appear mostly complete one day, then as if it hasn’t even started the next. The path to completion does not appear linear to the outside, and they shouldn’t expect it to.
- Now we move closer to the professional competition analogy. As the overall solution becomes clearer in our minds, our interactions with team members and The Business become more intense, more focused, and more collaborative. Very similar to the last few practice sessions for a team before an important competition. Now we’re looking more like a team of professional competitors preparing for the next competition.
- We then start to expose things we’ve built to external people, usually customers. Sometimes in a large, grandiose reveal of alot of functionality, sometimes in smaller, more incremental pieces. Regardless of which way we deliver, we then have respond to feedback that we get from the customers. If we don’t respond fast enough or effectively, they will stop using what we’ve built and we will lose them. This is how score is kept, and how the competition is won and lost.
The Competition Starts with Delivering Something
- It starts the moment we deliver the first piece to an external customer. From that point, we’re on a real clock. The score is determined by the customer’s behavior within and reaction to our offering. Changes must come fast and be on-target in order to affect the score. And we have real metrics from the marketplace on how we’re performing. If customers leave or stop using it, then we know we’ve lost. If we get more customers and see them using it more frequently, we know we’ve won. or are at least winning.
- If delivering to customers signals the beginning of the competition, then everything else leading up to that is practice. Just like professional competitors, we spend alot more person-hours practicing than we do actually competing.
- Also like a sports team, all other things being equal, the team that practices most effectively has a better chance of winning the competition.
- So, it stands to reason that the better we get at practicing in a way that develops both the correct skills and teamwork, the better chance we have of increasing our score at when we compete.
How do We get Better at Practicing?
The majority of time spent creating software isn’t contained in the time it takes to write, commit, and test a particular piece of software. It’s in the time it takes to for the software developer to build an internal mental model of the overall system, and how the piece fits in to that. Once that mental model is built, the software itself can be rewritten in an insignificant amount of time. The creation and maintenance of this mental model within each developer is far more important to the end deliverable than any particular piece of written code.
These mental models aren’t as stable as something like learning to ride a bike or memorizing the alphabet. They take repetition to maintain and deliberate practice to add definition to. The moment you stop thinking about a mental model, it incrementally loses definition and recall-ibility within your mind.
This is much like practicing for a competition against a specific opponent. You are coming in with mastery of fundamentals, but it will take a unique combination of those fundamentals in order to win the competition. You practice that combination exclusively and intensely right up until the last moment before the competition. You also know that any distraction from practicing those fundamentals will lower your ability to perform in the competition.
There are lots of examples of how deliberate practice has lead to the success of and individual or a team in a competitive environment. There is one thing they all have in common. An intense focus on and mastery of fundamental components of a successful strategy followed by an equally intense focus on the progression and interaction of these fundamentals within the framework of their strategy.
The most important thing we do as software developers is focus our practice time on developing the fundamentals necessary to successfully executing our strategy. Communicating this fact clearly to our outside observers and establishing their trust in this process will allow us to work in an environment that encourages the most effective approach to delivering software projects.