Liar, liar, pants on fire!

Before I start this diatribe, give me a minute to get up on my soapbox. Ah, that’s better. The air up here is not as polluted and I can see more clearly now. Too bad some of you can’t get up on the soapbox with me to enjoy the view, but I digress. OK, before going any further, I warn you that I am about to offend a lot of “kool-aid drinkers”.  If you are one of them, tough toenails, because I’ll give you the bottom line right now – you, my friend, are an idiot.  If you don’t have thick skin, read no further. Those of you brave enough to face the truth, continue on.

We here at Visionpace make every attempt to practice the Agile methodology of software development. We are proud of the fact that this practice serves both us, as software developers, and our clients extremely well. Many of our clients were reluctant at first, but once they understood the benefits, most of them gave it a chance and haven’t looked back.

Agile practices are a good thing, but I do have one beef that I am VERY passionate about and I am about to discuss (some of you might even say, proselytize) it. In many agile discussions, as well as discussions about other software disciplines, one often hears the phrase, “All comments are lies.” Those of you who believe this are (as I have alluded to above) idiots! However, those of you who do NOT believe it, COULD still be an idiot, and so, be sure to get a second opinion.

Hey, I get it. Don’t trust comments. They are not always accurate. Duh! I feel that there are a certain percentage of you out there who actually embrace this belief because it validates the fact that you were doing the right thing all those years by NOT putting comments in your code. No, it just validates that you are lazy. Lazy is not, necessarily, a bad trait in a software developer, but NOT commenting your code WITHIN the code makes you, dare I say it, an idiot. That is the last time I will use that term, because, hopefully by now, you are riled up enough to really listen to me.

Other than the fact that someone either knowingly wrote an inaccurate comment or wrote a comment, modified the code pertaining to it, and then did not update the comment, can any one out there give me a reason NOT to trust a comment you discover in code? We will exclude that person from the discussion because he is a “psycho programmer”; you know the one that NEVER follows any kind of standard and use one character mvars. Besides, most “psycho programmers” don’t comment anyway.

Here are the reasons why you SHOULD comment your code.

1. Let’s get the “trust” issue out of the way right now.  If YOU put the comment in yourself, you BETTER believe that the comment is accurate. You did it (primarily) for yourself.  The fact that an accurate comment will benefit a maintenance programmer who comes down the pike a year later is an extra benefit; a benefit which I appreciate when I am called in to do the maintenance. I will be more than happy to ASSume that the newly discovered comment is accurate because THAT developer put it in there and, like you, why would they want to lie to them self? Yes, there is that chance that the comment is now inaccurate.  Studies have shown, statistically, that approximately 93% of comments ARE accurate.  Right here, you should be asking yourself where I got those numbers, and right here, I will tell you that I made them up.  Who would waste their time researching that fact? Nevertheless, think about it, most comments ARE accurate because the person who writes them WANTS them to be accurate.

2. OK, I can tell you are getting a little bit peeved right now. Dave, I thought our code is supposed to be “self-documenting”? If I write bug free code, why do I have to comment? Oh, grasshopper, you will learn someday.  Until then, trust me, write those comments! In all honesty, I, too, am a believer that under most circumstances, the code SHOULD be self documenting. However, consider the following code:
   
   

