Are you Simple-minded?

Daniel Krieg Dev Methodologies 5 Comments

Just a few months ago, I hired someone to install a picket fence in my backyard. I had three separate quotes of varying price and ultimately settled on the least expensive. The installation plan, among other things, consisted of determining where the corner posts would be placed, the height of the fence, the number and general location of the gates, and the spacing between pickets. I observed the contractor as he converted these simple specifications into the sprawling length of fence that creates the enclosure of pets safe area.

He used simple techniques to implement these simple specifications. Once the first picket was installed, an adjacently placed 2×4 ensured that the spacing between pickets was consistent. A string tacked and strung between each post ensured the proper height of each picket. The gates, though more involved, were also implemented using similarly simple techniques. Today I am very pleased with the end product and I marvel at the similarities between the process used to construct my fence and agile software development.

When a company endeavors to invest in a software product, what are some of the first considerations? Price, of course! While there are many other issues to consider, the budget ultimately dictates the scope of a project.

The company then needs to decide between several alternatives: do they lease, buy or build?

And, if they determine to build, is it implemented by existing software developers, newly hire employees, temporary consultants, or outsourced teams? And once the budget and team are in place the software development process begins.

There are many different software development methodologies from which to choose; however, taking a tip from my fence contractor, I will focus on one methodology in which ‘simplicity’ is a core principles: Agile. As defined on Wikipedia:

“Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.”

This brand of methodology emerged in 2001 with the publication of the Manifesto for Agile Software Development. As stated in its Manifesto: “Simplicity–the art of maximizing the amount of work not done–is essential.”

So what are the tools of the trade to enable software developers to construct software and yet maximize the amount of work not done? My fence contractor used things that are readily available: string, 2×4 boards, hammers, nails, screws, etc. He did not begin by re-inventing these items or devising clever ways to avoid using them. If he had, I am certain that my fence would have cost much more! So, while using an Agile approach to software development, we too should abstain from creating clever ways to avoid using readily available tools.

Just as a backyard fence has a repeatable architecture – the corner posts – so too do web applications possess repeatable architectures. The web layer exposes entry points to the application that delegates the user’s action to a service layer, which enforces business rules and typically access data from a relational database through some form of persistence layer. By adopting this repeatable design and avoiding the chance to invent some new wiz-bang framework, we take our first step into ‘maximizing work not done’. This is not to say that inventive initiatives should never take place. I myself strive for better and more efficient designs; however, it must be appropriately scoped, typically as a separate initiative and not hidden within the cost of creating a specific software solution.

Once the basic architecture is in place, we can begin laying the ‘pickets’ of our software solution. Maximizing the amount of work not done, we next turn to ‘User Stories.’ According to Wikipedia:

“User stories are used with Agile software development methodologies as the basis for defining the functions a business system must provide, and to facilitate requirements management. User stories are a quick way of handling customer requirements without having to create formalized requirement documents and without performing administrative tasks related to maintaining them. The intention of the user story is to be able to respond faster and with less overhead to rapidly changing real-world requirements.”

With the completion of each User Story, the final solution begins to emerge. It is very important within the Agile methodology to understand what it means to be ‘done’! “Every user story must, at some point, have one or more acceptance tests attached, allowing the developer to test when the user story is done, as well as the customer to validate it.” These acceptance tests should be automated where possible and clearly defined where manual validation is required.

My fence contractor brought several of his own tools with him: hammers, saws, air-guns, electric drills, etc. These tools enabled him to more efficiently and effectively complete the tasks involved in placing each picket. For the agile software developer, there exists similar ‘power tools’ which help to keep the task of implementing each user story as simple as necessary. While there are several target platforms (.Net, LAMP, J2EE, etc.), as a Java Developer my go-to ‘power tools’ (among others) are: Maven, Hudson, Subversion, Sonar, Eclipse, JPA, JSF, Spring, and JUnit. With a firm understanding of how to use these freely available tools, I am able to focus on the specific goal of placing each ‘picket’ (i.e. the Use Stories) of the software solution for any given sprint of the project. The better I know these tools, then the less struggle I have when implementing business functionality. I can settle into a predictable and sustainable pace.

I believe that companies that invest in building software solutions all want to be pleased with the end product. But, it is not just the end product that will remain in their corporate memory, but the process that got them there. When misplaced ingenuity, unnecessary and excess work efforts, and misguided attempts to use unfamiliar tools divert a software project, the total costs and negative experiences are bound to increase. Remember the KISS principle (Keep It Simple, Stupid!) and adhere to the Agile Manifesto: maximize the amount of work not done! The principles espoused therein really do work, and are not limited to software development.

