Featuritis: Cleaving to the Big Picture

A gray rubber mat sat in front of me as I figured out the rough dimensions needed so it would fit snugly in our car. Once I knew where the various slits and slots needed to be, I grabbed a pair of scissors and started to cut, being very attentive to cut in a straight line.

After cutting a few inches my eyes wondered up to the top of the gray mat. To my utter dismay and disgust, I found that I had indeed cut a straight line... that was off by about 20 degrees. I had been so focused on cutting a straight line that I hadn't confirmed that my line fit with the bigger picture.

Infected

Most programmers, myself included, seem to infected with the featuritis virus, the one that eats at us trying to convince us that we absolutely must build extraneous features or implement a design pattern that we think is necessary only later to have this new feature sit stagnant and untouched. It's a vile little virus that wastes our time and diminishes our ability to meet the truly important goals.

Goals

The problem with featuritis is that it distracts us from our ultimate goal -- to develop, as quickly as possible, quality software that meets its users needs and provides no unnecessary features. I'm going to concentrate on only one part of this -- meets user needs.

If we build an unnecessary feature, the program will take longer to build than is necessary. If we must consistently retest some feature, we're wasting our time. If we must consistently work around a poor architecture, design, or implementation, we're wasting time.

Defeating Featuritis

So, how do you defeat the despicable virus? Acceptance test driven development, a form of top-down design.  In brief:

1. Write an acceptance test first. Don't lose sight of the end-user need.
2. Write only the code necessary to satisfy that requirement. This will often entail writing many different unit tests, each of which exercises part of the user's required functionality. Be diligent; be strong. It's hard, but with the end-goal, or big picture in mind, progress is evident.
3. Refactoring to follow the single responsibility principle (SRP). When you keep your code clean, it's much easier to spot when you start getting off on tangents.
4. Repeating the above steps as necessary

The above is also known as acceptance test driven development (ATDD).  A much richer explanation is available in Lasse Koskela's Test Driven. He has a sample chapter available that explains ATDD.

Remember the big picture, the ultimate goal.  Whenever I forget, I ultimately regret my lack of foresight.  When I get distracted by scenery, I don't end up where I want to go.