The Method is not The Problem

There's an old, old cartoon that's been floating around the IT industry for decades. (Sadly, I can't seem to find it on Google.) The gist of it is this: A programmer is sitting at a computer and his boss says: "You start programming, and I'll go figure out what the customer wants." (I said it was an old joke - I never said it was hilarious.) :-) Sadly, that cartoon is as relevant today as it was when it was first printed. And when people are asked how to solve this problem, they nearly always provide a standard answer: We need to adopt a more modern development methodology.

I've seen countless development methodologies in my lifetime, and each new one promises to cure all of the ills of the prior ones. The announcement of a new method is usually accompanied by a case study that documents a 50%+ improvement in efficiency and customer satisfaction. Inspired by this revelation, Smart People start their own investigations, and reach similar conclusions. Before long, the new method is the only topic being discussed at technical conferences. Practitioners fondly testify as to the merits of the new method, and the great unwashed hang on every word. Soon, training companies announce certified training in the new method, and enterprises line up to be the first trained. After this, executive reviews are interrupted as VPs ask if you're using the new method. If you aren't, they consider your project "troubled".

Over time, projects associated with the new method are not completing on time; they're seeing the same levels of productivity and customer satisfaction as before. Costs remain stubbornly high, and defects are appearing everywhere. A group of Smart People appear and denounce the new method as lacking in some key areas. Fortunately, the Smart People have an answer to all of the IT community's worries: A New New Method.

If you're still reading this, then you probably get my point: There are tons of methods out there, and any number of them can help you develop successful software. Personally, I'm of the opinion that the key success factor in software development is the team of individuals, and not the method used. To be sure, it's important to follow a method, but I'm regularly amused when people seem to think that changing a method will save their IT department.

Here are some key points I like to keep in mind when starting a project:

  • You have either been recruited to solve a problem, or an idea pops in your head. Spend LOTS of time thinking about this problem. Take notes. Lots of notes. No, really... TONS of notes.
  • Define the problem you're trying to solve. (Read:Simplify the description of the problem you're trying to solve.) It can be a paragraph, or even a sentence.
  • Think about the sort of person that wants this problem solved (i.e. the user / customer). Find them, and ask them if it's truly a problem that must be solved. You'll be surprised at the number of times it's not really a problem at all. Other times, people will agree it's a problem, but not one that's important to them.
  • If it really is a problem that's worth solving, listen carefully to what the person says. Repeat this often.
  • Don't react poorly to criticism. There's a difference between believing in your idea, and ignoring advice. (It can be a bit gray, but it's there nonetheless.) Learn from what others are willing to share with you.
  • Don't be afraid to throw away something that isn't working.
  • Learn from your mistakes, and keep moving forward

This (incomplete) list is unordered, because I usually jump around between points. For example, if I have an idea, I usually spend some time formulating it, and then I ask one or two trusted friends what they think. Based on their thoughts, I either ditch the idea, or press onward.

A project's critical success factor is the people, and there's no getting around it. However, some basic development process is important. Experienced teams rely on years of practice, so it's easy to think they're just winging it. If they're a good team, they're definitely not winging it. On the other hand, if you have an inexperienced team, a formal method can help guide them along. So to be clear: Methods are valuable, and they can contribute to the success of your project. However, do yourself a favor and surround yourself with highly skilled developers. You'll thank me later.