Tuesday, February 22, 2011

Software Craftsmanship, Beyond the Hype

Software Craftsmanship: The New Imperative
Corey Haines gave a talk about software craftsmanship at QCON London 2010.Corey describes how in December 2008, a group of aspiring software craftsmen got together and tried to solve some problems they were facing. They discussed how to become better and how to bring new people into software careers. They came up with a statement of things that they believe in and crafted the manifesto of Software Craftsmanship which states:

  • Not only working software but also well crafted software
  • Not only responding to change but also steadily adding value
  • Not only individuals and interactions but also a community of professionals
  • Not only customer collaboration, but also productive partnerships

The Enterprise and ScrumCorey’s talk focuses on well crafted software and a community of professionals.There are a lot of schools of software craftsmanship that all revolve around the principles of the manifesto. Corey expands on the thoughts of the Chicago school of software craftsmanship. They felt that we are heading in a bad direction. The state of software development was going downhill. People came up with idea on developing quality software. They came up with Scrum. However, Scrum did not prescribe any practices. Ken Schwaber said that we made a fundamental assumption that was wrong. The assumption was that developers were smart enough to come up with their own practices. However, developers had spent their careers working in large cycles. They were used to it. They were accustomed to waiting for 9 months before coding or before QA and now they had to suddenly figure out how to do things in 30 days or even in 2 weeks.

Test Driven Development: By ExampleXP had the practices that support the idea of short feedback loops. However, XP is hard. TDD is hard. When you introduce TDD, productivity goes down. Overtime, it will go back up again, but it is hard to get started.

Corey states that Agile is about developing quality software. We need something that focuses on developing quality software developers. This is what software craftsmanship is. We need to give people the tools to be better.

But what are these tools? And what does it mean to be better? This depends on each individual. Don’t let somebody else tell you what it means. You have to figure it out for yourself. Find out what you need to improve on to produce better software. Picture your ideal. Picture your reality when under pressure. The difference between the two is a measure of how much your code sucks. Use this to see how you are improving.

Corey continues by explaining how do we know what those ideals are? This is where we each have to go through the stages of being an apprentice, a journeyman and eventually a craftsman.

Clean Code: A Handbook of Agile Software CraftsmanshipApprentice is going in and finding somebody who is willing to take you under their wing and show you the way. You can spend time learning effective ways of developing software (TDD, evolutionary design, capturing requirements). You work to learn those ways. You internalize a set of practices that are time tested and proven. You do this by working on software. Not by sitting in a classroom.

Once you have those practices, then you look out for other people out there that are doing it differently. See how you can integrate them. This is the concept of journeyman. It is not about travelling the world. It is about participating in user groups, reading books, observing others, integrating what you have learned and moving forward.

Corey wraps up by describing the latest movements that resulted from the manifesto and how it made it easier for people to roll out some ideas on how to practice.

  • The Pragmatic Programmer: From Journeyman to MasterCode Katas: Dave Thomas from pragmatic programmers came up with code katas, which were small problems to solve. Uncle Bob switched that to practice on a solution instead. He related it to martial arts and how you repeat small motions and practice them until they become natural reflexes. When you are in this situation, this is what you do. An example might be practicing String replacement using regex. Do it over and over again until it becomes a reflex. The site Katacast.com has various screencasts known as katacast that show folks practicing a small kata.
  • Conferences: The Software craftsmanship conferences were established and 2 are held each year, one in the UK and one in the US.
  • Code retreats: Retreats started worldwide. This is where developers get together on a Saturday for a full day of practice. They work on Conway’s game of life using a technique known as “TDD as if you meant it” which focuses on TDD being all about evolutionary design. Pair-up, work on it for 45 minutes. Then delete your code, swap pairs and do it again.
  • User groups: Several Software Craftsmanship User groups started.
  • Craftsman Swaps: A couple of companies conducted craftsman swaps. This is where 2 companies swap an employee for a week. The employees learn the practices of another company and come back and try to improve their own environment.
  • Craftsman Journeys: Similar to a craftsman swap, this is where you just go to a company for a week and learn what they do. So instead of going to a conference, a company will give you time off to go and work and learn what others are doing.
  • Craftsman spikes: These are side projects that you can use to practice craftsmanship. Companies offers employees 20% time to work on these side projects.

This presentation is now available on infoQ at http://www.infoq.com/presentations/Software-Craftsmanship-Beyond-The-Hype

Saturday, February 12, 2011

Bold Statements

During the key note address at the 2010 Agile DoD conference, Scott Ambler made some bold statements. Below is a recap of some of his most interesting points.

There is overwhelming evidence that defining requirements in detail upfront is phenomenally bad practice, unethical at best in the IT world.

A changed requirement late in development cycle is a competitive advantage provided you can act on it.

Agile Modeling: Effective Practices for eXtreme Programming and the Unified ProcessChange management is really about change prevention. People that follow change management are worried about scope creep and are trying to prevent it. These people fundamentally do not understand what their jobs are as IT professionals. When you prevent requirements from changing, then yes you might be building something to spec, but you are now building something that people do not want and you are charging them for it. That is not ethical.

The best way for communication is face to face communication. If you want to increase the risk on your IT projects, write documentation and create a detailed specification.

Repeatable processes are bureaucracy. What people really want are repeatable results. They want high quality. They want systems that meet their needs in a timely matter. Delivering repeatable results requires discipline.

Agile is highly disciplined. You have to distinguish between bureaucracy and discipline. Bureaucracy is not discipline. Filling up paperwork, documenting requirements, documenting detailed architecture, reviewing them, and getting people to sign off on them, all this is not discipline. This is bureaucracy.

Real disciplined is producing high quality software every few weeks. It is refactoring and cleaning up your code as you go. It is about professionals validating their own work to the best of their ability. Don’t just throw stuff over to QA.

Agile teams are self organizing generalists. Like the military, guys on the ground are allowed to make decisions and adjust. Specialists are risky. If the specialists are gone, everybody is in trouble. We should avoid hand-offs between specialists.

Agile teams are easier to manage than traditional teams. In agile world, you cannot hide anymore, you have to produce.

There is nothing new about Agile. Most ideas of Agile can be traced back to the 60s and 70s. Agilists focus on the things that work and avoid the things that do not work.

There is nothing special about you. Do not come up with excuses for not adopting agile.