Coming off of my ‘sprint in the life’ mini-series of daily blogging for two weeks, I was very tempted to write this next post on the Agile principle of sustainable development (because I can assure you that any longer than two weeks of daily blogging is not sustainable for me).  But something I was reading earlier this week got me thinking about a different principle and I wanted to talk about it while it was fresh on my mind.  In the Agile statement of principles, this one says, “Simplicity – the art of maximizing the amount of work not done – is essential.”

The book I am reading is Behind the Cloud by Marc Benioff, CEO of salesforce.com.  In this book he shares 111 ‘plays’ from the ‘playbook’ that he followed in building salesforce.com into a hugely successful business.  There are a lot of interesting ideas in this book (check it out here: http://amzn.to/13vYho3), but Play #53 is the one that sparked my thinking.  Here is a chunk of this section from Marc’s broader chapter on technology:

Our philosophy was to write code that lasted for the long haul… “Do it fast, simple, and right the first time”… A typical programmer at this time had the mind-set that big and robust code was beautiful.  We didn’t agree; complicated code becomes bloated and slow.  We aspired to trim the code to be as minimal as possible.  That type of architecture also made it easier to identify any problems as we scaled… Software development is incredibly complex.  There’s great pressure to get a prototype out and to cut corners in order to meet deadlines… We knew that the initial prototype set the foundation for the entire product.  If it’s messy out of the gate, it can’t hold up over time.  In fact, it’s common for the code to explode as developers try to transition and scale.  These so-called success disasters have plagued the software industry.  They don’t have to.

From my perspective, these ideas resonate with the Agile principle of simplicity.  This approach begins with the pre-work done before any coding starts.  It involves the product manager and designer creating simple product plans with intuitive and market-validated designs.  Knowing that the market wants, likes, and will pay for the proposed solution before building it is crucial to maximizing the amount of work not done, since no one feels encouraged by long hard work on a product that no one ever buys.  The pre-work continues as the development team together with the product owner thinks deeply enough about the problem to find the simplest solution, delving into the interdependencies ahead of time to keep the logic and structure as simple as it can be.  This is not the kind of documentation-heavy product specification process typical of more traditional approaches; instead it involves collaborative thinking and conceptualization of the approach to take so that the team will be ready with the cleanest development path identified.  This tough collaborative effort before the work of coding begins helps to make the development process simpler.

Once actual development begins, the commitment to simplicity entails letting the product owner define the business needs (user stories) and the development experts find the cleanest way to code the solution.  Business team input into actual coding tends to complicate solutions, while allowing those with the deepest engineering knowledge to build out the best solutions is much more likely to result in cleaner and simpler code.  Simplicity also involves a conscious decision not to push for or settle for ‘adequate’ solutions that developers know are riddled with potential problems; instead the team must be encouraged and freed to strive for solid and reliable code that is well tested both on its own and as part of the system.  Introducing code that developers know to be poorly designed only complicates a product, adding burdens both to those who support the product and those who will further enhance it in the future.  The actual work of product development adheres to a principle of simplicity when more time is taken to do something right, with the result that the code is cleaner and the processing faster.

Once features and fixes have been released, an ongoing commitment to simplicity means that the team will regularly revisit existing code to simplify it further.  As new techniques are learned or new approaches investigated, a strong development team makes a commitment to clear out technical debt regularly – not just when things blow up.  The commitment to refactoring that keeps the codebase simple requires hard work, as there are often multiple attempts at simplification before a truly great solution emerges from the team.  The pre-work of discovering the simplest solutions and the development work of coding with simplicity are further enhanced by the post-work refactoring and maintenance that keeps the ongoing codebase and the underlying architecture as simple as possible.

This may sound like a lot of work – and that’s because it is; simplicity isn’t easy.  Especially in a collaborative scrum environment (as opposed to a ‘command and control’ environment where one person just tells everyone what to do) the business and technical complexities are compounded by relational complexity.  Following the Agile principle of simplicity takes hard work for the team.  If doing things this way takes such hard work and requires the team to be aware of complexities, it is reasonable to ask if this is really a ‘simple’ way of developing software.  Does this approach truly ‘maximize the amount of work not done’ in development?  Is it even possible (as salesforce.com strives for and Agile advocates) to do things ‘fast, simple, and right the first time’?  For my answers to those questions you’ll have to read my next post because, in truth, it’s not that simple.