REPLACE Name WITH UPPER(SUBST (LastName, 1, 2) + LOWER(SUBST (LastName, 3)

That code is self documenting, if someone wanted to take the time to figure out what it does, they could easily do so. The real question the person should be asking their self is... WHY is that code there? It looks kind of goofy anyway.  When I first saw it, I thought that perhaps the coder didn’t know about the PROPER function, but then, they were really capitalizing the first TWO letters of the name. Maybe the parameter of the first substring should have been 1, 1.  Maybe I should refactor using the PROPER function.  I am soooooooo confused!  Close to an hour of my time was spent determining WHY this code was here.  Imagine how much easier it would have been had the following comment been in place.

DLA/Visionpace 04-01-2004 Mr. Jones, the COO, bought 113 file cabinets at an auction. He has decided that the new company wide filing system will be based on the first TWO letters of the customer name. EACH drawer will have a two letter designation and the file will be placed in the drawer base on the first two letters of the customer name. To make it easier to file, he wants the first two letters emphasized for easier reading.

Immediately, we can see that the code is correct and that there is a reason WHY it was written.  Additionally, as often happens to me, in some scrum, when asked why this was done or who requested it, the answer is there.  Not only for me, but for you when you come in to do the maintenance. Two minutes to initially write the comment or 60 minutes to figure out the details three years later. You do the math.

3. Additionally, what one developer feels is self-documenting, another might not. Why not eliminate any potential confusion and explain the reason for the code’s existence? Again, it will save the next person who comes along much valuable time for there is a real good chance that they will know nothing about the project and the code. Believe me, you will benefit also.  One of my favorite phrases is... “When you are coding, you and God know what you are doing.  Six months later, only God knows.” I can not begin to tell you the number of times when I have gone into some legacy code and the comment I wrote three years earlier IMMEDIATELY brings back to life the exact reason for the code.  Many is the time that it has saved my fanny. Those are the times that I almost dislocate my shoulder patting myself on the back for a job well-done.
   
   

If you have made it this far, you are just not getting enough billable hours in.  However, thank you for reading along and agreeing or disagreeing.  Either way, I would appreciate hearing your thoughts on this very polarizing topic. I promise to bring an open mind if you do the same, but I will say right up front, that it will take a Herculean effort to change my mind.  Care to give it a try?

Denial Isn't Just a River in Egypt

A little over a month ago, the Microsoft Corporation officially announced that they will not be releasing any new versions of its relational database software, Visual FoxPro (VFP). The news came as a surprise to many of the developers in the FoxPro community, but those developers must have been in denial or had their heads buried in the Hentzenwerke “Hacker’s Guide” because the handwriting has been on the wall for months.  Years!  Decades?
 

To paraphrase Garrett Morris’ Chico Escuela persona from “Saturday Night Live”, “FoxPro has been bery, bery good to me”. It has provided me with an above average income and a comfortable life style (once I kicked all of my kids out of the house). More importantly, Visual FoxPro and before it, FoxPro for Windows and FoxPro for DOS, has been VERY, VERY good to thousands of small to medium sized business as well as some Fortune 500 companies. A VFP application is used to run the operation of the Chunnel (the underwater link between England and France). During the first Gulf War, FoxPro was an integral part of the military’s JFast application which managed the deployment of troops and supplies. There are many other high profile applications, but my point is that mission critical applications created by FoxPro developers provided reliable, efficient, and economically sound solutions to real world problems. ECONOMY is one of the reasons that Visual FoxPro is one of the best selling application development software tools IN THE WORLD. It is reasonably priced and is “self-contained”. i.e. For the most part, it has it’s own reporting capabilities, user interface capabilities, and data storage capabilities. Those are the basics of most data-centric applications. Of course, it has many, many more features than just those basic capabilities. I could go on about my devotion to VFP and why I (as well as many other developers, world-wide) love it so much.  Nevertheless, the fact is that Microsoft is going to support Visual FoxPro only through 2015, so there is no sense in denying it any longer. VFP is on its own.

Notice and this is very important, I did NOT say that VFP is DEAD.  I just said it is on its own. Why? Because 2015 is eight years away.  Who knows what will happen by then? I, personally, am still maintaining applications written in the mid 1990s that the clients love and couldn’t do without.  I expect to see applications, being written today, around for another twenty years.  The applications do EXACTLY (another key word) what the client wants them to do and they have no plans of abandoning them.  Isn’t that the bottom line? So, if you are in need of custom applications and plan on being in business for the next 20-25 years, there is no compelling reason why you shouldn’t consider (or at the very least, do not summarily dismiss) having those applications written in Visual FoxPro. An honest, ethical developer should offer you all options, explain the pros and cons of each, and then help you to decide upon the approach that is best for you.

My Bucket's Got A Hole In It

One of the tenets of life drilled into me by my dear old Mum is, “Grow ‘til ya go.”  When I was six years old, I thought it meant that I was still a little person, but if I ate the right food, I would grow up to be big and strong. At 17 and entering college, I still didn’t get it (but I knew what PART I wanted to see grow). Even after college, the immediate thought of constantly learning was not one that I embraced. When will I ever be done learning?  Now, as I approach the September of my years (and, obviously, still able to wax poetic), I finally get it. We will always be learning something. Close that door; the mystery of life has been solved!  Wait. What’s that? Another door just opened and on the nameplate it says, “OK, now what?”

That is the bigger question, you know?  If I have finally come to terms with the fact that I will constantly be in the learning mode, what should I learn next? I have wrestled with that problem for a long time.  In fact, there were times, when I reviewed my day, that I could honestly say I didn’t learn anything. Mom was right. I felt like I had cheated myself. It was then that I decided to take baby steps and I made a compact with myself that any day I ended up going to bed smarter than when I had woken up, was a good day.  At times, I really had to stretch my self-imposed criteria to come up with something new that I mastered. For several weeks, I took the easy way out and decided I was going to learn all about the seven remote controls sitting on my living room coffee table. I never said that what I learned had to be earth shattering, but I will tell you this (with chest proudly puffed up in braggadocio mode) every time I hear some standup comedian joke about VCRs still flashing 00:00... 00:00... 00:00, I LAUGH in his face.  That serves two purposes. First my guffaws let the comedian think he is actually funny, and secondly, it allows me to secretly bask in the knowledge that I am better than those people whose VCRs ARE still flashing 00:00... 00:00... 00:00. Somewhere in my darkest soul, the echo chamber is queued and I am letting a diabolical laugh rise to the surface.  Buh-WA-HA-HA-HA-HA

Last Thursday, I was struggling trying to come up with something that I had learned.  I had, long ago, amended my compact to say that LEARNING that you didn’t know something about something did NOT qualify for having learned something. I will give you a moment to reread that last sentence. Go ahead, read it again if you want.  So, there I was having discovered I didn’t know something and so far, I have not been able to find the answer.  I am hoping that one of you will have a clue. What is this conundrum? Namely, the word, “Bucket” is a reserved word in Visual FoxPro. My question to you, dear reader, is WHY?  I discovered this fact when I was writing a SQL statement that included a calculated field that I named, Bucket. Each time I typed Bucket, my editor capitalized it and turned it blue (the sure-fire sign it was a reserved word).  Sure enough, after checking the list of reserved words, it was confirmed.  I will also tell you that finding the word, Bucket, in the list of reserved words was the ONLY, repeat, ONLY place in the entire VFP Help file where I found the word.

If any of you would want to offer a possible answer, as Dumbo, once said, “I am all ears.”  I will warn you that one of my VFP buddies, Lister Potter, came up with the definitive answer as far as I am concerned, so you better really have a good response to top his.  Wise old Lister suggested that since Microsoft had announce it would no longer be supporting VFP, that they have secretly added a BUCKET for VFP to “kick” when 2015 rolls around.  Makes sense to me.  In the meantime, I am going to set my daily learning goal a bit higher and try to find out why people find Howie Mandel funny.