Andy Hunt and Dave Thomas on Programming

Andy Hunt and Dave Thomas published the Pragmatic Programmer in 2000. As the name implies, it is a practical book consisting of various tips and techniques that the authors have found to be helpful in their programming experience. Here are three tips that I found to be particularly helpful. All quotes are theirs unless otherwise noted.

Refactor Early, Refactor Often

Software Development is Organic:

Unfortunately, the most common metaphor for software development is building construction.

Software is more like gardening — it is more organic than concrete.

You might want to explain this principle to the boss by using a medical analogy: think of the code that needs refactoring as a “growth”. Removing it requires invasive surgery.

You can go in now, and take it out while it is still small. Or, you could wait while it grows and spreads — but removing it then will be both more expensive and more dangerous. Wait even longer, and you may lose the patient entirely.

Be a Catalyst for Change

Software Development is like Stone Soup:

You may be in a situation where you know exactly what needs doing and how to do it. The entire system just appears before your eyes — you know it’s right. But ask permission to tackle the whole thing and you’ll be met with delays and blank stares. People will form committees, budgets will need approval, and things will get complicated. Everyone will guard their own resources. Sometimes this is called “start-up fatigue.” It’s time to bring out the stones. Work out what you can reasonably ask for. Develop it well. Once you’ve got it, show people, and let them marvel. Then say “ of course, it would be better if we added….” Pretend it’s not important. Sit back and wait for them to start asking you to add the functionality you originally wanted. People find it easier to join an ongoing success. Show them a glimpse of the future and you’ll get them to rally around.

Don’t Gather Requirements — Dig for Them

Software development requires manual labor before writing code:

Many books and tutorials refer to requirements gathering as an early phase of the project. The word “gathering” seems to imply a tribe of happy analysts, foraging for nuggets of wisdom that are lying on the ground all around them while the Pastoral Symphony plays gently in the background. “Gathering” implies that the requirements are already there — you need merely find them, place them in your basket, and be merrily on your way. It doesn’t quite work that way. Requirements rarely lie on the surface. Normally, they’re buried deep beneath layers of assumptions, misconceptions, and politics.