I clearly observed that my fence contractor innately adhered to the Agile Manifesto principles. In his opinion, his way of working was common sense and worked well enough for him. I have him to thank not only for the building my fence, but for also reaffirming my belief in simplicity!

— Daniel Krieg,

About the Author
Daniel Krieg

Daniel Krieg

Share this Post

Comments 5

  1. PM Hut

    Hi Daniel,

    I don’t understand, the way he installed the fence seemed to me as much more waterfall than Agile. He just proceeded by phases, which is how Waterfall works. He didn’t even revisit old phases.

  2. Daniel Krieg

    Thanks for your post! As you pointed out, he just proceeded in phases; however, the phases in Agile are not the same as phases in Waterfall and this IS the key distinction. There is in fact also a distinction in Traditional Waterfall and Iterative Waterfall but I assume you mean Traditional Waterfall.

    These are the phases of Traditional Waterfall: (images from ‘The Agilista PM’

    These are the phases of Lean Development (one form of Agile):

    In my humble opinion if my contractor had used a Traditional Waterfall method here is how things would have proceeded:

    PLAN: A detailed specification would have outlined the precise location where each screw and nail would be placed. The exact number of pickets, posts. rails, screws, and nails would be accounted for. The specifications would state the precise measurement of each rail, the depth of the posts, and the exact amount of concrete required. The cost of each of these items and the cost of labor would all be itemized in the specification.
    BUILD: If the Plan was approved the build phase would be rapid, with no testing performed during this phase. This means that a ‘best effort’ would be taken to implement the specification (i.e. if the specification was wrong by having too few or too many pickets, the contractor, in trying to conform to these specifications, would have to adjust other qualities, say the spacing between pickets)
    TEST: After the entire fence was constructed the contractor would then need to re-measure the spacing between each picket (as this was not necessarily the focus during the build phase). If the spacing was inaccurate the pickets would need to be pulled off and entire lengths of fencing replaced.
    REVIEW: Only after everything was completed would the contractor ask if I was satisfied with the location of the gates, the spacing of the pickets, the location and number of pickets, the exact location and quantity of screws and nails. etc. If I was unhappy with any of these implementation details, more rework would be required!

    With a Lean Development approach we are able to iterate each of these phases with the placement of EACH picket. While this approach is much more interactive with the product owner (me) it shortens the feedback time and addresses risks early so that adjustments can be made ‘on the fly’ rather than after the entire product is implemented.

  3. Michael Green

    I’m not sure I agree with fence building within an agile way. The requirement of the fence is to hold in pets. You cannot iterate thru this construction with any meaningful outcomes until it is completely finished.
    If you build a section at a time, or just put up the framing for the pickets, etc – you always have a hole for puppy to run loose.
    It would be like building a financial system that takes deposits, but next week the payments come. You can’t deploy it like that 🙁

    The real agile comparison to getting end results with appropriate budget would be this:
    Requirement: I want a blue picket fence that keeps my big dog in the yard. It needs 2″ pickets every 6″.
    Implementation: Build fence with 2″ pickets every 6″
    Look at budget…also have new requirement today: Now, I want a puppy. Go add a picket in between each other picket. Done.
    Success! Dogs kept in.
    Look at budget. Very close… Let’s skip the painting.
    Success to the real biz requirement.

    just a thought.

  4. Daniel Krieg

    Well, this IS an excellent point. The goal of Agile is to produce a ‘finished product’ that is ready for production after each sprint. So I do agree that if I told my contractor to conclude his development efforts before all of the planned iterations (i.e. picket) was completed that there would be a huge hole in the functional capabilities of the fence. However, from my perspective, this is a risk that any Agile software project faces as well. The project that I am currently on had 20 planned iterations. The first few iterations addressed more technical concerns that needed to be in place for most of the business features that followed. This is equivalent to ‘sinking the posts’ of my fence. If the client had discontinued the project at this stage, he would have something to build on later but would not have anything useful.

    Most Agile projects do some up-front ‘Sprint Planning’ that outline the number of iterations. These iterations can be increased or reduced but there is usually a set of iterations that you ‘cannot live without’. With respect to my fence contractor, he was in the same position. If I had determined that I needed to ‘shorten’ the scale of the project he could have repositioned the posts and delivered a functional but shorter scale solution, though it may not have been a simple change and I would have not been as happy with the end product.

  5. Michael Green

    In response to your sprint planning above: I’m sure some folks would love to have a productive first sprint. If you really want a productive sprint 1, then do planning and don’t call it a sprint. We always have a sprint 0 where we ramp up, get environments going, utilities, servers, etc in place. Yes, it costs $, but it has to get done. The problem the whole industry has is they estimate finite tasks and forget about things like user interface tweaks, security, performance and simple architecture plans.


Leave a Reply