Build it like a physical product.

At least until the singularity, products of intellect still require physical interaction at some level. As such, they follow mechanical rules. You don’t fix a car engine by adding another engine on top of it. You fix it by taking it apart. You shouldn’t fix a digital product by adding more to it.

More code never made bad code better.

At one firm, a colleague of mine added this comment to the code on a website: “Because of bad decisions, this line must remain here…” The comment was a reminder of why things were not built properly. One bad decision was piled onto another. When we finally got to re-do that site, we took everything apart and rebuilt it.

Approaching digital products as though they are physical starts at the build. When we’re building websites, we often look to templates to give us a head start. Templates can be a simple set of HTML5 boilerplate files or elaborate packages of code that provide a default set of functions and styles. Templates are used in every industry. They are boilerplate contracts, lesson plans, a chassis used on different model cars.

There is nothing incorrect about using a template. But once that template provides an opinion, we can no longer use it to build something new. For example, if an agency specializes in building a specific kind of ecommerce website, it’s often better for them to build their own framework of styles, templates, scripts and functions that do exactly what they want. After all, if we were building custom furniture, we wouldn’t start with someone else’s blueprints.

When we approach building websites just as we would build something physical, we get a different feedback. Packaged templates can lead us astray because we don’t know the original intent of the developer. We’ll often realize that maintenance to a site that used a template takes much more time because we didn’t create the original rules. But when we start with what we need and build from there, we create an intent for our products that we can’t get from a framework.

By the same token, we must fix digital products as if they were physical.

I wrote the first good.simple.open book at least 3 times. I began writing it a couple of times as a continuous document. Then I realized that each essay was really its own little pep talk so I split the manuscript into separate files for the essays, wrote them, and reassembled the manuscript. I began editing. After 7 drafts, I realized I was going to have to do some major restructuring. I began to cut and paste essays from one location to another. It was confusing. It became laborious. I was writing this essay in the middle of the established manuscript and I realized I needed to follow my own advice. So I once again split the manuscript into separate files to fix it.

Taking a digital product apart like it is a physical product helps us examine the pieces individually to determine their value. When a thing is assembled, we often struggle to remember how everything works together. We’ll spend a lot of time following a thread of code or writing to see where it originated. But breaking the thing into pieces frees up our memory to work on one thing at a time in order to find the flaws or benefits.

When we find ourselves struggling in complex systems, the solution is not to add something new to them. Yes, we need established processes but we don’t need new process added on top of old process. We have to take those systems apart and rebuild them. Sometimes, rebuilding simply means stripping out the parts that are causing the problems. The same goes for our products whether they’re physical or digital. We have to open. We have to simplify to repair.

When we’re building a thing, we can start with the knowledge that the more layers we add at the outset, the more hours of maintenance we’ll add down the road. Instead of starting with a weighty framework, we can consider only building what we need. We can always “scale later” in the words of Getting Real when the need arises. Better to launch the product you built completely than a product that’s only 10% customized.

This is a chapter from good.simple.open: the values that lead to better work. It is only $5 on Kindle, or $10 in paperback.