(Also published on IBM’s Rational Developer Network site)

In any software development methodology, there’s a secret ingredient that doesn’t get enough press. It doesn’t matter whether you follow Cooper, Beck, McConnell, or anyone else on the long list of notables.

The various methodologies range from formal to informal, with huge amounts of paperwork or almost none, from endless meetings, to stand-up only meetings, from 10-foot thick walls between programmers and other coworkers to small teams that work together, from etched-in-stone project schedules and milestones to small iterations and releases, with nothing predicted other than the next two weeks. All of these methodologies can work in certain situations and all can point to successes they’ve had, which leads their proponents (perhaps more than their founders!) to often tout their new religion as the be-all and end-all of software development.

When people have had bad experiences with particular methodologies, upon speaking to them the problem often seems to be related not so much to the methodology itself but either an incomplete implementation of the methodology or some particular individuals. I presume everyone can think of a situation where some lousy <fill in the blank: programmer, analyst, customer, project/product manager, VP, architect> caused so many problems that the project failed miserably. When that happens, whatever methodology was used seems to leave a bad taste in your mouth forever. It’s like getting stomach flu: you never again want to eat whatever you ate just before you got sick, whether there was any relationship between the two or not!

But throwing out the methodology because of an individual (or even a bad team) is throwing the baby out with the bath water. If the problem is the people, then so is the solution.

The Impact of the Wrong Team Members

What rarely seems to be articulated as an absolute requirement in any situation is quality people who care enough about producing quality software that they have open minds about how to build the best they can build.

Think what bad people cause in projects:

  • Programmers have clueless analysts telling them what to do without understanding anything.
  • Analysts have been lied to (“that’s not possible”) by bad or lazy programmers or have just been ignored.
  • Product managers push unrealistic schedules on everyone, and add features late in the game without adjusting the schedule—or take the schedule they were given and say “You can have half that time. You always inflate your guesses anyway.”
  • Some programmers do inflate their estimates because they’ve had their schedules cut in half before!
  • Managers have people making decisions on their own that affect the quality of the software, the schedule, and the future of the company but this information never comes up until much later.
  • Sales people promise features that aren’t available and then expect them to be added.
  • Features get slipped into a product because the programmer thought it was cool.
  • Programmers change the interface of something without telling the documentation writers.
  • Writers don’t update things because “it will just change anyway”. User interface gets slapped on at the end when someone gets told to “pretty it up.”
  • Programmers see the face lift above and figure why bother working with a UI person: they just slap stuff on at the end anyway.

Learn From Your Past Carefully

We each take our own experiences and extrapolate to come up with “rules” we can live by. Unfortunately, many people take a negative situation and come out with unfounded generalizations that color their world in a negative way. Work with a bad programmer: you’ll try to control and curtail every programmer you work with. Work with a stupid analyst? Find a methodology that eliminates the need for them and believe you can do it all yourself. Work with a writer that never did understand what they were writing about? Ignore them all in the future. Every one of these situations can lead to someone to believe:

  • All analysts are useless.
  • Product managers don’t understand anything so just keep them in the dark about the product as long as possible and never invite them to engineering meetings.
  • Programmers will just have to work overtime to deliver according to the schedule.
  • User interface designers are useless and we can ignore them.
  • Don’t let the sales people hear about any features or they’ll be off selling the next version before we’ve finished this one!
  • Writers take up too much of the programmer’s time and keep wanting to change everything! Keep them in the dark as long as possible so there’s no time to fix anything they want changed.

The Secret Ingredient: People

Far more important than any particular methodology is the secret ingredient: People. Qualified, talented people who know their own limitations and appreciate what other team members can bring to the project, communicate well with others, are realistically optimistic, open-minded and want to continue learning.

Here are my rules. They apply no matter what role you play on the team.

The Sprezzatura Way

I’ve learned from all of the people that I mentioned in the first paragraph and hope to continue learning and trying out new ideas until this life is done. I’ve learned from people I personally dislike and people I admire greatly. In fact, there are very few people I’ve run into that have not taught me something. (In the worst case, of course, it’s what not to do ever again!)

Work with people you respect and admire. Earn others’ respect and admiration. Do things in the best way you know how. Continually learn from books and people. Don’t allow yourself to do a sloppy job. Mentally sign your name to your work. Be proud. Be honest. Have a professional code of conduct.