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

The Big Three at the start of a Project

cue flashback effects......

revisiting a few topics from an old post, I was reminded today about some of the things that can make or break a project, that some thought at the start can alleviate much suffering.

Things your logging system needs to do:

1. be dynamic - you must be able to change logging levels on the fly without stopping any processes
2. be granular - you need to be able to segregate the severity of the log messages, so that you can eliminate detail as necessary (more on this below)
   
3. be muxable - you need to be able to route log messages to multiple different sinks - syslog, files, another server, etc
4. have a strong locality to the messages - know where they come from - process. thread. date. time. function, etc.

Things your configuration system needs to do:

1. be compact - have your configuration be in one place, a file or a DB
2. be dynamic, unless absolutely impossible - you want to be able to change config on a running process.
3. be contained in one function, so that if you trigger a reconfig, only one call needs to be made.

Things your feature setup needs to do:

1. be configuration-driven - you don't want to require a rebuild to enable a feature.
2. use the Factory pattern, and feature flags to drive it - so you can have one code stream.
3. have a single code interface to determine if something is in use - do not have an "enabled" function and a "licensed" function and an environment variable to set things.

Logging is a really big thing - some people prefer a levelled system, some prefer a bitmapped system. I have suggested a combined system - a level system for the basic part, and a bitmapped section for spheres of concern, like network access, database access, etc. An alternative is to have a keyword filter, so that you can filter on keywords as well as levels.

One logging idea that I have not yet fully fleshed out is a class-based logging - where every class has a logging flag that can be set so that you can log everything that instances of a given class does.

---

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

Eating My Own Dogfood

After trumpeting the virtues of making your codebase a single branch, modified by configuration data, I found myself drifting into the maze of twisty if statements, all alike on a recent work project. So I took a deep breath, hitched up my belt, and started all over again.
This time, I'm subclassing from the existing classes for the new message protocol. The project already as the Command pattern in use, so I'm subclassing the command object type, and the processing object type, and instantiating the command objects via a factory, so that the only thing that needs to check if the protocol is in use is the factory, based on the type of the caller.
It's a little more code, but keeping the logic of which protocl is in use tightly controlled will pay off, as this portion of the project is primed for a lot of new development as the current branch of the industry tries to hold off a new branch that has the advantage of decades of advances in telecomm technology.

---

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

Expecting too much from us?

I ran across this post last week. An admirable sentiment, perhaps, but one that, in my opinion, is unwarranted. Many, many software developers never approach the user interface side of the work, and they have no need for graphic design exposure.

I see articles like this, and wonder if the managerial types are trying to keep the developers from feeling like they already possess a valuable and necessary skill. In a manner akin to those "open ads" for a job that list a very specific set of qualifications, clearly intended to fit the already-chosen candidate, often one whose options are limited by immigrant status, or whose salary is low due to being overseas, this begins to feel like a way to tell the existing developers "You're no longer good enough, we don't have to hire you unless you're a polyglot Renaissance man"

---

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

More validation of my opinions

Not that I need much.....

It was written for "artistic" types, but applies to software types

Points 3,4,9 and 10 resonate most, pity too many developers feel differently about OOP

---

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

Like I said......

Someone else has seen the "Back where I used to work, we did things different" syndrome
Clinton Forbes

So remember folks, don't treat your new cow orkers like idiots, or they will hate you for it.

---

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

Turnabout's Fair Play

Today, driving home, I had a mild epiphany.

You have no doubt heard the manager-speak where they call a problem "an opportunity", one of the more hated turns of phrase I know of.

Well, I just thought that what's sauce for the goose is sauce for the gander...

When managers discuss bugs, refer to them opportunities. You know, a chance to improve the codebase.

---

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

Another Stupid Cliche - The Ninja Rants Again

It always happens, in every job. Some well-meaning managerial type has a chat with you about dealing with external issues, and that phrase comes up:

"You have to own the problem."

