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, email@example.com