While working at a former employer, we were required to take a series of courses to help us all with inter-personal skills. In one of those classes we were encouraged to keep asking "Why?", at least three times, whenever we were discussing an issue and felt that we had found a root cause. Why, you may ask? (OK, there's 1!) The idea is that by continually asking "Why?" we may uncover a deeper, more basic issue that needs resolving. Getting to that deeper level may solve more than just the obvious problem.

Since that class I have tried to apply that concept to application development. It has some obvious applications as it relates to discussing requirements with users. The more you as "Why?", the more you understand the processes used and the core reasons for those processes. Too many people, when asked how they do their job, will tell you something like: "I take a 1 and a 4 and a 6 and a 2 and a 3". OK, what application is this? I suppose the answer is "pretty much any". Getting to the root of how things are done and "Why?" makes for a better application.

At that same company there had once been an application written for the marketing department so they could extract account information from an order history database and use that to send catalogs to those customers. The order history information resided across two separate boxes. The application designed required the marketing department to sign on to each box when steps were required to process data from that box. This meant switching back and forth between systems several times before a coherent list could be achieved. This became too cumbersome and confusing for the users and, after a while, they reported to IT that they were too busy to use it, could IT do the extract for them?

After several years of IT taking over that process, they re-wrote the application, but failed to note the underlying issue: the system was cumbersome. The new application was better than the old, but still required the users to jump back-and-forth between systems. Again IT was asked to handle the extracts because marketing was too busy.

The next time around was my turn. Apparently I asked "Why?" enough times. Instead of having the users jump between systems, I setup a single interface to the application on one of the systems. There would no longer be any question as to which system they would need to access. From their perspective, there was only one place to go. Data needed from the other system would be retrieved using DDM and data would move "under the covers" to its desired location. Now it was simply a matter of moving from step 1 to step 2 and so on.

The end result...no more IT involvement.The problem wasn't that marketing was too busy, the previous systems were too cumbersome and confusing. Digging a bit deeper uncovered the root cause and made it possible to solve.

Whether the questions are "Why?" or "How?" or "When?", keep asking those questions, even after you think you have the answer. You never know what other, more basic issues you may find.

I've been in this business for over 26 years now, so there is a lot of junk in that attic that I call "brain". Hopefully, there are some useful items, too, but every now and again I remember something that I did "way back when" and realize that I'll never do that again. No, I'm not talking about things I did in college (it's even more important that others forget about some of those things). I'm talking about little tips and tricks that I've learned along the way.

Take date conversions. We have all had to deal with a date stored in a database as a numeric value. Sooner or later we need to convert it from one format to another. That's where that old trick of multiplying by a weird number and letting the system do truncation came into play. It was a cute (and very expensive) trick, always worked, but was oh, so esoteric. It's a good thing that I documented it in the code (at least once or twice). RPG-IV doesn't like that trick...without some extra effort. Using data structures or, better yet, date data types to do the conversion is pretty self-documenting.

If you're using any of these types of tricks, you're pretty clever, but not necessarily smart. Sooner or later you will need to mainatin that code. Or, worse yet, someone else will. Will you remember what you did and why? Will anyone else understand it? Friends don't let friends (or themselves) code cleverly...code it smartly. And, about those tricks: Forget It!