How the Sausage Gets Made

I saw one of Jeff Atwood's Coding Horror posts where he states that nobody cares if the code you write is ugly code or not, as long as it works. While I have some basic agreement, I have a big qualifier - if they are a customer and do not expect to get bug fixes from you, they don't care.

However, if they expect you to fix the bugs they find, or are your manager, they do, or at least should care. Ugly code is harder to maintain, harder to improve, and sometimes harder to find developers to work on.

Jeff has a point, that trying to make code pretty without a business purpose is programmer vanity, but there is a cost to using working, but bad code. This article about technical debt is a good discussion of the tradeoffs.

---

Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP

Pilot Error

aThe Job had an interesting filed issue, one where a running process had its RPC binding hijacked by a manual invocation of the same program. This had the puzzling effect of blocking new connections, while leaving existing connections intact.

So the Ninja Lesson from that is twofold:

1. servers must be controlled so that an accidental start will not clobber an already running process
1. this means making all your '1-of' initializations must be explicit, and after the check for an already running copy
2. you need a check for already running copy
2. you need to make it difficult for your servers to be accidentally invoked
1. make a user for general observation/maintenance not have execute permission for your servers
2. remove the server directory from the path

These will help prevent this problem

---

Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP

Put up guardrails!

Stop programming like the architects of Star Wars - the same idiots who failed to put up guardrails around bottomless pits.

From the "Just Last Week" files:
I found out that a very bright developer wrote code made the bad mistake of thinking that he would always be the only developer in charge of his code. He wrote multithreaded code that did not protect a very useful, method-laden collection of data from simultaneous access by 2 or more threads. His rationale was that he would, by convention, only access the dataspace from the main thread. Then he had the gall to get transferred away from the development group, and The Ninja got his code. And promptly found there were several cases of a secondary thread accessing the dataspace, the unprotected dataspace, at the same time as the main thread was modifying it. The predictable result was a program crash.

You cannot ever expect the developers who follow you to know or remember all the little rules you've set up for your own little code kingdom. You ignore the Best Practices at your own peril. If you are working in a multi-threaded process, you must assume that all threads may access a global data structure, and if it gets modified, those accessing the data will crash. Assuming that the next guy will not tromp on your daisies is foolish.

---

Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP

Too Much Information

I'm all for the freedom of information, among individuals. In the corporate world, there are sometimes
good reasons not to tell someone part of the story.

Case in point (with serial numbers filed off) - a discussion last week touched upon an old release, where there was a big improvement in performance, brought about when a developer found an inefficiency in transaction processing, removed it. In the process of this release, upper management was pressing for a rationale, and someone offered a detailed explanation of the issue, using the names of the various classes in the code. Because some of the class names were chosen for their purpose in the code, they had a rather ironic connotation in the situation. This led to essentially a disparaging attitude towards the development team in upper management, which is never good, because then the expertise of the developers in their field is undermined.

The Ninja Solution(tm) is to implement a Gaussian blur for the information when talking to upper management (anyone higher up than your immediate superior). Never mention class names to them. Never describe the algorithms by the code names - blur out that level of detail. This prevents the bosses from finding humor in their misunderstandings of the code flows.

Note that this is not a license to lie to them - just to tweak the level of detail you use to report upwards (and sideways - program managers don't need to know class names either.

---

Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP

A Note To Managers

A note to managers:

When your staff tells you that they cannot under any circumstances do a particular thing, LISTEN TO THEM! Do not keep asking them to do something that they have strongly stated they will not or cannot do. It will only serve to make them feel that you do not care about their issues at all. It will undermine morale, demotivate them, and make them less likely to expend extra effort to further the job, since it will felt as excessive sacrifice, given that they will be asked to do more and more later on.

---

Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP

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 --
Software, SoftwareDevelopment, Computers, Programming
HTTP

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 --
Software, SoftwareDevelopment, Computers, Programming
HTTP