Friday, December 23, 2011

The Code Christmas Tree

The Code Christmas Tree is a technique used to visualize the quality of your code. It is based on a treemap which is an information visualization technique to display hierarchical or tree-structured data as a set of nested rectangles. Branches are represented by rectangles and sub branches are represented by smaller rectangles and so on. The leaf node’s rectangle has an area and color proportional to a specified dimension of data. In the case of the Code Christmas Tree these can be lines of code, cyclomatic complexity, and test code coverage. The different colors and sizes make it easy to see patterns that would be difficult to spot in other ways. Looking at the tree you can quickly identify which code areas are clean and which ones need more tests or major refactoring.

The chart examples shown here were generated by Michael Kaiser and Guy Royse using a utility that displays Big Visible Metrics (BVM). It takes XML metrics generated by Sonar and parses the data and converts it to CSV data that is then consumable using the Microsoft Treemapper and Excell Add-in to generate these colorful charts. The size of the rectangle represents lines of code. The color represents cyclomatic complexity or test coverage. The large red rectangles are the code targets that need to be refactored or need increased code coverage. BVM is on GitHub and you can find out more about it here.

Adapted from The Code Christmas Tree @Agile2011

Tuesday, December 13, 2011

Draw me a picture

Draw me a picture is a retrospective technique that can be used when people are tired of the same old routine and when verbal communications are failing.

The process is as follows:
  1. Ask the attendees to silently reflect on the on the events of the last iteration or release 
  2. Ask them to draw a picture reflecting their feelings 
  3. Place the picture on the wall
  4. In turn, let each participant describe their picture and provide a title
  5. Try to observe patterns to highlight significant events or impediment

Adapted from: Putting the fun back in your retrospectives @ Agile2011

Tuesday, December 6, 2011

The 1st ever bug

In 1946, the 1st ever case of a bug was reported when an actual moth trapped in the relay of a Mark II caused it to malfunction. The bug was removed and taped into a log book and recorded as the 1st actual case of a bug being found! The log book (with attached moth) is on display at the Smithsonian National Museum of American History. How’s that for error tracking!

The term bug however was coined earlier as records show that Thomas Edison used it in 1878:

“It has been just so in all of my inventions. The first step is an intuition, and comes with a burst, then difficulties arise—this thing gives out and [it is] then that 'Bugs' — as such little faults and difficulties are called—show themselves and months of intense watching, study and labor are requisite before commercial success or failure is certainly reached.”

Adapted from: Refactor your wetware @ Agile2011

Tuesday, November 29, 2011

The Kata in the Hat

At Agile 2011, Emmanuel Gaillot and Jonathan Perret performed a coding Dojo entitled "The Kata in The Hat." Emmanuel and Jonathan are behind the original coding dojos in Paris. Usually, katas are performed by practicing TDD and applying baby steps. The main kinds of Katas include:
  1. Prepared Kata  where someone comes prepared with a full solution to the Kata and presents it to the group.
  2. Randori Kata where the group rotates pairs so solve a particular problem.
The Kata in The Hat is a twist on these katas. Here, the hosts had a hat in which audience members can write-in rules and requests and drop them in the hat. The presenters start with a main idea, but every five minutes one paper is pulled out of the hat, the instructions are read and the timer is reset. The hosts continue to pair program, but now they incorporate the new requests into their code. And so on... The interesting part is seeing how they can finish each request by doing the simplest thing that can possibly work. They quickly adjust and keep the code moving as they try to solve the main problem no matter what is thrown at them. This type of Kata is definitely not for the beginners, but it’s a great show that is fun, entertaining and educational. If they are ever touring at a conference near you, I highly recommend you attend.

"The big idea we want to get across is that programming can be beautiful, and that through creativity and beauty and poetry programmers have much more power than they think." 

Monday, November 21, 2011

Organizational Agility

The Economist Intelligence Unit published a paper entitled "Organizational agility: how businesses can survive and thrive in turbulent times." The paper is based on in depth interviews and surveys of 349 executives around the world on the benefits, challenges and risks associated with creating a more agile organization.

