Fog Creek Software
Discussion Board




Help, before I go insane!

Or at least, anymore than I already am.

I guess you have read it all here before by so many people in so many forms, and no I have one of my own. A developer from hell.

I am not actually looking for help -- allthough every kind of advice is welcome, naturally -- I am just trying to put things in perspective by writing about it. Leave now if your not into some serious insanity (mine, or the developer from hell's, that's up to you).

The situation is: I am trying to define some (external) behaviour of an application. Basically this is a client-server system, with the server being an ancient DOS-system.
Both systems communicate via RS232 by exchanging messages (with commands or data) and the server is so ancient and of the pasta-kind, that any change should be avoided.
And, there is this developer who is responsible for making modifications to the DOS-application.

On many an occasion, when I suggest interaction between the client and the server to realise some expected behaviour, I get arguments.
Of the How-it-does-not-work-that-way kind, but of course not with the inclusion of how it would work.
Or of the This-is-not-good-design kind, but his suggestions are usually far worse in modest opinion.
Most of the time, he tries to simplify interaction by lowering the level of abstraction, not realising that that usually results in not-so-good design.

Example:
The server might need to reboot before activating some changes.
So I suggest the following behaviour:
- The client requests the changes.
- The server acknowledges the changes, but requests confirmation before it reboots.
- The client confirms and the server reboots, activating the changes.

Why? Because a reboot may not be necessary for every change.
Therefore, the client needs to know when the reboot is needed and ask the operator first.
It can be programmed to decide to ask the operator before even requesting the change, making the confirmation sequence obsolete. Or we go with my first suggestion.
Programming the client to know when a reboot is required is, IMHO, bad design, because you are know tightly coupled to the server. Any change in behaviour there, will need to be copied to the client.

Guess what my developer friend insists on?

Anyway, there's plenty more where that comes from, basically of the same nature.

Hmm, feel slightly better know...

Practical Geezer
Friday, June 06, 2003

Practical Geezer,

You have my sympathies.  Is he trying to shift all work into the client, so that he doesn't actually have to make any changes to the server.  That is understandable, because it isn't nice having to dive into the bolognaise.

Perhaps a comprimise is possible?  A config file downloaded from the server which lists the actions that require a reboot?  Far less satisfying, I know,  but at least the login isn't locked into the client.

Ged Byrne
Friday, June 06, 2003


A couple of observations:

1) How often are you going to update this system? If the answer is "rarely" then who cares if they are tightly coupled or not?

2) What percentage of changes are going to require a reboot? If the answer is "most" then just reboot every time a change is made. If the answer is "hardly ever", can you make the reboot a manual procedure?

We don't always agree on what is good design, but a simpler implementation is almost always better. And, while many here would not agree with many aspects of XP, the "YAGNI" (you aren't gonna need it) rule is a good one to live by: if you don't KNOW you're going to need a feature, don't bother designing for it.

Oh and, your relationship with the developer seems a little confrontational. That isn't going to help in the long run either.

Bruce
Friday, June 06, 2003

Ged says:
>Is he trying to shift all work into the client, so that he doesn't
>actually have to make any changes to the server. That is
>understandable, because it isn't nice having to dive into the
>bolognaise.

Actually yes he is, and no it isn't. And I respect that. In fact, one of the project directives is to change as little as possible to the existing code base.
Within reason of course. Not changing the code base and thereby condemning yourself to perpetual change in the client, whenever the server's behaviour is changed (because it is on occasion), makes for bad economics. Medium or long term of course.


Ged says:
>Perhaps a comprimise is possible? A config file downloaded
>from the server which lists the actions that require a reboot?
>Far less satisfying, I know, but at least the login isn't locked
>into the client.

Possible, but that would involve modifying the server too.
IMO, it would be far easier to trap the code that executes the reboot, and have it send a request for confirmation first.
Provided there is such a singular piece of code of course.
Besides, the action are, or can be, conditional. Meaning, you'd also have to specify under which circumstances an action would require a reboot.
Things get ugly quickly if you go down that road. By that measure, adding a confirmation request sounds like a day in the park.

