UFOs and the aliens that drive them

At one point in every coder's career, you will get that one requirement that you just don't understand why they would have such an inane requirement. Thanks to a good presentation, I can now close the book on the worst one of my career.

 

Once upon a time I worked at a place that wanted something better. They wanted reusable code. This was the early 2000's and we were coding in perl. This company was built on custom cgi servers written in c, and we used perl for all the admin/backend stuff. It worked for us. It was perfectly fine that they wanted something better. The catch was, they had no idea what "better" looked like. But I'm getting ahead of myself.

So they hire a java guy with a pretty certificate he propped on the windowsill behind some glass. This did not bother me. They told me, him, and our user interface artist to rebuild an existing administration website using a reusable object model. This bothered me – I had written the current site (in perl), and it worked.

Being a professional, I got down to business. Learned enough Java and the Tomcat environment to put an active website together. Listened to the new guy about designing the site in five "layers."

  • Presentation: the browser
  • UI: converts data to html for display
  • Business Logic: application specific decision logic
  • Data Access: intermediary to Database
  • Database: actual data store

And that's what we did. It worked, but only barely. It took far longer than just writing the app with the previous standard perl did. And the code was terrible. Most of it was very delicate, and in no way reusable. When the bosses wanted a new field, we had to literally edit ten different places to do it.

So we presented this project to the bosses. And what did they say? "We don't like it. Clean it up and do it all over again. You have a week."

At the beginning of that week, I thought it should not take long to clean it up. But as each day passed, the nights got later, and the goal got further and further away. The due day came, and we had absolutely nothing to show for it. At nine years in, already anything but a spring chicken, I had my first and only panic attack. I had never failed so utterly before or since.

 

Fast forward another decade. I'm regularly working with people who were children when I started coding. Makes me feel old. Along comes the Kansas City Developer Conference (http://kcdc.info). For two days, I go to every code design presentation that I could, barring one presentation about making good presentations. But I digress.

There it was: "Pragmatic Architecture in .Net," hosted by Cory House (http://www.bitnative.com). One presentation, just one hour, I am introduced to some things that answered every question about why that project failed so many years before.

In game development, typically the most abstract you get is MVC if you are lucky, spaghetti code if you are not so lucky. I've been hearing things like Service Oriented Architectures (SOA) for a few years along with a host of other acronyms. But as far as I could tell, they had no real bearing on game development. Finding simple explanations was fairly difficult, just from the plethora of acronyms available these days.

At the time it seemed unreal to have every layer need a separate declaration of the exact same block of data. Or why I should need a completely separate object just to run a SQL query that literally populated a flat datablock. Or how many places needed to be touched every time we wanted to add a single new data field.

Learning from past mistakes is something I care deeply about. For the first time, I could finally understand the fundamental principles they were asking me to implement on that job so many years ago. More importantly, I can now recognize the proper use of those principles. Were I to go back in time, I could have argued with the bosses much more convincingly: they were asking for a SOA design, yet their business needs were truly served better by the simpler Active Record approach.

 

Disclaimer: this post was not solicited in any way. For years I've been the fix-it guy for many projects and it's about time I started expounding so someone else might avoid making the mistakes I've seen. Therefore these writings are entirely self-serving because I don't want to be the one to fix it anymore!