Heilmeier’s Catechism – a checklist for software projects

NOTE: I originally posted this at my old company's website in 2010,
but as that blog has been taken down, I thought I'd resurrect this
post here.

Until recently, I am ashamed to say that I had never heard of George Harry Heilmeier. A recent retweet by Roy Osherove on Twitter soon had me digging for more information.

It turns out that not only was Mr. Heilmeier  a pioneering contributor to liquid crystal displays, he was a Vice President (and later CTO) of Texas Instruments during the time they produced the mighty Speak and Spell.

Mr Heilmeier’s Wikipedia page lists an amazing amount of awards, including the National Medal of Science  and the IEEE Medal of Honor, but that’s not what sparked my curiousity.

What was interesting to me about Mr. Heilmeier was a series of questions anyone should be able to answer when proposing a research project or product development effort. These questions are known as Heilmeier’s Catechism.

Here is Heilmeier’s original list of questions:

Heilmeier’s Catechism

  • What are you trying to do? Articulate your objectives using absolutely no jargon.
  • How is it done today, and what are the limits of current practice?
  • What’s new in your approach and why do you think it will be successful?
  • Who cares?
  • If you’re successful, what difference will it make?
  • What are the risks and the payoffs?
  • How much will it cost?
  • How long will it take?
  • What are the midterm and final “exams” to check for success?

When I read this list, it struck me that these questions could easily be adapted as a software project checklist.

With some small tweaks in language, this list becomes a standard project checklist that any consulting organization should work on with their customers to answer when deciding whether or not to go ahead with a project:

Project Checklist

  • What is the underlying business problem we are trying to solve with this project?
  • What happens today? Is this problem worked around with manual processes?
  • What’s new in this approach and why do we think it will be successful?
  • Who are the project stakeholders?
  • If we’re successful, what difference will it make?
  • What are the risks and the payoffs? How can the risks be mitigated?
  • How much will it cost?
  • How long will it take?
  • How will we measure progress on the project? How do we know we’ve been successful?

What about your organization’s project approval process? Does your company use Heilmeier’s Catechism to decide whether to give a project a green light? What other questions should be asked before starting a project?

Is your consulting code an asset or a liability?

NOTE: I originally posted this at my old company's website in 2010,
but as that blog has been taken down, I thought I'd resurrect this
post here.


When you hire consultants to build software for you, how do you know if the code is worth the money you pay them?

Consulting code (indeed, any custom code) should be an asset to your business, but unfortunately, many times it’s quite the opposite.

Consulting code can become a liability. Lack of tests and poor quality, buggy code can leave you, your code and your pocket book in worse shape than before the consultants arrived (and usually with little to no recourse).

Untested code has no business value

Years ago at the Agile 2006 conference, one of the sessions was "Delivering flawless tested software every iteration", delivered by Alex Pukinskis. The catchy name attracted a big audience and it was standing room only.

During this presentation, Alex made the following statement: ((I'm not sure whether Alex was quoting someone, but googling that precise phrase returned zero results, so I'm attributing it to him))

Untested code has no business value

This struck a chord with me, because at the time I was working for a company that was trying to transition to agile, but many of our practices still hadn't changed. We were (okay I was) still breaking the build and still expecting the QA team to find our bugs for us. We weren't consistently doing TDD, we had no automation of the build acceptance and we were not practicing continuous integration. I could go on, but I'm sure you get the idea.

The "aha" moment for me was the concept that the quality of the code, and a lack of defects was my responsibility as a professional developer. It was my responsibility to ensure that no defects were passed to QA. Of course, I know that software cannot be perfect, and there will be defects, but my attitude towards defects changed after that talk. Defects should be unexpected. Defects should be unusual. Defects should be prevented, not found.

No Bugs

The attitude that defects should be prevented, not found, can be summarized in the "No Bugs" philosophy.

James Shore recently published the full text of the No Bugs section from his excellent Art of Agile book. He summarizes the text in 99 words:

Rather than fixing bugs, agile methods strive to prevent them.

