Take This: It's Dangerous to Go Alone - Craftsmanship and Agile Software Development

Wednesday, May 11, 2016 9:15:00 AM Chuck Charbeneau

0 Comments

In the early days of Agile Software Development, agile was actually an adjective. Agile Software Development was a complete thought and process, and it focused on the process by which software was created by dedicated software developers. Extreme Programming (XP) was the norm and it was understood that good development practices created quality software. Unfortunately, although many XP practices can be found in scrum, not since the heyday of XP have they been a focus.

Over the years, as scrum has evolved, the term 'Agile' has evolved as well, transforming from an adjective that described the noun 'software development', to becoming a noun on its own; a thing that, itself, is being implemented. By losing the 'software development' from the end of the phrase, many in the software industry feel that a key focus has been lost with regards to our craft, and that there is danger in pursuing the agile process around software development without a focus on the aspects of agile software development that codify good development practice.

As someone who considers himself a Craftsman, who acts as a scrum coach to several teams and tries to embody the practice of scrum, I believe that the Agile Manifesto [http://www.agilemanifesto.org/] is an important first step to the creation of self-organizing, delivery focused teams. I also believe that it is specifically lacking in discussion that focuses on the behavior of the developers, the quality of the software they produce, or the goals of the team in how they respond to change.

The Manifesto for Software Craftsmanship addresses these concerns specifically, complimenting and extending (without changing - in good SOLID practice) the Agile Manifesto with words specifically focused on the developer.

As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:

Not only individuals and interactions, but also a Community of Professionals Not only working software, but also Well-Crafted Software Not only customer collaboration, but also Productive Partnerships Not only responding to change, but also Steadily Adding Value

That is, in pursuit of the items on the left we have found the items on the right to be indispensable.

We are tired of writing crap

“We need to act like other craftsmen and start "signing our work”. - Andrew Hunt and David Thomas, The Pragmatic Programmer (1999)

The Craftsmanship movement is an approach to software development that emphasizes the coding skills of the software developers as a primary tool in the success of the team. It is a direct response by many software developers to the perceived ills of the mainstream software industry, including the prioritization of financial concerns over developer accountability, time to market over code quality, and the sacrifice of developer continuous improvement as wasted time and unproductive. How many times have you been asked to:

sacrifice training time
cut corners
not do unit testing
just get this one fix, feature or little thing in without following good practices

Each one of these scenarios is asking you to compromise your professionalism and ethics with regards to your craft for the sake of speed or cost. It is my position that this is dishonest to you, the developer, to the rest of our team who rely on our continued quality to be successful and to the customer, who has a reasonable expectation of quality, performance and attention to detail.

The Builder and the Software Craftsman

"If you were hiring a builder to build an addition to your house, you wouldn't hire one who didn’t use a Measure, Level and Square. Why would you do it with the backbone of your business? Automated Testing, Code Metrics, Code Style Analysis and Static Code Analysis are a .NET developers Measure, Level and Square and allow him to know the impacts of his change and prove the quality of his code." - Chuck Charbeneau

In all other fields we expect craftsmen to use the tools and processes of their trades to deliver the highest possible quality in the time available, and yet every day software developers are being asked to cut corners and sacrifice quality and craftsmanship on the products on which most of our society runs.

The Shield of No Compromise

As signatories of the Craftsmanship Manifesto, we agree that:

We will not make messes in order to meet a schedule.
We will not accept the eternal lie that we will “Clean things up later”.
We will not believe the claim that quick means dirty.
We will not accept the option to do it wrong.

We will not allow anyone to force us to behave unprofessionally. We agree to these axioms because they protect us from contributing to the degradation of the quality our product, from slowly building the barrier to success that is comprised of unnecessary technical debt; it shields us from contributing to, Robert C. Martin calls it, The Giant Mess We also agree to face the Mess and Fix it, bit by bit, day-by-day. We agree to apply the Boy Scout Camping Rule to our products by submitting better code than the code you found when you started. We agree to strive to be proud of every line of code we write; to be willing to sign our name to each one. We agree to "do it right" even under pressure and to take responsibility to what we committed to. We take pride not only in our end product but also on the process we use to achieve it.

Sharpening the Blade of Our Craft

The software craftsman is a continuous learner. When she doesn't work, she spends her time studying, finding new methods and tools to improve her work. She writes code. She practices deliberately and understands the difference between practice and work. She practices in order to be prepared for work. She also contributes to the community. We are programmers. We need to talk about programming from time to time. We need time and space to focus on our primary discipline: the craft of programming. We should be continuously practicing and seeking out new methods of training and practice, including:

Test First

Test Driven

Test Obsessed

Code koans

Master and Apprentice

Find a Master

As Craftsmen, we recognize that there are other craftsmen in our midst and we seek them out to learn from their technique, analyze their craft and hold our work against theirs for the betterment of the craft.

Find an Apprentice

As craftsmen we realize that to teach a thing is to know a thing. We recognize that there is no better way to learn a craft than to teach it. Even if you are a beginner, there is always someone who is more of a beginner than you. Be it in the work place, a User Group or an online community, be a helpful, educating and guiding mind in the craftsman community.

Twelve Principles of Agile Software Development

Remember that this movement is not at odds with Agile Software Development; it is in service of agility that we seek to better our craft.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity — the art of maximizing the amount of work not done — is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

What's Next?

Sign the Manifesto

Read and Educate yourself