Doing what you think you want to do

Spend more than 5 minutes in software development and you’ll come across with plenty of rules, guidelines and traditions about how to write software so it doesn’t spontaneously combust. Sometimes these are not much more than anecdotes: “Bob once tried to use technology X and it failed horribly. I wouldn’t ever dream of using technology X because of that.”. Sometimes they have catchy name: “DRY, Don’t Repeat Yourself“. Sometimes they are semi-formally specified in form of software design pattern. In any case, there seem to be lots and lots of guidelines about what to do and what not to. And it’s good, because writing software is hard, complex and difficult undertaking.

But it makes sense to remember that every rule has an exception (including this one). There are times when one goto statement would save the day, but since many developers (very rightfully) consider goto statements bad, we try to work around the problem with other tools. Resulting program might work, but the code might not feel particularly satisfying (satisfying is quite subjective method of measuring things though) or it would have overly complicated looking structure (or just plain funny).

These patterns, principles and stories exist for reason though. Plenty of hours have gone into testing and honing them. It makes sense to know them and learn from them. But they shouldn’t be considered as hard set rules that can’t be broken under any circumstances. They also shouldn’t be considered just humbug and old stories that don’t hold any relevance in modern software development.

What I have tried to pay more attention recently is to really think how any given change or decision is likely to change the current situation. At the same time I have been trying to objectively gauge how well my past decisions about code are working in current situation. Sometimes this slows me down quite a bit as I spend a day or two pondering over pros and cons of having global state in my program. As a result, I have a wider selection of tools at my disposal and can try and choose the most suitable of them in any current situation.

Too long, didn’t read summary: rules are good as they (mostly) keep you from doing silly things. But when you know the rules and reasoning behind them, you can sometimes step over the lines and deliberately break them.


Leave a Reply

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

You are commenting using your 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 )

Connecting to %s