Anyway, I think lack of experience and personal rigidity is a large factor here. This guy appears to be very prejudiced and sensitive. He seems to feel he should be in charge, because he knows better. I don't think he does, but I really only know my own capabilities very well.

Practical Geezer
Friday, June 06, 2003

Bruce says:
>How often are you going to update this system? If the answer
>is "rarely" then who cares if they are tightly coupled or not?

You can guess what product management says. Probably not as much as they wan't to. I don't strictly mind the tight coupling so much not to want to do it. But in the cases I do mind, it is usually because they have implications for the user interaction.
But more to the point, this guy does not say tight coupling in this case is not so bad because of the unlikelyhood of change
He says the solution that involves loose coupling is bad design. And conveniently fails to mention why of course. Maybe he is right that it is bad design, but given my and other people's experience that is unlikely. But not giving arguments why a different solution is better, is what pisses me off.

Bruce says:
>What percentage of changes are going to require a reboot? If
>the answer is "most" then just reboot every time a change is
>made. If the answer is "hardly ever", can you make the
>reboot a manual procedure?

It's a security application. You can't just reboot, so that leaves manual procedure. The only question is, do you always ask and reboot, even if it wasn't necessary after all, or only when it is.
Of course I prefer the latter, but that might not be achievable in the presence of my friend.

Bruce says:
>We don't always agree on what is good design, but a simpler
>implementation is almost always better.

Simpler for me always needs the addition, for the user. I prefer giving the developer a sweat once, over giving the user the willies every time she uses this developer's "simple" solution, or the maintenance engineer every time the need to work on the code.
Of course that is not always economical.

Bruce:
>Oh and, your relationship with the developer seems a little
>confrontational.

Apparently so. I would worry if no one else was experiencing the same.

Practical Geezer
Friday, June 06, 2003

In addition to reboot another factor is how widely distributed is the client.  If the client is widely distributed then updating is a serious serious nightmare.  Updates to the client must be kept to an absolute minimum. 

Even is the update is only to occur once every few years, if the client is widely distribute then you most certainly are gonna need it.

Thinking on it more I think your best solution is to create an extra server to act as a mediator between the legacy server and the clients.  This way you can have full control over these important aspects of server behaviour.

It could also simplfy interactation with the DOS server, since it will only have to cope with a single instance of the mediator rather than possibly concurrent clients.

Ged Byrne
Friday, June 06, 2003

Ged says:
>In addition to reboot another factor is how widely distributed
>is the client. If the client is widely distributed then updating is
>a serious serious nightmare. Updates to the client must be
>kept to an absolute minimum.

I forgot to mention this and you are right. Most of the behavioural decisions that I make, are influenced by this.
Right now there is only one client server, but in the future there will be, or rather, there should be, a multiple client situation.
The current client will be split and morphed into a server process that mediate between any number of clients and this legacy server.
That's why interaction between client and server now is on occasion more complicated that strictly necessary for the current situation.


Ged says:
>Thinking on it more I think your best solution is to create an
>extra server to act as a mediator between the legacy server
>and the clients. This way you can have full control over these
>important aspects of server behaviour.

Exactly. Fact remains though, that the clients are only intended as remote terminals, with no intellegence as far as workflow is concerned.
They offer users buttons to push and information on the system, but the legacy server decides what happens, when and why. Basically, because no-one really knows exactly when it does what or why.

>
>It could also simplfy interactation with the DOS server, since
>it will only have to cope with a single instance of the mediator >rather than possibly concurrent clients.

But the mediator still has to cope with multiple clients, so in order for it to be able to direct responses back to the originators, it adds extra information to the interaction, on top of what would be needed if there was only one client.
This concept seems to ellude my friend too, most of the time.

Practical Geezer
Friday, June 06, 2003

"I am not actually looking for help -- allthough every kind of advice is welcome, naturally -- I am just trying to put things in perspective by writing about it."

Wow, the one time a subject line like "Help, before I go insane!" was justified. Hang in there!

Joe

Joe Grossberg
Monday, June 09, 2003

Practical geezer, JOS is a forum for discussing managers from hell.


Monday, June 09, 2003

*  Recent Topics

*  Fog Creek Home