When is overkill, really overkill?

[Barrie]

Hello All:

I have just ended my exile in the Simpson Desert in Australia and I'm now on to a new project. I expect it to have around 500+ VIs and about 8 separate processes.

My new task needs determinancy and it needs a GUI. One obvious solution is some kind of RT based front end coupled to a PC.

Unfortunately, I also need a graphical display that also has a good update rate and determinancy, something that RT can not provide.

There are a number of ways I can go, but that is not the topic of this post.

When is overkill really overkill?

Processors, memory and disk space are so cheap, that it's tough to avoid the tendency just to find the latest and greatest and use it. As a matter of fact, that is what I think I should do. I might even use 2 PCs and an RT box.

Having all this power means that the code may not be as efficient as possible, but tuning, setting threads and priorities etc. all takes time, and as we all know time is money.

Perhaps this thread is partially out of guilt, but part of being a good system designer is being pragmatic. Many of us here are also businesspeople.

So, I thought I would just throw this out to the group and get some feedback.

Disclaimer: Before any purists jump on me, I know we would all like our apps. to be clean, efficient, elegant and optimized, but we also have to eat. Apps that don't get delivered, don't get paid for. No pay, no :beer:

I look forward to your thoughts.

[crelf]

The Simpson Desert?!? Sounds like you need a drink!

Although I agree with you in principle, I can't stress one thing enough: up-front design. You really need to spend some time (ie: money) at the start (especially since it's a multi-component system) and that'll save you a bunch later on. Whilst you might not be concerned about making a system perfect, with a decent amount of fore-thought, all the components should fall into place with a little thinking about the glue to interface them together.

(I haven't been out to the Simpson in years - where were you?)

[Barrie]

The Simpson Desert?!? Sounds like you need a drink!

That'd be right. I did crack a tinny or two when I got back to Melbourne.

Although I agree with you in principle, I can't stress one thing enough: up-front design. You really need to spend some time (ie: money) at the start (especially since it's a multi-component system) and that'll save you a bunch later on. Whilst you might not be concerned about making a system perfect, with a decent amount of fore-thought, all the components should fall into place with a little thinking about the glue to interface them together.

I agree completely, the choice of interface points and division of tasks is key. No amount of horsepower can compensate for bad architecture. My point is that some sloppiness has an economic advantage. The question is: How sloppy is too sloppy? The concept is an anathema to good programmers.

(I haven't been out to the Simpson in years - where were you?)

All over actually, but it was mostly the Simpson and the Strzeleki; Moomba, Dullingari, Birdsville, Innaminka, Della, Gidgealpa. Our break in civilization (?) was Broken Hill.

[crelf]

Crikey! That's some trip!

[Mike Ashe]

... <snip>

When is overkill really overkill?

Processors, memory and disk space are so cheap, <snip>

Disclaimer: Before any purists jump on me, I know we would all like our apps. to be clean, efficient, elegant and optimized, but we also have to eat. Apps that don't get delivered, don't get paid for. No pay, no :beer:

Well, that last point ( :beer: ) puts an upper bounds on the overkill ...

The limit of engineering elegance, as overkill approaches "no :beer: " is ... Q.E.D.

On a semi more serious note, I try to look at what the realistic prospects are that the system, once delivered, will then be either reused or extensively modified post delivery. Feature-creep often makes what initially seemed like overkill into near clairvoyant foresight. I've been beaten about the head and shoulders for "overkill" before, only to have my praises sung later when it became apparent that we needed to make large additions and mods and the architecture and hardware were already in place to support that.

I've also had the experience where I made it so easy to make mods that I "overkilled" my self out of the follow on work because the client was now able to do it on their own, one of those cases where you're both proud of the result and hitting yourself on the forhead at the same time.

That being said, if you are pretty sure that this is a One-Off system, then I'd lean towards just getting it done, as quickly and as cheaply as possible and moving on to the next project. Managers never ever ever complain that you came in too far under budget and schedule and that you should have spent more time, to the point of "overkill".

.... My point is that some sloppiness has an economic advantage. The question is: How sloppy is too sloppy? The concept is an anathema to good programmers.

Maybe, but really great programmers have an honest appraisement of their own programming ambition and know how to make trade-offs when business factors outweigh or mitigate engineering elegance. It sounds like you are well aware of and quite willing to make those trade offs.

Good luck and good :beer: