Saturday, June 06, 2009

People should not use patterns!

What has gone into Siderite and made him rave mad? Is he high? Everybody knows that software patterns are all the rage and the only perfect and delicious way to make software. You can't just go "cowboy style" on software, it's an industry after all.

Well, I am not saying that (although you can probably guess from my impression of my virtual/inner critic that I am a bit partial to the cowboy approach). All I am saying is that once you identify a pattern (and yes, to open another parenthesis, a pattern is identified not learnt) one should never stoop low enough to use it. Some software should do that for him!

One good example is the Iterator Pattern. It sounds so grand, but the software implementation of it is the foreach command. Does anyone actually think while iterrating through a collection that they are using a pattern? As I said before, patterns are identified. You think of what you have been doing, see a pattern, make some software to take care of similar situations, then get on to identifying another pattern.

Well, yes, but you can't entrust everything to a software, Siderite! You will bloat your code, create tools that will do less than you wanted and still end up doing your own efficient code. I know, I've seen it before!

Well, thank you, critic! You have just identified a pattern! And any pattern should be solved. And yes, I agree that software can't do everything for you (yet!) and that sometimes the tools that are designed to help us with a problem become a problem themselves. But instead of having "two problems" you have a bad solution to a previous problem. Fixing the solution would fix everything and the problem domain is now one level of abstraction higher.

Stuff like managed code, linq, TDD, ORMs, log4net... just about every new technology I can think of, they are all solutions to patterns, stuff that introduces new problems on a higher level. What C# programmer cares about pointers anymore? (developers should still be aware of the true nature of pointers, but care less about it).

There is one final issue though, the one about the actual detection of patterns. Using "prediscovered" patterns like from the classic Gang of Four book or anything from Martin Fowler is ok, but only if they actually apply to your situation. That in itself shows you have to have a clear image of your activity and to be able to at least recognize patterns when you see them. Sometimes you do work that is so diverse or so slow that you don't remember enough of what you did in order to see there is a repetitive pattern. Or, worse, you do so much work that you don't have time to actually think about it, which I think is the death of every software developer. Well, what then?

Obviously a log (be it a web one or just a simple notebook or computer tracking system) would help. Writing stuff down makes one remember it better. Feeling the need to write about something and then remembering that you have already done so is a clear sign of a pattern. Now it is up to you to find a solution.

Back to the actual title of the post, I recognize there are situations where no automated piece of code can do anything. It's just too human or too complex a problem. That does mean you should solve it, just not with a computer tool. Maybe it is something you need to remember as a good practice or maybe you need to employ skills that are not technical in nature, but should you find a solution, think about it and keep thinking about it: can it be automated? How about now? Now? Now?

After all, the Romans said errare humanum est, sed perseverare diabolicum. The agile bunch named it DRY. It's the same thing: stop wasting time!