The report finds that organizational agility is a core differentiator in today’s rapidly changing business environment. Agility may also be linked to profitable growth as research conducted at MIT suggests that agile firms grow revenue 37% faster and generate 30% higher profits than non-agile companies.

Yet most companies admit they are not flexible enough to compete successfully. The report finds that internal barriers stall agile change efforts and the main obstacles to business responsiveness are slow decision-making, conflicting departmental goals and priorities, risk-averse cultures and silo-based information.

Technology can play an important supporting role in enabling organizations to become more agile. Technology should function as a change agent in the use and adoption of best-in-class knowledge sharing processes, so companies can improve their use of critical data.

The report concludes there are a number of steps that management can consider to lighten the burden of agile transformation:

  1. Minimizing excess spending and non-core programs so companies can better direct limited resources to satisfying customer expectations. 
  2. Minimizing information silos so business leaders can improve collaboration inside and outside their enterprise and better align departmental goals and performance measures with overall strategy. 
  3. Integrate and automate fundamental knowledge-sharing processes to improve decision-making, convert information into insight and enable IT to advance an organization’s ability to problem-solve. 
The complete report and survey results can be found here.

Monday, November 14, 2011


Agile Retrospectives: Making Good Teams GreatCaptions is a retrospective technique that can be used as a collaborative and safe way to share feelings. The technique is fun and the results can be very insightful and hilarious at the same time.

The process is as follows:

  1. Announce a specific topic for discussion 
  2. Each team member gets n number of index cards where n is the number of team members. The cards are numbered sequentially in each stack. 
  3. Individually, on card #1, members draw a picture to illustrate the topic at hand 
  4. The decks are passed to the right 
  5. On the new deck received from the left, members study the picture on top, then move the card to the bottom of the deck. 
  6. On the next card, members write down a caption for their interpretation of the picture they just saw 
  7. The decks are passed to the right 
  8. On the new deck received from the left, members read the caption, then move the card to the bottom of the deck 
  9. On the next card, members draw a picture based on the caption they just read 
  10. This process is repeated for several rounds until each stack is back at card #1 
  11. Members take turns laying out the decks and reading out and sharing the results with the team 

Note: If the number of team members is even, then start with drawing a picture, otherwise, start with writing down a caption.

Adapted from: Putting the fun back in your retrospectives @ Agile2011

Wednesday, November 9, 2011

The Nordstrom Innovation Lab

At the Nordstrom Innovation Lab, a new team is applying agile and lean startup techniques to move quickly from conception to deployment. The team is acting like a startup within a large organization. They work in a collaborative open workspace and go through several iterations using frequent customer feedback loops to plan out their next iteration. They keep their planning simple and light-weight by using sticky notes and index cards and following agile engineering practices like pairing and test-driven development. Watch this team in action below.

Tuesday, September 20, 2011

The Spinning Lady

Look closely. Is she spinning clockwise or counter-clockwise?

Think of happy places, found memories, poetry, and music. Let your mind wander.

Look closely. Is she spinning clockwise or counter-clockwise?

Solve 3*5=?
Solve 15+5=?
Solve 20+5=?
Solve 25 + 3 =?
Solve 28/2=? 14.

Look closely. Is she spinning clockwise or counter-clockwise?

Pragmatic Thinking and Learning: Refactor Your Wetware (Pragmatic Programmers)Did she switch direction? The idea here is that our brain switches between left and right. If she is spinning clockwise, then we are using the right side of our brain which is responsible for feelings, beliefs, imagination. If she is spinning counter-clockwise, then we are using the left side of our brain which is responsible for logic, math, and science.

Adapted from "Refactor Your Wetware" @ Agile2011

Friday, September 9, 2011

Effective Daily Standups

Thanks to all that attended my talk on Effective Daily Standups at the SA Scrum Gathering Conference. Below is the presentation slide deck and speaker notes.

Saturday, September 3, 2011

Source Code Word Clouds

