Inhabitants and motion
In physical construction, the inhabitants and events that play out in buildings are the only factors we can use to create metrics for the value of the building. We can only measure the value of a construction by those for which the building is intended, whether as their place of work, rest, or play. How those events play out, whether they are effectively performed or fit neatly into the space, can be used to describe the suitability of the building.
In code, the end user and their activities are the critical measure. What the user gets out of their interactions is the only metric by which software should be measured. But this is not always the case. Software is purposeful, and whether it can be found and used to complete a task effectively determines whether it is fit for purpose. The inhabitants are the users, and the events that play out are the users’ transactions, actions, and interactions.
How do these values differ? Well, referring to the insight discussed earlier, there’s a big difference with maintenance. The built object needs to be maintainable for physical construction, whereas, for software, the product need never be repaired. Instead, it is the code that constructs the product that needs to be revised. In some situations, even the data can be thrown away, but usually, it’s just a minor migration task, even when wholesale replacing an application. This is quite different from physical building maintenance. We can’t just tear down a whole house and replace it. People keep their stuff in there.
But this is not always the case. With regards physical buildings, one counterexample is a hotel room. If there is something wrong with your room, the hotel can offer to move you. This is effectively the same as replacing the building. On the IT side, there are counterexamples where software must be maintained rather than replaced. The way servers used to be run was ‘as pets not cattle’, so uptime was extremely valuable, and the ability to make changes to the running system was considered a mandatory requirement.
Physical building maintenance is akin to changing the codebase while your application runs. While possible in most programming languages, this activity is unusual in the present climate. We generally restart services or shut down applications while installing new versions. The feature is built into Erlang; you can roll your own in Python, but C and C++ are more complicated. Stefan Reinalter’s Live++ is an excellent example of what can be achieved. But these are all exceptions to the rule. However, not all systems can keep the product in place; some need to replace the whole running executable. Those that mutate their behaviour to achieve change and leave the source untouched are more like physical buildings. Because we don’t reconstruct with every design change, the design should include protection from things that are not yet present.
The natural software maintenance pattern is to tear it down and build it back up. Unfortunately, this transfers into how we consult with the client. Developers second-guess software users and make changes without informing them. With physical development, it’s relatively uncommon. For one thing, maintenance and change costs time and money, and the maintenance will intrude on the physical location, so the client is aware by default.
The other difference is that with physical construction, even if the design is uniform across a selection of buildings, there’s still a chance to customise specific structures. When the land is a bit smaller or lower, or a road bends a little towards the end, we can make adjustments and local adaptations can play out.
When a design is improved, existing buildings are not automatically updated. This is clearly not true with software. Rollouts and updates are now the norm with software. I cut my teeth on writing software for games consoles. When I began my career, consoles didn’t have network connections, updates, or patches. Those games were almost the same as physical buildings. If there was a bug in the game, it would be in all copies and would never be fixed. Today, almost every game over a certain size has what is known as a day one patch. The process of certifying a game as suitable and bug-free as possible is slow enough that a development team can work those extra weeks to produce a new version with significantly fewer bugs. It’s a strange world we live in. Hardly anyone but the testers and reviewers play the first version passing certification.
The software user has a discontinuous interaction with the application. One day, the application will be different, and there is little opportunity to go back. Changes are thrust upon the user whether they like them or not. The money and time they invested in the application are not seen as a reason for the developer to consider the user’s point of view. Instead, the goal is always new users.
As stated earlier, we don’t always use the value of the software to our users as the metric of success. New users are new sales. Sales are money, and money drives the actions of most organisations. Sometimes, there are romantics who believe there is some greater purpose to their work. But even if you are trying to make a delightful and practical tool for your client, you’re only being allowed to by the organisation because it senses your actions are profitable overall. Harsh, I know, but unless you’re in charge of the organisation, such as with some open-source initiatives, then ultimately, it’s probably money pulling the strings.