« June 2009 | Main | April 2010 »

September 30, 2009

K.O.K.O.P.E.L.L.I. is koko-licious!

The world’s greatest software application has been released. OK, maybe not the world’s greatest, but certainly, this country’s finest software. That COULD be a bit of a stretch, too. Why don’t I tone it down a bit and just say that a useful piece of software is now available? It will be particularly useful if you are planning on attending the Southwest Fox 2009 conference in Mesa, AZ on October 15-18, 2009. K.O.K.O.P.E.L.L.I. is its name and you can read more about it and view a video tutorial at http://swfox.net/kokopelli.aspx. It is also available for download at that URL. Allow me to tell you a little bit more about it.

 

Several years ago, a co-worker, Doug Carpenter, and I were annoyed by the time we “wasted” in trying to come up with the optimum conference schedule when attending a developer conference with multiple sessions. It seemed like we would spend several hours with pencil and paper trying to pick and choose the correct combination of times and sessions to get the best bang for our conference buck. It was then that we embarked on the quest to come up with some semi-intelligent, intuitive software that would do the scheduling for us. It was that software, “The G.O.D.D.E.S.S.”, which debuted at the DevEssentials in Kansas City, MO. in 2004. K.O.K.O.P.E.L.L.I. is the next generation of this type of software.

 

Written in Visual FoxPro 9, Kokopelli (K.O.K.O.P.E.L.L.I. is too difficult to type) takes the attendee’s preferences and converts them into a SUGGESTED conference schedule that all but guarantees, by the time the conference is over, that the attendee will have seen every session they wanted to see. You will need either VFP8 or VFP9 installed or have the run-time files available to run the executable.

 

Once you download the zipped file, unzip the file into the directory of your choice and just run the executable. Take the time to READ both the help (4th page of the page frame) and/or use the graphical help by clicking on the “Help!” button. This is all the help you should need. I do have a couple of warnings however. If you keep them in mind, you will have the best chance of getting the optimal schedule.

 

First, although it may appear to be so, it should NOT be your goal to “pick” the session in each time slot that you want to attend. The software will eventually do that for you. YOUR job is to rank the four (or five) sessions in each time slot as if they were the only four sessions you could attend the entire conference. i.e. Of the four sessions in the time slot, which one would you MOST like to attend? Which one would be your 2nd choice? Third choice? It is so important that you understand this concept; I am suggesting that you read this paragraph over again. Do the same thing for EACH time slot (ignoring what you chose before in other time slots). To reiterate... Treat EACH TIME SLOT as an entity unto itself. By following this plan, Kokopelli will determine which sessions are most important to you and present a schedule that should meet your needs and ensure that you have had a chance to attend the sessions that interest you the most.

 

Second, the generated schedule is ONLY A SUGGESTION. No one is twisting your arm and forcing you to attend a particular session. I think you will be amazed at how well it does in creating a schedule for you. You can always tweak the rankings to fine tune the schedule. If you have any questions, concerns, comments, feel free to comment them here and I will answer them and guide you down the right path.

 

Lastly, we tried to come up with a form that isn’t your standard Visual FoxPro/Windows form in appearance. We hope you like it and appreciate the Southwestern theme of the form.

 

"Thank you"s are in order. I must mention those VERY patient folks who tested the application, offered constructive criticism, and generally harassed me to get it done. Without their help, it would have taken much, much longer. So, in no particular order, I would like to acknowledge the following humanoids for their help:

Doug Carpenter
Kelly Conway
Tamar Granor
Doug Hennig
Larry Koska
ShellEy Nass
George Clooney (just checking to see if you are paying attention)
Cathy Pountney
Rich Schummer

 

For those of you who are really weird, YES, it WAS in a particular order - ALPHABETICAL (by last name).
Thanks again to everyone.

 

Posted by Dave Aring on September 30, 2009 | Permalink | Comments (5) | TrackBack

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 again, 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, in MY opinion, you SHOULD comment your code.

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.

 

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 parameters 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, recently 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 five years later. You do the math.

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?

Posted by Dave Aring on September 30, 2009 | Permalink | Comments (12) | TrackBack