97 Things Every Programmer Should Know: Collective Wisdom from the ExpertsHere’s a neat way to look at code quality - use source code word cloud generators.
A word cloud or tag cloud is a visual representation for text data. Tags or words are listed and the importance of each word is shown with different font size or color. When applied to well written and clean code, word clouds give us a quick way of understanding what the code is about.
 Below is an example from

Clearly, looking at the second cloud, we know a lot more about the domain than the 1st cloud.

Try it out using the original or

Adapted from "Code" @ Agile2011

Saturday, August 27, 2011

Back to the Future!

At the conclusion of the Agile 2011 conference, Todd Little jokingly looked back to the 1st Agile conference in 2004 when agile experts made predictions of the future and came up with the top 8 things that will happen once main stream gets hold of Agile Software Development:

8. The 1st Agile software development conference will undergo historical revisionism, in which it will be told as originally taking place on a farm outside Sundance, with lots of music and on-demand pairing, and announcements in middle of the conference to not eat the brown acid.

7. The Spike channel will ask Ron Jeffries to host an Apprentice-type reality show where agile teams will compete against each other to build software for rocket-packs, X-ray goggles, and invisibility rays. The catchphrase when he gets rid of the failing team each week is “You’re dead fish!”

6. GE will develop 3 year, six sigma certification programs for becoming Agile Certified.

4. You’ll see personal ads like ”Certified SCRUM master seeks product owner with large product backlog for promiscuous pairing”, and “Single Agile Developer with data envy and analysis paralysis seeks customer for private requirements collection; expect failure”.

3. Sun will come up with an innovative, elegant Agile programming language, get people to use it, and proceed to totally screw up the marketing for it and name it with really confusing release numbers.

2. Woman out at bars together will refer scathingly to the guy at the end of the bar who keeps starring at them as a “scope creep”.

1. A paperclip in Windows will pop up periodically and say, “Looks like you’re trying the waterfall method. Want me to pair with you?

Saturday, August 20, 2011

Measuring Code Quality

A common measure for code quality is to measure Cyclomatic Complexity. Cyclomatic Complexity is used to measure the number of linearly independent paths through a program’s source code. The more conditionals (if statements) or the more loops (for, while …), then the more branches run through the code and thus the code becomes more complex. But what is considered to be a good number for Cyclomatic Complexity? What should developers target?

