The developer’s true goal

Having been a part of several large, long-term products and projects, I’ve come to a bit of an epiphany on what our goal as developers truly is.  For the longest time, I believed that our goal was to write good software.  That was a little nebulous, so you start to see distillations towards high quality or maintainable software.

All of these miss the mark.  Our true goal is to write as little software as possible.  In order to provide the highest long-term value to our customers, any solution should absolutely minimize the amount of software created.

Why should we minimize software?  The most valuable software, most used software, easiest to change, maintain, understand, least complex all have one thing in common – they minimize the software developed as much as possible, but in a variety of ways.

Bloat Sources

Traditionally, movements like software craftsmanship and even XP tend to focus on the engineering aspects of minimizing software.  These are important sources, but focusing solely on these ignores more large sources of bloat.  If we look further up the development pipeline, the requirements fed in to the developer’s process, we can also see sources of bloat from:

• Complex features
• Worthless features
• Confusing features
• Gold-plating

Complex, confusing and worthless features are those that won’t be used by the end user of the system.  Additionally, complexity carries a maintenance cost that is often glossed over or ignored because of the assumption that complexity does not need to be re-learned when the component needs to change.

The bottom line is only the most important, most useful features should be developed.  Everything else should not.  Putting it in modern terms, the joke about the “new twitter” page is that the “old twitter” page is what Steve Jobs would have created had he seen “new twitter”.  Users want simplicity.  Complexity leads to confusion, lost users and support calls.

###

Fighting Bloat

In our projects, we strive to fight code bloat with a two-pronged attack: develop the minimum set of features to release to production, and with as little code duplication as is cost-effective given the constraints of the project.

We can do as much research as we can to determine what features will be used, but that can vary from greenfield, new product development versus upgrading or replacing existing systems.  But in either direction, if we focus on releasing usable production software, software that is actually used in production, we’ll optimize for the features that most of our users will use most of the time.  For both greenfield and brownfield, those are going to be the most valuable features.  Side note – this is where many “rewrite” projects go awry – the assumption that ALL features have equal priority to be transplanted to the new system.

By opting for a more continuous delivery model, we can better adapt to changing users needs, as well as prioritize features for use in production.  For existing systems, this can be a lot easier question to answer.  When our teams look to replacing legacy systems, and these systems are ALREADY in production, it’s merely an exercise of profiling at all levels of the system to determine what modules/applications/databases etc. are being used.

On the flip side of the coin, fighting duplication removes bloat from code that we’ve already committed to writing or already exists.  Fighting duplication is equally as critical as fighting feature bloat, but not more or less!  The entire development pipeline from “concept to cash” as it were is important to optimize, not just the middle, hands-on-the-keyboard stage.