Of the 18 IT consulting maxims I listed in my previous post, number three -- It's not the theory, it's the execution -- is the only one that I haven't written about before, which is odd because it's one of my favorite mantras. Let's expand on this observation.
Managers often fall victim to the notion that "if we adopt a specific methodology, we'll fix everything"; this mindset can infect consultants and developers as well. We're all tempted by the promise of not having to think about a certain subset of the actions we must perform; if we just follow the prescribed procedure, we'll be all right.
You don't want to have to reinvent all of your processes on every project, so you should standardize procedures to help avoid missing things. But nobody has perfected a methodology for a nontrivial activity yet, so you always need to consider when to break the rules -- or at least bend them a little.
As an example, let's consider the Agile vs. Waterfall controversy. I'm a big fan of Agile principles (I even signed the Agile Manifesto early enough to get my name in the left column), but just "doing Agile" doesn't necessarily fix anything. Here are ways that Agile can go wrong:
- You can fail to plan far enough ahead.
- Scope creep can eat all your resources.
- The product's design can end up inconsistent and not well thought out.
- You may never get to "done."
Agile doesn't cause any of these scenarios -- people who do Agile badly cause these scenarios.
Now let's consider the all-too-familiar drawbacks of the Waterfall approach:
- You'll probably fail to account for some important requirements.
- When you add or modify requirements during a later phase, it requires massive rescheduling.
- The initial design is almost never right, and you won't know that until implementation.
- You have to be omniscient to be able to budget the required time and money.
Despite these drawbacks, it's possible to use the Waterfall approach and still be successful. How? By taking a few hints from Agile processes.
- Change the requirements or design whenever necessary -- after verifying with all stakeholders. Build extra time into the schedule for these mini-iterations.
- Keep an open mind about the phases. Don't be so stuck on defining the phases that you find yourself on a death march through them.
- Start prototyping during the research phase rather than waiting until the design is finished.
- Organize the project so the less critical features are implemented last; this allows you to omit the features if you run out of time.
To be successful with Agile, you can't blindly follow its principles either. You should keep in mind the following:
- Some projects or parts thereof benefit from thorough planning and design in advance.
- Sometimes you need to say "no" to user requests. (Unfortunately, not all user stories have happy endings.)
- Sometimes you have to place limits on a project's schedule.
No methodology or theory is a silver bullet. You can use any system to help you organize your processes -- though arguably some are better than others depending on what you're trying to accomplish. The lessons we learn from the failures and successes of each approach are far more valuable than adopting one or the other. Project success depends much more heavily on the people involved, and their ability to adapt the procedures as needed to meet the challenges they face.
The same principle applies to many domains. I've seen object-oriented code that clearly represented components of an application, and all developers have seen object-oriented code that obfuscated what was going on in order to satisfy a purist's notion of what object-oriented programming should be. Ruby (which is one of my favorite languages because it is so expressive) can very easily be monkey patched into an indecipherable nightmare, while I've seen PHP (a language that encourages badly organized code to the point that I've often said it must stand for Page Hacked to Pasta) that was so clear and well-organized it would make you weep tears of joy.
The theory is not as important as the way you put it into practice.Get weekly consulting tips in your inbox TechRepublic's IT Consultant newsletter, delivered each Monday, offers tips on how to attract customers, build your business, and increase your technical skills in order to get the job done. Automatically sign up today!
Chip Camden has been programming since 1978, and he's still not done. An independent consultant since 1991, Chip specializes in software development tools, languages, and migration to new technology. Besides writing for TechRepublic's IT Consultant blog, he also contributes to [Geeks Are Sexy] Technology News and his two personal blogs, Chip's Quips and Chip's Tips for Developers.