The System I Don’t Love, Exactly

There’s a particular piece of enterprise software that we use at the office of which I am none too fond.  As a member of a small technical team, there are a number of things I find myself doing that don’t fit squarely into the “developer” wheelhouse (“hey, you’re IT aren’t you?  come fix this printer”) , and I typically consider that more pro than con.  There’s a perspective and breadth of experience with various concepts that one just can’t acquire doing heads-down coding 100% of the time, and I like to think that the variety keeps me from getting so comfortable with a small number of things that I fall into a rut without seeing it coming.  On occasion, however, it seems that someone has taken the time and the energy to prefabricate a rut for me to fall into with very little effort on my part.  Sometimes that rut can become a ditch.  Or a bottomless pit of despair.

Before I address the particulars of the application that makes me sad whenever I touch it, I should point out that it is not the first of its kind and quite possibly isn’t even the worst I’ve seen.  In every position I’ve held from the time I got out of undergrad and set up my desk at my first “real job” in the field, there has been by definition one program I have enjoyed working with less than anything else.  Sometimes I’ve been part of the development team for a project with a less than stellar future so I’ve stared into the abyss of subpar spaghetti code and felt the tendrils of anti-logic boring their way into my soul.  Others, it’s been a company standard application that everyone has had the pleasure of using on a daily basis despite the fact that for many people it was the square peg that was pounded relentlessly into the very round hole of the requirements for which it was originally purchased.  Having both experiences more than once in my career leaves me on the fence when trying to decide which is worse; with an internal project, the ability to see and touch the inner workings of the thing means that on a long enough timeline there’s a reasonable chance of squashing most of the major bugs or begging the people in charge to authorize a rewrite.  On the other hand, bugs in vendor-provided software are officially Somebody Else’s Problem and the reflexive facepalms at finding painfully counter-intuitive behavior stops at the point discovery because only the vendor knows how offensive the source really is.

In this particular instance, the application is produced from a vendor who deals exclusively in ,one specific problem domain and is required to pass an extensive series of regulatory hurdles in order to sell the product.  The thorough vetting process does not, for reasons I cannot begin to fathom, include a check for foreign key relationships between tables or other relational database principles that I used to take for granted were a given in any well-ordered database design.  The total number of tables reaches into the five digit range, and if a primary key in one table makes an appearance in three others it the chances are good that it will go by at least two different names.  There are multiple blob fields storing documents of various kinds and those same files are replicated in at least one location in the filesystem.  New versions and hotfixes contain DDL scripts on a semi-regular basis and in the releases I’ve observed those commands seem to change field names or remove them as often as they add objects, so any reports or data transfers that were built against the existing schema may or may not continue to work with newer versions.  This is of course not a very serious problem as long as no one needs to pull information of any kind out of the database on a consistent basis for any reason.

The user interface is completely intuitive and navigation is straightforward enough in parts, but other areas are significantly less so.  Month, day, and year textboxes appear on screens next door to forms that use date pickers, date pickers occasionally get caught in infinite loops that require a date value to break out of but don’t recognize anything that’s been entered and users are forced to kill the process then restart, and the same data can be presented in a completely different fashion between one part of the environment and another.  It was saddening but not completely surprising when I learned that some of the database calls from the application are constructed in the code and use ordinal parameters instead of explicitly naming them but others use stored procedures with what I consider sensible naming conventions.  An end user recently remarked to me that it seemed like someone with a split personality had designed the whole thing and that one of those personalities did not like the people who use their software very much at all.

There are a few reasons to share this beyond the desire to vent and give myself the ultimate one-up at any watercooler conversation about programs that might be less than ideal and who has it worse.  It also provides the opportunity for everyone else to indulge in a serious amount of schadenfreude and reflect that the system that they built or have to use or maintain may not really be all that bad.  This also gives me a baseline to refer back to whenever I discuss one of the many tools and processes that  I find myself building to address pain points in this or any system I don’t love, exactly.  Maybe I’ll call it SIDLE for short.

1 Comment on “The System I Don’t Love, Exactly