What language?

Someone told me once: "If it ain't programmed in Java following the Extreme Programming principles, we don't want to buy the software." Arguing about why he put this statement so firmly, the person orated for an hour on the great advantages Java has in respect to more traditional programming languages. And in combination with principles from Extreme Programming the resulting software would be perfect. He was talking about policies put onto a system he was going to buy…

Do you care in what language your word processor is written? Delphi, Smalltalk, C++ or Miranda? Probably you don't. Why should you care then when it's a specific information system you buy? You should pay attention to this aspect, that's for sure. But, not because the syntax is so neat, and certainly not because some external bureau, (or a Guru on a seminar) has yelled that Java is the way to go.

So, why should you consider these aspects? For the use of the software itself you don't care what is under the hood; if it runs, it runs. But for the continuation of the system in the future it is a factor to consider. If an obscure programming language is used, it may be difficult in the future to find good programmers skilled in this particular language. This is definitely a risk for the quality of the software in the long run; as you know, people come and people go, also programmers. As for programming principles, let everyone program in on the way that works for them best. Just look for principles; are they available and used? The companies only stake is to have no surprises, in the quality of the software and in the process of constructing the software.

Like before, with the stakes you can do something. They're valid business arguments and leave some room to operate. Still wonder what the stakes were of the guy that told me "if it ain't programmed…"? I guess he has programmers employed, who want to program using way cool techniques they have learned at a seminar. But that's just my guess.

Are you thin?

Software architectural discussion are always the best. You draw four boxes with several arrows between them, and state that all systems should comply with this architectural design. "All systems should use a 3-tier architecture". I will not explain what it is (if you want to know, just look it up), only that in the segment where I operate there are very few systems that follow this architecture (at the moment I write this book). So, you have to build it yourself?

Searching for the stakes took my quite some time. Talking to toga's, dissecting there arguments, turning them over, looking up close, looking from far with my eyes almost shut… The effect of this policy is that on workstations less software is installed then traditional, the so called thin-clients, which seems to be easier to maintain. Second effect seems to be less network traffic, which allows the purchase of less bandwidth and saving money.

Ease of maintenance and saving money on bandwidth are in the end the original stakes of the company. Die hard technicians might now complain: "that's not the real power of 3-tier". Perhaps they're right. The point is, it doesn't matter. The requirement is formulated, correct or incorrect, but it's the stake that's important. So before redesigning your system you can consider cheaper alternatives for saving bandwidth and ease of maintenance. You go against the policies. But presenting the alternative requirements in such a fashion they keep supporting the stakes, is most of the time a winner. It is at least worth a discussion.

Respecting the unborn child

When buying a house, some of my friends want extra room for the kids, they might get, someday, maybe. They try to anticipate the coming of the unborn, better yet, the unconceived child. While purchasing a house this kind of anticipation is easy, one child is one room extra. You do the calculations.

Consider the following situation: the current system is in state of collapse, there is a technical necessity to replace the software. That's the cause and goal of a little happy project. Parallel to it are some larger projects, that are "strategic", and therefor have larger visibility and in perception a higher priority. Policy is you have to consider the "strategic" projects and keep in line with them. As you know "strategic" means large time frames, vague requirements, and big changes, sorry, reorientation. Try to keep in line with stuff that can't give you a date, or specific requirements, let alone, the quantified benefits. It's like saying to a professional athlete to keep in the same pace of this senior citizen with a Zimmer-frame. What do you mean, slowing down?

Again, the story becomes annoying, you should focus on the cause and goal of "strategic" projects, they can be considered as stakes. Try to create the situation where you can align with the projects when they have things clear. Try to avoid the situations where you make it impossible to align anyway. Don't say, forget it; "strategic" means a lot of higher people are watching, and giving the finger to higher management is always a bad career move.