A study by energy ( reveals the following:

There is a 50% chance of errors with a Cyclomatic Complexity of 38 and almost a 100% chance of error when Cyclomatic Complexity is 74. On the other hand, with a Cyclomatic Complexity of 11, the chances of errors drops to 28%.

So based on this study and the above graph, shoot for a Cyclomatic Complexity of below 20 per class.

Adapted from "Technical Debt Assessment and Reduction" @ Agile2011

Saturday, August 13, 2011

The 5 Whys

Agile Retrospectives: Making Good Teams GreatThe 5 whys is a retrospective technique that can be used when the team needs to focus on a specific symptom that does not have an obvious solution. The goal of the 5 whys is to clearly understand the situation and not necessarily to solve the problem.

The process is as follows:
  1. Write the problem statement clearly and concisely on the board.
  2.  Divide the team into groups of at least 3 but not more than 5. 
  3.  In each group, individually answer why did this happen? Number your answer as #1.
  4.  Individually answer why did #1 happen? Number your answer as #2.
  5.  Individually answer why did #2 happen? And so on until you have around 5 answers or can’t come up with more meaningful answers (try to have at least 3 answers).
  6.  Each individual places their chain of responses in a column below the problem statement. The group then discusses the individual answers and tries to find common patterns.
  7.  The group consolidates the chains into a single chain.
  8.  If necessary, the team consolidates the chains into a single chain.

Participants should focus on exploring the immediate cause of the symptom rather than attempting to immediately jump to a root cause. The intermediate reasons often spark ideas within the group that would otherwise be overlooked.

While this exercise is typically applied against problems, this same technique can also be used to discover what led a team to achieve exceptional success in one area.

Adapted from: Putting the fun back into your retrospectives @ Agile2011

Sunday, July 31, 2011

Follow-up on Getting Fit Using Agile Workstations

Back in late December, I blogged about my New Year's resolution of using a standing workstation. Well 6 months later, I can say that I have stuck to it. I can now work standing for about 6 hours a day, with a break during lunch. Overall, I definitely feel better and more energized, but I do not have concrete metrics to show that my health is improving. There are however more studies that have come out on the subject. Some warn of the dangers of sitting, yet other warn of the dangers of standing. Go figure!

And here's an info-graphic from medical billing and coding that sums it all up:

Sitting is Killing You
Via: Medical Billing And Coding

Tuesday, July 19, 2011

Importance of Well Designed Software

Refactoring: Improving the Design of Existing CodeAt the 2011 Agile Development Practices West conference, Martin Folwer addressed trade-able quality.

Martin explains that quality is something we can trade-off for other things. We often hear managers saying “We need to put less effort on quality so we can build more features for our next release.” We also do this every day. We do it when we buy a car. Sure we want the fancy car, but we go for the cheaper one and spend the extra savings on something else. This is a natural part of how we think about the things that we buy every day.

In software, there are visible and invisible quality features. For example, with a UI, you can feel the difference. But internal quality is not visible to the users. As a buyer, if I can’t see it, why do I want it? In that case, I will always pick the cheaper option.

Next Martin introduces the Design Stamina Hypothesis to illustrate why we should care about internal design of software.

Figure 1 - Stamina Hypothesis

The graph shows functionality over time.
The blue line shows bad design. We start out strong, but fade and slow down over time.
The red line shows good design. We start out strong and over time, we can keep a steady pace and even speed up.

With the clean system, a year from now it will have another 5 new features. The bad design system will probably only have 1 or 2 new features as they struggle with their bad code base.

Next Martin introduces the term technical debt which was originally coined by Ward Cunningham. Complexity that we don’t need causes extra effort to add new features. The unnecessary complexity in your code base is like the principal of a debt and the extra cost that you pay for adding new features is like the interest on the debt. This metaphor is useful when talking with non technical people. When building new software, you can choose a quick and dirty approach, increase your debt and increase your interest payment. Or you can pay down the principal and reduce interest payments.

Martin then explains the reasons we get into technical debt.

Figure 2 - Technical Debt Quadrant

1. Prudent/Deliberate: “We must ship now and deal with consequences” – This is a conscious decision. I have a deadline and I’m prepared to tradeoff some quality to meet that deadline.

2. Inadvertent/Reckless: People have no clue about software design.

3. Deliberate/Reckless: Very close to prudent/deliberate however, it is done without understanding what is going on. The decision to trade-off quality (debt) for speed only makes sense when we are below the design pay-off line (where the 2 red and green lines cross in figure 1). The key is to understand how far away the design pay-off line is. It is probably in the order of weeks and not in the order of months. It is a lot shorter than what people tend to think it is. If I am close to the point where I go over the design pay-off line, then there is no point in sacrificing design for speed because them I will end up losing both.

4. Prudent/Inadvertent – Here the financial metaphor breaks down. This case is when we’ve taken on debt without noticing it. It is because we learn new things as we code and when we look back at what we coded we say “Now we know how we should have done it”.

Clean Code: A Handbook of Agile Software CraftsmanshipThis presentation is available on youtube at (starts at minute 29:05)

Martin also discusses technical debt on his blog and

Tuesday, July 12, 2011

Command and Control vs. Agile

Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition (Addison-Wesley Signature Series (Cohn))
In her book, Coaching Agile Teams, Lyssa Adkins nicely maps out the transition in beliefs that traditional project managers have to go through when adopting agile.

Lyssa explains that the command and control project management beliefs on the left need to be replaced with the agile beliefs on the right:

Project management belief Replaced with
We can plan the work and work the plans. Planning is essential, plans are useless.
The triple constraints can be traded off for one another to correct for unknowns. Time and budget are held constant. Only scope flexes.
The plan gets more accurate over time as we flush out the project through phases of activity: requirements, design, testing, and so on. The plan gets more accurate over time because it is constantly reviewed and tuned up based on the teams actual performance.
Delivering on time, within budget and on scope equals success. Clients getting the business value they need is the only value of success.
Scope can be locked down with later discoveries being handled as change requests against the schedule end date. Scope remains flexible and changes of any kind are welcomed even late in the schedule.
Controlling through the project plan is my job. Controlling through a plan is not possible; releasing the team into the safety of agile is my only measure of control. So I coach the team to use agile well.
Completing tasks and delivering deliverables indicate progress and value delivered. Only delivered end products indicate progress and value delivered.

Tuesday, July 5, 2011

The Agile Manifesto – 10 Years Later

At the 2011 Agile Development Practices West, Martin Fowler reflected on where we are in the agile movement 10 years after the creation of the Agile manifesto. Martin looked at what was going on back in 2000. We were in a world of badly managed software. A group of people felt that to clean up this mess we needed big methodology, planned driven methodology, or an engineering approach to software development with lots of documents and lots of processes (waterfall).

Others had success with a different approach. They believed in rapid iteration, lots of collaboration, and an evolutionary approach to requirements, design, and architecture. They felt that they were not getting heard and were getting trampled by big methodology approach.

This group got together in Snowbird 10 years ago. The idea for the meeting originated a year earlier when the group got together at a workshop at Kent Beck’s home. Kent described XP as a set of practices governed by a set of principles and values. However, there were some that liked the values or principles, but did not like the practices.

This led to the Snowbird meeting where they concentrated on the values and discussed the different approaches like XP, SCRUM and Feature Driven Development. Uncle Bob felt the group needed a manifesto as a statement of what they believed in. In the end, the people that wrote the manifesto were just the people that were free to meet up that week.

Now 10 years later, a lot of the people that where there at the creation feel a sense of unhappiness with Agile and the manifesto.

Martin believes there are 2 main reasons for this.

The 1st is due to the inevitable consequence of success. The idea of Agile spreads out but the true meaning gets diffused. He refers to this as semantic diffusion. Anything that is successful spreads faster than the semantics can follow it. Martin stresses that we have to keep reminding people about the core concepts.

The 2nd reason is that the Agile revolution is still in its infancy. We are in the early days of a very long running change. Martin remembers the OO revolution. It started in the late 60s, it was put together in the 70s, had a good definition of what OO is in the 80s with small talk and took another 20 years or so before OO became main stream in languages like java, C++ and C#. Still today, 40 years on, people think they are doing OO, but they really just have procedures and naked data structures and not true OO.

Martin thinks Agile will take even longer than OO because it affects more people. It’s not just developers, but it is testers, BAs, managers, etc…

Martin then argues that people should still care about agile. He remembers how the manifesto was written.

The group came up with 8 valuable useful good things in software development. The idea was to arrange them in pairs so that one useful thing was more valuable than the other. The guiding light was the drive to the engineering methodologies. Flipping the values around was the value system of the engineering methodologists.

A lot of companies care about processes and tools over individuals because they want to be able to move people around.

The design and documentation is important to them because they believe that once it is produced they can give it to a bunch of developers that can code it up.

You have to have contracts in place and decided. The conversations are based on what is in the contract.

Following a plan was important because the definition of success was based on whether they stuck to the plan.

Martin argues that if you don’t care about Agile then you can be equally happy in a flipped or agile environment. The order within each pair of values does not matter.

Martin wraps up by looking to the future. He sees 2 emerging areas for Agile. The 1st is Agile User interface design where the UI evolves through customer, designer and developer collaboration instead of handing the UI to a team and then asking the developers to code what was designed (even if the developers see much simpler and faster solutions).

Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler))The second is the concept of continuous delivery and improving the process of how we move code from development to test to production.