Test-driven development structures work into easily-verifiable steps. Pair programming provides instant peer review, enhances brainpower, and maintains self-discipline. Energized work reduces silly mistakes. Coding standards and a "done done" checklist catch common errors.

On-site customers clarify requirements and discover misunderstandings. Customer tests communicate complicated domain rules. Iteration demos allow stakeholders to correct the team's course.

Simple design, refactoring, slack, collective code ownership, and fixing bugs early eliminates bug breeding grounds. Exploratory testing discovers teams' blind spots, and root-cause analysis allows teams to eliminate them.

Asking the right questions

Now you are probably expecting some sales pitch from me at this point to say that you should hire us because we're great. Well that's not the point of this post (although you should, and we are). The point of this post is that the next time you are talking to a consulting firm or hiring a developer (( For more information on hiring developer team members, read http://jamesshore.com/Blog/Alternatives-to-Certifications.html)), ask them about their definition of code quality and how they ensure it. By simply asking a couple of questions you should be able to determine whether they are all "smoke and mirrors" or if they will add value to your business. For example, you might ask:

  1. What is your definition of quality code?
  2. How do you ensure your code is bug free?

The answer to the first question should mention practices like the Law of Demeter, coding standards, refactoring and adherence to the SOLID principles.

Although unsettling, it is okay if the answer to the second question is “I‘m never 100% sure my code is bug free” (particularly if they mention Gödel's proofs). However, they should quickly follow up with, “I make bugs less likely by practicing test driven development, peer reviews (or pair programming), automated acceptance tests and adherence to coding standards and good design principles.”

If they can answer those two questions to your satisfaction (and follow through by demonstrating these practices when building the code) then they might know what they are talking about, and actually give you value for your money.

The Waterfall approach to reading

NOTE: I originally posted this at my old company's website in 2010,
but as that blog has been taken down, I thought I'd resurrect
this post here.

I was chatting to my wife the other evening and started to discuss reading lists. I wondered aloud how many years I had to live (30? 40? 50?), and was thinking about how many more books I would be able to read in that time.  A book a week for 40 years would mean I could read about 2,000 more books in my lifetime.

A quick search netted this wonderful article from the Guardian Online: 1000 novels everyone must read, so that was a great starting point.

I thought about how the task of building a reading list would look like if I approached the task like a software project.

The Waterfall Approach

  1. Use the Guardian article, Amazon reviews and recommendations to create the complete list of 2,000 books I am going to read.
  2. Prioritize the list.
  3. Buy all of the books in the list.
  4. Work through the list, reading the books in order.

Now deciding ahead of time what you are going to read for the next forty years is clearly ludicrous, as so much will change in that time.  My interests and priorities will change. The world will change. The available books will change. Even the cost and technologies for delivering books will change. All of this means that making decisions now about events far in the future is a pointless and expensive exercise, as most of the books in the list would go unread.

The Agile Approach

  1. Decide how far ahead you want to plan – far enough to avoid running out of books to read, but not so far as to make change costly.
  2. Make a much shorter list of books to read.
  3. Prioritize the list.
  4. Buy the first few books in the list.
  5. Keep updating this shortlist as your interests change and new books are published.

This approach has the advantage of having less overhead to maintain (a few books instead of 2,000), cheaper (less cost and inventory up front) and more flexibility (the list can change more easily over time).

Don’t plan in detail too far ahead, but be prepared for change

On many software projects, we are asked to plan iterations and projects months and even years into the future. This is as foolish as planning your reading list far in advance.

Just as most of the 2,000 books in our waterfall reading list would probably go unread, by the time we get to the end of a long software project, we know so much more about what we need to do and so much has changed that a lot of the later detailed planning has to be completely redone as it is worthless and out of date.

I’m not saying it’s worthless to have high level plans – in fact this is really important. We need to know if certain things have to be lined up ahead of time (for example communicating release plans and outages, getting users trained, making sure other teams are ready for the downstream affects of our changes) and we need to know when the last responsible moment to make those decisions will be.

We also often need to provide our customers with a ballpark idea of the costs and schedule of a project (is it a week? a month? a year?) before the project begins, but we shouldn’t treat this as being cast in stone. The plan has to be flexible enough to change with the landscape. The cost and schedule estimates need to be improved and updated as time goes on, as uncertainties about the project are reduced (I’ll write more about this in another blog post).

While a high level plan is a good thing, what is foolish is detailed design, task planning, assignment and estimating for items far in the future of a project. While this may give the illusion of control and predictability, it is just that: an illusion. In fact it’s harmful to have that level of detail because the more design artifacts and task details that need to change in a project, the higher the overhead of maintaining these details and the more rigid the project will become.

Just like keeping your reading list short and easy to change, you should keep your iterations and detailed project plan short. This will give you a flexible plan that can adapt as the project progresses.

For more ideas about shrinking your iterations, see my recent blog post on the topic.

The shortest amount of time that could possibly work – shrinking your iterations

NOTE: I originally posted this at my old company's website in 2010,
but as that blog has been taken down, I thought I'd resurrect this
post here.

It’ll never work

It’s hard to believe this with my looks, but back in Liverpool I sang and played guitar in a band. One day, in rehearsal we were working on a new song, and I asked the guitarist to play an unusual arrangement. (For the music geeks amongst you, one guitarist would play the three chord trick in the chorus, and the other guitarist would play the relative minor chords at the same time.) His response was, “it’ll never work – the chords are going to clash together.”

Now bear in mind, at this point we are in a rehearsal room, with guitars strapped around our necks and plugged into amplifiers. It would have taken thirty seconds to try this out and see (or in this case, hear) whether or not it worked, but instead a long argument about music theory ensued. Eventually we played it, and it worked. (We recorded the song some time later and I think that those chords played together still sound rather nice)

In retrospect, to get the guitarist to try out the idea, what I should have done (instead of arguing about music theory), was to say, “you know, you might be right, but let’s try it – if it doesn’t work, we’ll know pretty quickly and we’ll try something else.”

A resistance to short iterations

One of the things I almost always find when working with customers is a reluctance to shorten their development cycles. Although they begin to adopt a lot of good development practices and are enthusiastic about the benefits of an agile approach, they’ve been conditioned over the years to think that there’s nothing achievable in a week or less, and they want to start out with iterations a month long or more.

This resistance to change was recently summed up by Mike “GeePaw” Hill as a case of the “Yabbits.”

Yabbitting is when people go through a sequence of resistance statements, where each statement begins with the words, “Yeah, but…”.

While Yabbits can be annoying, Mike goes on to state their value:

Yabbits don’t always, or even usually, represent real resistance to change. On the contrary, they are probes, whose intent is to test an idea’s prima facie validity.

A person who offers you yabbits is typically more open to an idea than a person who says nothing at all.

So when faced with this resistance, remember that these objections are often coming because people care and because they have real concerns. I should have been happy that the guitarist cared enough about how the song would sound, rather than just going along with my idea.

Often it is easy to show someone who is resistant to change a way forward by asking them to try something for a little while and show them that there is little risk in trying it out. This approach avoids getting embroiled in an argument about about some esoteric theory of agile software development (or music theory!) For some practices, the change may be perceived as risky, but for others, like shortening an iteration, or playing a new arrangement of a song, the risk is minimal.

The shortest amount of time that could possibly work

The problem with having long cycles (particularly when transitioning from a traditional approach to an agile one) is that the cycles tend to behave like mini waterfalls: most of the work gets done at the end of the cycle, the testers have most of the features dropped into their laps in the last few days of the cycle, and a lot of the real tools and practices needed for a sustainable pace (for example continuous integration, build automation, automated regression test suites and improved communication) often don’t happen early enough in the project for the team to get real benefit from them and ease their transition.


The benefits of a short iteration far outweigh the risks. The only real risk is that you won’t get much done in the iteration, and the overhead of setting up the iteration will be high. However, shortening the cycle means that you will not waste time in high ceremony activities, and any pain points or roadblocks will become evident very quickly. In addition, the risk of not achieving much soon disappears as you become much better at slicing requirements down into small but valuable features. You will also improve several techniques that will help you work at a sustainable pace.

To summarize, you will see the following benefits:

  • Risks and inefficiencies are exposed earlier.
  • High overhead activities like long meetings that don’t get you closer to your goal of releasing a valuable feature are removed or reduced.
  • The team will work together, swarming on a single feature until it is complete, rather than continuing to work across many features in the traditional manner.
  • Improved communication between the team and the business owners is necessary to keep the work flowing.
  • Automation becomes a necessity, rather than a nice to have.
  • Less temptation and opportunity to revert to old practices and do mini waterfall.

So given all of these benefits,  how short should an iteration be?

Ward Cunningham famously rephrased Occam’s razor when applied to software development as:

…ask yourself, “What’s the simplest thing that could possibly work?”

Let’s redefine an iteration in this way:

Ask yourself, “What’s the shortest amount of time that could possibly work?”

In other words, find the shortest time-frame in which you can get something of value to the business done.

How short is that? Almost certainly shorter than you think.

How do you get there? Luckily, several people smarter than me have some ideas.

The disappearing iteration meme

There has been a recent meme about shortening iterations, with several people blogging on the topic from different approaches.

Michael Feathers recently wrote about Zeno length iterations, where he proposes an experiment:

Suppose that you had an iteration of one week, followed by an iteration of 2 days, followed by an iteration of 1 day, followed by an iteration of one-half a day, and so on…

…you can deliver business value in shorter times than you can currently imagine.

From Michael’s perspective, one of the main benefits of short time boxes is that they force trade-offs and produce creative solutions. He concludes by saying:

Look at your product today.  If you only had one day to develop and deploy some feature, before putting the product on ice and letting it generate revenue as is forever, what would it be?

While I think Michael’s experiment is a little abstract, the point he is making is that you can deliver value with very small chunks of code – smaller than you think today.

Kent Beck recently proposed a different experiment in extremely short iterations, for a different reason, continuous deployment immersion:

Get the whole team in a conference room Monday morning. Choose a feature you are going to add. Have one person come up to the one machine in the room. Write one line of code. Deploy.

If you can’t deploy, erase that line of code and write a different line of code first. Deploy.

Once the deployment is done, write another line of code. Deploy.

About this time some of the rest of the team is going to be bored watching all the manual steps in the deployment. Have them go off and automate the most tedious, boring, or error-prone step. Bring the automation back to the conference room and start using it.

Kent suggests that by doing this, you will start to automate your deployment, automate your tests and understand a lot more about slicing up your features into smaller chunks.

By Friday afternoon you may not have made much progress on your feature (but you may be pleasantly surprised), but you will understand deployment much better than you do now. You will also understand how to slice development more finely and rearrange the pieces. You will also understand the value of automation.

He also (with tongue in cheek) concludes that it’s a crazy idea, but in reality, there is also a lot of value here. Forcing everyone to think about where their pain points are and making the pain points happen often (due to shortening the cycle) means that the team will be motivated to remove and automate those pain points and ultimately work more efficiently.

James Shore and Arlo Belshee also recently gave a very entertaining talk at the Lean Software and Systems 2010 conference, entitled “Single-Piece Flow in Kanban: A How-To.”

In it they propose stripping down a lot of the complexity of Lean and only having two queues, On Deck, and In Progress.

Ideally, only one item (Minimum Marketable Feature, or MMF to use Lean terminology) would be in progress at any time. Instead of moving the MMF through the traditional production line of Kanban (for example, through requirements definition, story queue, development, testing and deployment), you instead create a detective’s blackboard by putting all of the information about the MMF onto the board. The name comes from detective TV shows, where all of the information about a crime is displayed on a blackboard. This information might translate to tasks or information about the feature.

The whole team swarms on this single feature until it’s completed and then it is removed from the board and the next item added from the On Deck queue. What is fascinating about this talk is that while Jim and Arlo disagree about some details and definitions (including their definitions of an MMF), they both agree that this is a more efficient way to build software.

Try it!

While there are several approaches to shortening the iteration, or taking a Lean approach and not having iterations at all ((For more information on Lean and Kanban development, read Jeff Patton’s excellent post, Kanban development oversimplified)),  the best approach for you is the one that you try. Whether you take Michael Feathers’ approach of shortening the iteration length to find a workable minimum, Kent Beck’s approach of starting with a single line of code at a time, James Shore and Arlo Belshee’s Lean approach of swarming on a single feature, or some other means doesn’t really matter. What does matter is not being scared to shorten the cycle until things are a little uncomfortable and real work needs to be done to make efficiencies such as automation or continuous integration, or coming up with creative ways to solve problems and chunk up work.

Don’t get bogged down in figuring which way will be the best to shorten your iterations – that is like arguing about music theory when you have guitars in your hands. Instead, just pick an approach and try it.

You’ll soon arrive at the shortest iteration that works for your team, and it’s almost certainly shorter than you think.

And before you become a Yabbit and say “it’ll never work” ask yourself this: “what’s the risk?”

An Architect asks (part one)…

I just had a conversation with a software architect friend, who asked some pertinent questions about agile. After a lively discussion, I thought that the best way to respond in detail to his questions was to post here. I’ve broken the post up as it got a little long!

First, a little background on my friend. He is a very talented developer who has been involved with several companies helping to define business strategy, and design and build business applications. He has embraced some agile practices at the developer level (test driven development, refactoring etc.) but has not been involved in full blown agile projects until recently. After seeing a customer’s kickoff presentation about how they intend to manage an upcoming project he had some questions for me. The first question and answer is below:

We’re supposed to have something to release in three iterations. How can we deliver anything useful or worth releasing in three iterations?

There are two parts to this answer. One about what you don’t build, and the other about what you do build.

The first principle you need to follow is Simplicity. This skill is so important that is is mentioned as one of the principles behind the Agile Manifesto:

Simplicity–the art of maximizing the amount
of work not done–is essential.

Ironically, simplicity is a difficult skill the first time you try it. If you’ve been of the school of “Big Design Up Front (BDUF)”, it’s a hard practice to let go of. On an agile project, you need to be disciplined in not building what you haven’t been asked for and don’t need, even if you suspect you might need it in the future. You need to follow the principle of You Ain’t Gonna Need It (YAGNI) all the time. Now, if this thing called Simplicity is defined so simply, why is it so hard to do?

Well, it’s that nagging feeling at the back of your mind that you ARE going to need it. Designing everything up front and gold plating requirements is comforting for two reasons.

  1. Developers love solving problems, and there’s almost nothing more satisfying to a developer than finding a general solution to a problem. The good news is that you don’t have to abandon this approach entirely; as you’ll discover, if you practice test driven development and refactoring properly, it will be easy to find a general solution to a problem when you need to find a general solution and not before.
  2. Developers worry that without a big design up front, they will have to go back to the customer with change request forms and throw away code that’s already been built, thus adding lots of time and expense to the project. These seem like realistic concerns at first glance, so let me address them:

There’s really no such thing as a change request on an agile project. Change requests exist on projects where requirements are fixed. Agile projects embrace change, and what is built and not built is entirely up to the customer. The constant feedback and communication between the customer and developer and the fact they are part of the same team ensures that feedback is incorporated early. Formal change requests are not necessary on an agile project because there is a requirements backlog where the customer can add, remove and prioritize requirements.

While it can happen that code gets thrown away, particularly if you are not practicing Little Design Up Front (LDUF), by following the SOLID principles it’s more likely that your code can evolve and change, and the tests you have in place will ensure that existing functionality is not broken by new functionality.

The second part of this answer is about what you do build. In Agile projects, requirements are typically defined as User Stories. A User Story can be thought of as a vertical slice of functionality that has value to the customer. The skill of defining and slicing up these requirements is so important that there have been several books written about it. I recommend User Stories Applied by Mike Cohn for a great introduction to this topic. Building vertical slices well requires that you practice the principle of Simplicity to ensure that you only build enough infrastructure to support your current requirements.

I’ll talk more about practicing LDUF and agile architecture in upcoming posts, so watch this space.