Lessons learnt from building a tiny inspector extension

This tiny extension is a nice example of how Moldable Development works over time.

We created the initial view about 3.5 years ago. At the time, we wanted to provide an insight into what does a missing file mean (i.e., is it just the file that's missing, or an entire folder structure?). It served that purpose just fine.

More recently though we wanted to also affect the problem we were informed about. So, we extended the tool.

There are a few things to observe.

First, we started from the viewing use case. The edit ability came later on. This is a pattern we see over and over.

Many people focus on tools that edit. We think there is great value to extract from viewing tools. Indeed, we can benefit greatly from editing tools, but they have to deal with many, often detailed, issues that require more attention and are therefore more expensive.

Looking at the implementation: the first view-focused implementation took 24 lines; the second, edit-focused one takes 58 lines of code.

This leads us to the second lesson: tools evolve over time together with your needs ... and wishes.

The ability to create custom tools is important. The ability to adapt them as the needs evolve is even more important. Why? Because the tools you have induce your behavior.

It is less obvious at first, but as we got to practice Moldable Development for several years we know that it's tempting to get used to tools. Instead we choose to ruthlessly control our environment so that our behavior is attuned with our current needs rather than our current tools.