This presentation is available on youtube at (minute 50)

Monday, June 27, 2011

The Semmelwies Reflex

Fearless Change: Patterns for Introducing New IdeasAt the 2011 Agile Development Practices West conference, Linda Rising gave a keynote address entitled “Deception and Estimating, how we fool ourselves”. In the presentation, Linda referred to the The Semmelwies Reflex which is a metaphor for the reflex-like rejection of new knowledge because it contradicts entrenched norms, beliefs or paradigms. It is based on the theory that once scientists have crafted a hypothesis they are reluctant to let go.

Linda quotes Max Plank:

“A new scientific truth does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die, and a new generation grows up that is familiar with it”.

Linda then explains that we have to wait for the old ideas to die, physically die, and she amusingly wonders “How many waterfall people must pass on before Agile takes over!!!”

Monday, June 20, 2011

Non-Determinism and Testing

Refactoring: Improving the Design of Existing CodeAt the keynote address of the 2011 Agile Development Practices West, Martin Fowler gave a talk on non- deterministic tests. These are tests that when you run them they pass, but if you run them again (without changing any code), they fail. They are also referred to as flaky tests or intermittent failures. The tests seem to pass or fail in a random fashion.

Martin asserts that non-deterministic tests are useless. The whole point of a regression suite is to be a bug detection mechanism. Its value is that you get immediate feedback when you make a mistake. The time between making a mistake and realizing that you did is very short. And because it is short, you can quickly figure out what you did wrong and fix it. With non-deterministic tests you get unreliable information.

