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