Showing that fear of mediocrity can make the world a better place.

When features become patches

Should a feature be explicit?

As far as I am concerned a feature should be explicit. There should be little guesswork in the code about the feature. There should be a definitive attitude to the code that shows the structure and shape of the feature. In kitchen design a feature could be adding a stove. Once installed the homeowner shouldn’t have to guess where the stove is or how it works. The stove should blend in enough that it doesn’t look bolted on and it should become a part of the whole design. The key word there being design. There should be evidence in either a kitchen design or software application that the feature was put there on purpose and with a nod towards a larger picture.

Is my patch a feature?

Probably not. You created the patch to plug a hole in the original design. The patch is an ugly and utilitarian section that demonstrates the need for a better design or at the least a new solidly constructed piece. The patch doesn’t need to be designed since it is a quick fix. Like most patches though, they were not meant to be long-term and the structural integrity of the component shouldn’t and can’t be trusted. Patches are quick and they allow you to keep moving despite a minor setback.

So what do you have against patches?

Stop patching it already

Stop patching it already

I have absolutely NO PROBLEM with patches WHEN USED SPARINGLY. However, there are some people who refuse to design and segregate a feature from a patch. Everything they develop is a patch. It is just enough to keep the system running without any of the structure or explicitness that a feature would have. It is a cop-out and pretty soon the developer can produce nothing but patches. That’s great if you think you are in a race where you might need to sacrifice in the short-term to win the race. But when patch it up and put it back in the race (production) becomes your motto then you start to develop serious issues. Eventually the system becomes a worn down and tired mess of code in serious need of some structure. Each patch has degraded the stability of the system and worn away any explicitness. Everything becomes an implicit relationship full of “yeah, but it reallies”. Don’t know what a “yeah, but it really” is? If any of these sound familiar:

  • “Yeah, that method saves the data but it really deletes the data and creates a new record”
  • “Yeah, that should work but it really doesn’t”
  • “Yeah, that piece of code exists for a reason but it really isn’t used by anything”

then you might have come across a patch that should become a fully designed feature.

If you want to be a patch-master: fine. I don’t care.  But when you are a patch master and a micro-managing senior developer who has to approve every design change then I care.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s