Friday, November 14, 2008

Sometimes I annoy my employer with my programming...

...but not the way you might think.

I'm not a Windows programmer. Most computers run Windows (or some "windowing" operating system, like OS/X or Linux). It's what people expect these days.

But I'm a luddite about computer programming. 640K was good enough for Bill Gates (just kidding... it's often attributed to him, but there are no citations). It's good enough for me. In fact, I almost never use more than 128K of RAM (the old DOS small memory model -- it's what my favorite C compiler generates).

And if you're programming for an old-style DOS computer, the Disk Operating System (DOS) and Basic Input/Output System (BIOS) are very helpful, but you don't have to use them. If you want to talk directly to the hardware, you are free to do so (just like an embedded system...)

I've tried to get my feet wet in Windows programming, but never could. I always wound up with something like "I want to call function _foo() here. What do you mean I can't -- it's not in my class inheritance!?!? And, despite what the manual says, the compiler won't let me call it classlessly. Grrr... time to drop this steaming pile of ****". Or, trying to do a simple system call, you need all sorts of funky constructs like "try ... catch" for error handling. Of course, you still need an error return, so your program knows if it can proceeded. But you still need to do tons of special error handling to satisfy Windows (and the compiler), on top of what you need to write to make sure your software works smoothly.

The upshot of all this is that, when working on an embedded system, chances are that you need to simulate the "other half" as well. It may be a simple potentiometer that varies the simulated input to the system. It is often a computer program that pretends to be another part of the embedded system. Or it could be a PC program that sends setup / calibration information to the embedded system.

When I need to write the "other half", I write it as a DOS program. It works. It's fast and (for me) very easy (I have about 20 years of software to draw on for snippets).

So, I now have a program that took me a day or so to write that lets me talk to / calibrate / whatnot the embedded system I'm working on. Great! Except for one thing...

When it's time for me to hand the project off to someone else, they ask me how to setup / calibrate / whatnot the system. What I use is my DOS program. I can give them a copy, but:

1) They don't like it (not pretty enough, I guess...)
2) Management does't like it (not corporate standards or something)


So, why not get the equivalent Windows program written? It can't be that hard, can it? It only took me a day or two, and I can give them all the algorithms, data structures, and whatnot.

But it never works that way. It often takes a couple of weeks to get the equivalent Windows program written. Sometimes they never do get it written.

And this is why my employer gets annoyed...

3 comments:

pebbles said...

You could always call them "n00bs."

Bill said...

Naw... lots of them are experienced, professional programmers. And with the variety of programming platforms and tools out there, I could easily be considered a "n00b" for my limited world view.

I just find it interesting that my "antique" tools make me more productive than the latest whiz-bang slick GUI tools.

pebbles said...

GUI's are for n00bs.
In my humble opinion.

I'd be fairly impressed to find someone whom could paint by numbers.

Bitmaps presumably.

I find the appreciation for efficiency much more respectable than any memory hogging whiz-bangs.
Hell, I'd even say you're all the more slick.