This always happens when the discussion is about someone outside your area has a problem and they want your help. They can't be bothered to provide all the necessary info, even if they are well-aware of what is needed, and they can't be bothered to follow-up on the issue, so you have to "own the problem" and spoon-feed them the answers, and god help you if you don't.

I always wonder why I am the one who has to "own the problem", and not the person who brings the problem to me? And why I am expected to be able to solve the problem against all odds without any increase in my authority, budget, or rank? It's particularly galling when you discover that the problem does not lie in your area of expertise, but are expected to pursue the problem to the next expert, instead of informing the one who came ot you, and letting them carry it to the next expert. Why aren't they "owning the problem"?

One of my theories about this is that managers don't want to appear as if their staff cannot solve problems, so they expect their staff to be the ones to "solve" the problem by carrying it to the end. It garners much praise from the upper managers, because they don't have to actually manage the problem. It might be an effect of continual delegation - the upper managers might rightly delegate a problem to an underling, but that underling still has enough authority to encompass the entire solution. This rule falls apart when you reach the lower levels of management, because the solution may not fall under the authority of that delegate, and that causes difficulties - the delegate now cannot command obedience to get the answer. And so the lowest level of management follows the trend, and expects the contributor level to magically influence others at their own or higher levels to help solve a problem that they have less then immediate data about.

---

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

Software is like an ogre....

...it has layers

(sorry for the Shrek reference....)

Most developers are at least somewhat aware of this, since we all see the usual network protocol stack diagrams with 3-7 layers, and the MVC design pattern/paradigm, and so on.

What I am starting to think is that this pattern is not being used enough. We have our GUI layers, our database layers, and our business logic layers, but we tend to have a single program running as the layer.
After a recent push with work to have a VP's pet project done, I had the chance to build a "server" that was calling several standalone executables to perform specific tasks. What I got from this was that it followed the UNIX way better - I had smaller, easier-to-debug pieces that could be re-used on other projects without having to alter basic code. The big use would be for test harnesses - by having standalone executables, the test crew can write shell scripts to drive their tests, which relieves the development team from having to provide all the integration test code.

Now, this does not work in places where serious speed or efficiency is needed. But many programs are driven by user input, or easily-paced timers, and the benefit of the encapsulation can pay off later.

Also, many developers will point out that libraries can perform similar functions. They can, but alternate use requires they be linked in to the calling program, which can be problematic for testers, who typically have a) less software writing experience, and b) less support structure to write code in.

---

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

Being TOO Careful

A program at work gave me a bit of trouble these past two work weeks (the holiday break interrupted the debugging).

It's a process manager for the product, allowing the user to start and stop the various parts of the system, and it also monitors the processes to restart them if they fail. Basically, all the same stuff initd does under Unix, but for the specific system applications.

Now, for some reason, it does not keep its list of child processes in memory, but uses the 'ps' function to get them, filtering the output to eliminate things using the executable name in other ways. However, it expects the executable to be the first thin in the command line section of the output.

That's it - no provision for an interpreted script at all. And my most recent work is a rapid-prototype server in Python. So it can't be controlled from the manager. And it's buried in old, barely managed code, so I'm reluctant to dive into that swamp without managerial mandate.

(To be fair, this is one of the oldest parts of the system, written over a decade ago, so it was probably not a high probability that interpreted languages would be used in the system at that time. But it still was a real pain to have this float out of the miasma of reported bugs coming from the 3 sets of testing staff.)

Fortunately, Python's embedding feature saved me here; I was able to throw together a quick C++ wrapper that would call the Python script, waiting for it to exit. So now I get the monitor to start and stop it cleanly, but keep the useful parts in Python.

There is a plan to move the code more to C++, but the need to do several things that we have no C++ libraries for will keep some Python in the mix.

[Later]
Mea Culpa, Readers! I forgot to relate the moral of this story, in all my bitching and moaning.

The Lesson: When filtering results, the Software Ninja makes sure the filtering code is a) separated into an independent function, and b) make the filtering criteria very clear, so that the next developer to work on the code can change the filtering if necessary, and will understand what is being filtered out.

---

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