API Chasing

It’s always important to distinguish the genuinely new from the repacked and reinvented. Large companies with lots of manpower are awfully good at taking an existing technology, putting a new spin on it, and then releasing at as something “new”. (The old new thing?). This then puts the competitors in the situation where they need to catch-up to the new API / gizmo / widget / whatever.

Know where you are leading, and where you are following. From a commercial, time and cost standpoint, API chasing is a bad thing.

Why does it take so long?

Why does it take so long to write really good software? Unfortunately, it seems that the devil is always in the detail, and things take longer than expected. I’m definitely not the only software developer where I have a bright idea, and I can conceptually see exactly what I want the software to do, but actually getting it to do that turns out to be a long and arduous battle.

Unfortunately, software is not a forgiving medium: for every situation where you can see roughly what you want, you then have to describe it in precise and excruciating detail to a CPU that has no intelligence whatsoever.

Another thing is writers block. If I’m enthused about something, then I can just code and code and code, but tricky details being what they are, sometimes, you have hours or days when the old grey cells don’t quite want to get themselves round the problem.

Another productivity issue is the extent to which you want to reuse code. Some people like being “hobby kit” programmers: they are very happy to take freely available bits of code off the web, and them sew them, patchwork quilt wise, into a product. The catch is of course that when it comes to code licensing, it’s not necessarily all theirs, and although it’s invisible to the end user, some of the hacks that get written to get unrelated modules of code to co-operate can be just plain ugly. A quicker way to get a product, but down the line, the developers start muttering, ewww. yuck!

Me, I tend to be a bit of a perfectionist, and I can write the code myself, I will. The downside with that is that after a decent software engineering degree, with the exception of things requiring specialist knowledge, I should be able to write the code for most things. Which means of course, that my default attitude seems to be “oh, I’ll just write a few more thousand lines, and it’ll be there.” Streaming systems, no problem, Object hierarchies, no problem, parsers, no problem, vector and matrix math, no problem, database persistence systems, no problem, interpreters, no problem…….

The problem is that when you want to write everything exactly the way you like it to be, it takes absolutely ages. It used to be that by the time I’d written five or six thousand lines of code, I couldn’t help but end up with some sort of a working program. Nowadays, I can write twenty or thirty thousand lines of internal structure, and still end up with a simple test program that has nothing but a text box, and two buttons on it! Ahhh…. such is the path of progress.

OO software: Corn is not beef is not hash.

My favourite bugbear. Appropriate delegation / compartmentalisation / structure in OO software. There are some excellent books concerning design patterns and anti-patterns.  The general rule of thumb is: stuff in a class deals with that class, and delegates to neighbours as appropriate. So:

  • The code that formats the message, is not
  • The code that retrieves the data that the message needs, which is not
  • The code that trawls through some structure looking for a target which might know how to deal with the message.

For those that don’t have time to read through the official textbooks, my rules of thumb:

Do one thing and one thing only in a function, examples:

  • Formatting a message.
  • Updating internal state on the basis of a message.
  • Delegating things elsewhere.
  • Performing some algorithmic calculation.
  • Converting from one format to another.

OO software works well on the basis of ignorance. Yes, it’s important that the code does stuff, but really good OO code works well when each bit of code knows only about a relatively limited subset of its own class, ancestor classes, and a minimal subset of stuff around it. Code should be as ignorant as possible. i.e. Keep your design contracts simple.

That means good OO software should be generic. Yes, some bits of code have to know the knitty-gritty of how some algorithm works, or how some data is structured, but in general, if your code does not know how to do X, and X is not locally or closely related to your class, then just delegate it elsewhere.

Joel-esque rant over.