I once had a client who I was helping to build a piece of software to be used by other business units in their company. The project had been going on for quite a while and the business unit responsible for its development was very eager to get the tool into production.
The other business units were starting to lose faith; each time they were presented with the software there appeared to be lots of issues with it. It wasn’t just that there were issues, it also seemed to be taking the development team a long time to resolve issues.
As you could imagine the sponsoring business unit was very keen to find the shortest path to resolving those issues and getting the users onto the tool. This was creating a ‘to kill the project’ or ‘not to kill the project’ situation. Rapid progress was essential.
During the course of the project I often found myself involved in prolonged and somewhat heated discussions with my client about the need for balancing working on features with working on foundation. Features are the capabilities that the software users see. Foundation is the stuff behind the scenes that enables the delivery of the features.
From my client’s perspective their software was mostly ready. The problems, as they saw it, were issues with the features. Sure they saw some risks associated with using the platform, but those risks were acceptable given the business situation. Conclusion: foundation was mostly sufficient to take them to where they needed to go, features were where they needed to focus. I was never able to convince otherwise.
Not Like Constructing a Building
I’ve since come to believe that the reason I wasn’t able to make much progress with my warning was because what I meant when I said ‘foundation’ and what they thought I meant was different. At the root of that misunderstanding was a very deep difference in our understandings of the nature of software development.
I’m thinking now that whenever I said ‘foundation’ my client was imagining something akin to those big concrete beams we see in parking garages. Perhaps they thought that whenever I was warning them to pay more attention to the foundation I was warning them that without the right beams in place their product was going to fall over. Foundation does to some extent refer to that aspect of the software, and there was some risk of that on this project, but that is only one small aspect of what I meant when I said foundation.
Let’s look at how I defined foundation earlier: “Foundation is the stuff behind the scenes that enables the delivery of the features”. So yes part of the role of the foundation is to provide a solid running platform of software components and technologies. However, more importantly foundation is about having in place elements that enable the development team to understand what has been built, why it has been built and how to make changes rapidly with confidence.
Not an Either/Or Proposition
I believe there was another misconception going on whenever I talked about paying more attention to the foundation. My client seem to see it as an either/or proposition: a developer is either working on features or working on foundation. That is a misunderstanding of the nature of software development and of how features and foundation relate to one another.
We work on foundation in order to facilitate making more rapid progress on the features. We measure our progress on the foundation work by how much it positively impacts our feature work. When a project is having problems addressing issues in features then deciding to focus more on features rather than foundation is essentially a decision to double-down on exactly the same bet that has lead to the troubles in the first place.
What’s at Stake
When we talk about foundation in software we aren’t talking about the big concrete beams that are supporting the product. We’re talking about the big concrete beams that are supporting the project. When a project is in trouble it’s the foundation which is almost always the source of the troubles.
A product falls over when it fails during operation. A project falls over when it fails to produce the desired results. A lack of attention to foundation might not make the product fall over, but it very often makes the project fall over.