I have a couple of anecdotes to share and then I'll get to my point about software, particularly related to BMC Service Level Management.


In practically any "problem scenario" there is usually a "right way to fix it" and many other ways to fix it that are faster, cheaper, and "less than ideal".  Finding the "right way" may take time to understand the problem.  I'm sure you have experienced this if you have ever dealt with a car mechanic.


I once tried to explain to a colleage in another software organization that "slowness" can be a good thing in software development.  I think he raised his eyebrow and changed the subject.


I think the worst line of code I ever saw was an "if" statement in a C program (in a software product that is now thankfully dead) that spanned 10 lines and included multiple levels of nesting and Boolean conditions.  It took me about a day to understand that program before I decided to re-write the whole thing because the structure of the resulting code had become so convoluted.  This didn't happen the first day the code was written - it was the result of years of software maintenance and shortcuts or "low-risk" choices that left the code in that state.  Nobody wants to re-write production code because of the time and risk involved.


I think the point is that every development task involves choices that may have long-term consequences.  Bad choices can  leave you wrestling with alligators.  As my parents used to say, "haste makes waste".  Especially true in software maintenance.


Now for a more concrete case.  I was working on SLM 7.5 a few days ago for a software training session, and noticed that my SLM Trends dashboard displayed duplicate entries for certain Agreements.  These agreements were related to multiple contracts.  Instead of getting one line for each Agreement/Contract, I got two.


I tracked this down to a form that indeed showed four entries, two for each Agreement/Contract.  There should have been only two.  My first instinct was to delete the two entries that appeared to be in error.  But I didn't understand why these entries appeared in the first place so I spent a couple of extra hours researching.


It turns out that this form was a join form, in which the join criterion used a non-unique qualifier to find related entries.  So each of the two Association entries was related to the same two Compliance entries, resulting in what appeared to be four entries.  The "right fix" was actually to change the join criteria to use a unique qualifier. Voila - now there's one line per Agreement/Contract!


So I learned a lot of cool stuff about SQL joins and Remedy join forms.  But this also reminded me that finding the right fix is worth the wait.  If I had deleted those two entries in the join form I probably would have created multiple other data problems that would surface later and be very difficult to understand or fix.  (I'll probably post something about this in the SLM forum, but suffice to say there is a defect filed for this).