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.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in Process. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Steve

    There haven’t been many places where I’ve worked where the developer has final say over whether a features should be implemented or not. Actually, there has been only one, the startup where I was the CTO. Everywhere else, a developer might resist, or say something is stupid, but it’s rarely his/her call on whether it needs to gets in or not.

    This leads to the bigger problem, in that once a feature has made it into a published version of your software, it’s very difficult to pull it out.

    If only 5% of your customers utilize a features, removing it will cause them to freak, and your Sales/Marketing/PR people really won’t care that other 95% of your customer base at the very least weren’t impacted (and maybe even benefited) from it’s removal.

    While I don’t disagree with anything in your post for a theoretical stand point, in reality doing things like developing a minimum set of features before releasing into Production isn’t always possible.

  • RichB

    You’ve missed what I view as the best argument for writing less code – fewer bugs.