Many times trying to write about experience is tough! It's easier to tell people about what can really fix things within an IT shop, or organization, within your programs themselves, or within the systems you use by telling a very poignant story filled with amazing gems of wisdom that will change all of your lives quickly efficiently and help you remember the lessons learned from them. But, what story should I use? I write these articles so late at night…. [YAWN] [CLUNK]
As Andrew's head hits the Mac's keyboard (nose firmly planted on the G key… gggggg…) he's visited by the people who gave him a lot of wisdom in his past…
First to arrive is his partner and owner of the consulting firm he worked for in South Florida, Jim Lyall (because Jim is completely healthy we're assuming Jim is a skilled lock-pick and can disable a Brinks alarm system in under 30 seconds, and is so light on his feet that he entered Andrew's house without waking up the dog… honestly, it isn't that hard to do as Andrew's dog isn't a good guard by any stretch of the imagination).
"Andrew… I'm here to tell you that you're going to be visited by three sets of ghosts. The ghosts of projects past, a ghost of projects present, and a ghost of projects future!!"
"Oh! Thanks Jim! Are you staying? Need to stay the night? How's Ellie?" With those words uttered, Andrew falls asleep again.
ggggggggggggggggggg…..
At one o'clock in the morning, Andrew is visited by Jim Franz, (another healthy person) his other partner at the consultancy. Jim used similar methods to sneak into Andrew's home and awaken him while not alerting the dog…
"You know Andrew," Jim starts, "if you look at some of the programs you wrote, there's not enough documentation within them."
"But there's a header describing the programs purpose" Andrew sputters. He then looks a little closer. And yes – many of the lines are documented:
* If Field1 is less then Field2, add 20 to Field2
IF FIELD1 < FIELD2
ADD 20 FIELD2
ENDIF
"See, it's documented!"
"No, Andrew," says Jim, shaking his head. "That's code. The programmer that follows you into this will never understand the business decisions that caused FIELD2 to have 20 added to it."
Jim is right -- it should have read:
* Due to seasonal differences in taking inventory while drinking spiked egg-nog, John in the warehouse is always 20 low on his counts of the inventory. Per Jane the purchasing manager.
IF FIELD1 < FIELD2
ADD 20 FIELD2
ENDIF
This documentation contains the key information to understanding the program: The who "John is low on his counts" and what "add 20 to inventory" – and the who requested this "Jane in Purchasing" supplying the why and we know this now… because it's documented.
Many people look at their program, and jot down these snippets of documentation that mimics the program, not the actual reasons behind it. The people following you into the programs you write, are also programmers – so no need to teach them about programming. So the why something happened is far more important then how. This is a ghost of projects past, because it has the potential of changing the future of how these programs are modified. We need to keep that in mind when creating documentation within our programs.
And then Andrew's head falls to the computer… .
ggggggggg….
"WAKE UP!!! Why are you sleeping at your kitchen table!" as Dennis Leon, one of my managers at my current company says. Again, he had to pick the lock, disable the alarm, give a snack to the dog, and a partridge in a pear tree.
"The servers are going nuts!" Dennis exclaims. "We're being bombarded by visitors to the Web sites – what's happening?!? We should watch the sites like a hawk!"
Suddenly, we are forced to watch something instead of programming or other activities. Isn't there monitoring software? That answer is: YES! We all would love to have that guy that doesn't blink, and watches 1000's of activities going on in a computer all day long, but the reality is someone's going to pass out. Heck – I passed out writing this article!
Monitoring software is so important to a large organization, but all companies can benefit from being informed of things when they happen. Using ICOM/400 or ROBOT systems monitoring tools, companies can watch what's happening, and pick and choose what activities are watched a little closer. Sometimes you can also put complete responses based on business rules. Responses such as: files filling up. You want to know about space problems on your servers (80%.... 90%!!) and even "Record not added" so you can extend the files to the sizes you can manage, and know why they are filling up. Return on investments for monitoring software is easy to justify because you're preventing down time.
Andrew's head hits my computer again for the last time …
ghhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh….
.
Because Andrew doesn't have a future job in mind (although Dennis may decide Andrew should after reading this) he is visited by a third ghost – the ghost of projects future!
The ghost arrives adorned in a robes with words "Java/PHP/Web Programming" written all over them.
Yes – any projects you do in the future must include potentially using the Web while designing them. Why? The Web is the most distributed your computer programs can be and still automate internal processes within your company. From contacting customer service, and making sure all messages are being answered, to a full blown business-to-business website, or a commerce solution to help sell your companies products, all future computing projects must take Web usage into consideration.
You must strive to make your programs more object oriented. Create them as reusable tools that any project or program can use quickly for faster future deployment. These programs enforce business rules, but are also small and easy to maintain because when they change, all the processes using them change -- just like magic.
People need to make time to become more versed in the Web languages. They are all very powerful, you simply need to make a choice, and learn the nuances of all of them before you make a decision on which technology is best. In today's IT world, there may be many solutions within your organization.
So did we learn from these ghosts? Will we learn from our ghosts?
It doesn't matter!!
Kid! –yes, you – here's a pocketful of change. Get me the largest turkey at the market!
Happy holidays to all, and to all a good night…
ABOUT THE AUTHOR: Andrew Borts is webmaster at United Auto Insurance Group in North Miami, Fla. He is a frequent speaker at COMMON and is past president of The Southern National Users Group, an iSeries-AS/400 user group based in Deerfield Beach, Fla.
