Saturday, September 22, 2007

Stupid Standard Protocols

You'd think that the people involved in defining the protocols for various data interchanges would be pretty smart people, wouldn't you?

Then why does every protocol I've had to develop for have:
  • redundant messages - a message telling you how many items are in a list, and an entirely different message with the list, which has a length count in it?
  • horrible bit-slicing sections where they take 3 bits to define a counter, then 1 bit for a flag, and then 4 bites for another counter?
  • messages whose size is not carried in the message at all, but instead in a wholly different message?
I guess that either the poeple going to standards meetings are dense, too busy sightseeing, or too enamored of their pet project to compromise well.

Technorati Tags --
, , ,

Wednesday, September 19, 2007

Sic Semper Tyrannus!

...the problem is what the "thus" is.

One of the big issues with the code at That Place is that since it has had nearly 15 years of development done on it, there are many tasks that have multiple ways to handle them - logging, socket output, RPC, etc.

This is a Bad Thing(tm)

As a good Ninja Developer, one must strive for a streamlined code base - make sure that there is only one way to do things, and enforce it with an iron fist.

I'm not saying that only one person gets to decide what to do - you can still make decisions by consensus, reading entrails, executive fiat (loser gets run over by the boss's convertible), whatever. But once you have a method in place, use only that method. Don't log some data in files, some in databases, and some to the console, all configured differently. Don't have some configuration by environment variables, some by files, and some from command line arguments.

The reason for this is simplicity - if your other developers, mostly non-Ninjas, have only one way to do something, they will:
  • never need to ask how to do X, since there will only be one way, and the code will have examples
  • never fix a bug in one system only to leave it in another
  • never have to explain how to set up the configuration for a tester more than once
Now, the trick here is the enforcement.

Also, it may well be that your team decides to change the way it does something. This is fine, as long as your team also makes the effort to convert everything to that new system. And this is where the tyranny comes in. You must be heavy-handed in insisting that all vestiges of the old system get removed, even if you have to drop a feature from each of the next few releases.

If you don't, you will have both versions lingering on, perhaps until you get a third version, and then your
troubles are multiplied.

Technorati Tags --
, , ,