If you’ve worked in this industry long enough, you’ve probably gone down a road I like to call Tool Blame. I know I sure have. Tool Blame is that final, last-ditch act of desperation where one simply refuses to admin that he’s wrong and concedes to “working around” the “deficiencies” of the “pathetic” tool he chose to use in the first place. My absolute favorite example of Tool Blame is a tirade from a developer I once worked with: “what do you mean .NET can’t parse an empty string into a DateTime? My whole middle-tier is designed around strings! It’s going to take me at *least* a week to work around Microsoft’s bumbling incompetence!!!”

Though I might tell that story someday, today I’d like to expand on an article back from the WTF University series. For those unfamiliar, last year we all took a trip back to our favorite alma mater for a programming course, a security course, a web development course, and even a work-study on one of the college’s critical information systems. Enric Naval, the student who worked on that system, wrote back and gave an update on his experience and his trip down Tool Blame Lane.

The work-study opportunity that Enric was offered was a highly competitive position. Easy work, plump scholarship, real-world experience, extra money – just about every computer science major wanted it. Enric knew that he’d really have to sell himself to the IT Department to even be considered for an interview.

Instead of simply showing off his grades and past class-assignments, Enric decided to try something different. Already familiar with the Student Registration System, he submitted a proposal that detailed exactly what improvements he would add to the system. The big one was an “interactive, user-maintainable, permissions-controlled content creator.” More or less, it was an awkwardly-described content management system. That apparently sold them, and he got the work-study job.

In order to build this content management module, Enric told the boss that he’d need features from the latest and greatest version (1.5, at the time) of Java. Specifically, he needed Enums. He wanted to use them to define the various content Sections and Subsections. The boss agreed and, being a mostly developmestuction environment, installed JDK1.5 on the production server.

Enums seemed like the perfect choice. Not only were they a brand-spanking-new feature of Java, but they were so much cooler than their C++ counterparts. They could be used to store all of the dynamic content and navigation. He started coding right away:

public enum Section {
  INFORMATION ( "Information", Permission.Visit, ...),
  CALENDAR    ( "Calendar",    Permission.Visit, ...),
  COURSES     ( "Courses",     Permission.EditCourse, ...),
  ... etc ...
)

He did the SubSections in a similar manner:

public enum INFORMATION_SubSection {
  LOCATIONS   ( "Locations", Permission.Visit, ...),
  POLICIES    ( "Policies",  Permission.Visit, ...),
  ... etc ...
)

After a few weeks, Enric had built a fully-dynamic, code-driven system that programmatically displayed content based on his Enums. It looked and functioned exactly like the HTML-based system before it, and also shared the same problem: it couldn’t be maintained by the end user. In fact, it required a Java programmer to change content.

To Enric’s dismay, Enums could only be updated by editing the code and recompiling. Why would Sun be so stupid as to not create dynamic Enums? Enric would simply have to work around this limitation with a database.

The Database structure looked very similar to the Enum structure: Sections, Subsections, pages, titles, etc. Enric moved all of the navigation and content into the database and modified his code to retrieve items based on the Enum key. It seemed to work: users could edit content pages with ease. They just needed a “little help” to add or delete them.

Of course, this “little help” referred to editing the Java source code and adding or deleting an Enum. Unfortunately, it was a bit too inconvenient for those end users. Try as he might, Enric could not convince them that this was a technical limitation of Java. He’d have to find another work around.

Enric tried everything from complex hashmap tables all the way to runtime code-modification. And every step of the way, he kept finding more and more deficiencies with Java. It simply didn’t do what he needed it to: dynamically update static enumerations.

In the end, Enric gave up and moved everything in the database: navigation, permissions, content, etc. It was nowhere near as elegant as he wanted, but it did the trick. Although he eventually forgave Java (read: realized how ridiculous he was), for a while, whenever someone would even mention Enums, he’d share his two cents: “Java Enums are a useless feature; real programmers never need them and use databases instead. I’ve never used Enums and, trust me, neither should you.”

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!