Martin argues that non-deterministic tests are worse that useless. They are very dangerous. They are like an infection that infects the entire suite. One failing test will mark the entire suite as red. Usually we will dig in to see which test failed and fix it, but once we start seeing red regularly, we will assume the failure is due to the non-deterministic test and ignore the failure of the entire suite. This makes the entire suite flaky and the entire test suite becomes useless.

Martin purposes setting up a quarantine area for flaky tests. If we pull the tests from the suite, then the suite will remain reliable. The number of tests in quarantine need to be limited and fixed as soon as possible. Martin recommends setting some limits like no more than 3 tests can be in quarantine or a test in quarantine should be fixed within a week.

Martin next describes some causes for non-deterministic tests.

1. Lack of isolation: Tests depend on the order that are run. These are very hard to debug because when a test fails because of the order it ran in the suite, you usually re-run in isolation and then it passes. The real cause of the problem is in another test which is green and very hard to locate. There are two possible solutions:
  • Track dependencies: Track the order in which the tests need to run. This is very hard to manage and maintain.
  • Isolation: Martin prefers this solution. You can apply a clean-up strategy. That is, make sure there is a tear down that destroys anything you have created. An even better approach is to use a blank slate. Always start with a clean data set. The disadvantage here is that setting up the blank slate can be time consuming.
2. Asynchrony: Testing asynchrony is difficult. A common approach is to use what Martin calls a bare sleep where we introduce a sleep statement.


If we sleep too long, the test will run very slowly. If we reduce the sleep, then when we move to a different machine or if the machine is overloaded, then the tests will fail, so coming up with the correct number to sleep is very hard. Martin warns us against using this approach and recommends another solution using polling:

someFunction + timeout
while(!answer.recieved) {
  if ( > waitLimit) {
    throw new TestTimeoutException
  sleep (pollingInterval)

Here we have the sleep inside the polling and a timeout interval. You can keep the sleep interval very low and adjust the timeout. You have two times to play with (global constants).

Martin also discusses another approach using callbacks

callback = function
{ assert(answer) }
asserts.add(callback, timeout)

The callback method itself contains the verification. This solution depends on the testing framework that you are using.

3. Interaction with remote services: There are many things that can go wrong when dealing with a remote service that have nothing to do with your code (network down or slow, limited availability, unstable test data).

xUnit Test Patterns: Refactoring Test CodeMartin recommends using a a test double. This way, you control the data the service has access to, you can control changes, and ensure fast connections. However, some don’t believe this is testing the real service because we cannot keep the double consistent with the remote service. To solve this problem, Martin recommends that we add an integration contract test that does not run as part of the main build. This test will probably run nightly against the actual service and ensures that the signature of the double is in synch with the actual service.

Martin concludes by warning us that flaky tests are a common problem that can become very dangerous if not addressed immediately.

This presentation is available on youtube at

Martin also discusses non-deterministic tests on his blog

Thursday, April 21, 2011

Software Craftsmanship - It's an Imperative

Thanks to all that attended my presentation on Software Craftsmanship.

Below are the slides and notes from the presentation.

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 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