We're going crazy with all this service stuff

I heard this statement today and it stopped me in my tracks... It came from a developer who was trying to explain to me why it was a good thing to embed our job postings as static files in our main corporate website.

"After all, it only takes 15 minutes to get the new files and deploy the new version of the application" he continued. "After all, how often will they change?"

I had to resist the urge to say "sooner than you might think"...

At that point I should have realized that perhaps this guy was unreachable. I say that because when I attempted to explain my position he just waved me off and immediately stopped listening and started doodling on his notepad.

Upon reflection, a number of problems were evident:

  1. I have done a really bad job explaining the value of using reusable components or what a "service" is

  2. I have done bad job of explaining why decoupling the content of an application from the code is a good thing

  3. I have forgotten that I was 23 once and already knew everything there was to know about everything and that there was actually a time before I had to get woken up at 2:00am because a server stopped working.

  4. He didn't realize that spending 15 minutes a day for a year added up to roughly 1.5 weeks of work (BTW his 15 minutes are more like 1 hour)

  5. I didn't make it evident that every time we redeploy the app, we kick out users and risk screwing up our main corporate web site



I guess my lesson is to realize that some folks don't get the big picture and you need to be careful about delegating important decisions to them. I find it ironic that the very people who complain about the haphazard nature of our legacy applications, are continuing the tradition of not thinking through the solution.

Comments

Unknown said…
This post made me sad. You need to add a hopeless or unreachable tag.
Jason Konen said…
You have to spend time everyday updating your Jobs page? What the heck happened to the turnover there? It wasn't that bad when I left.

There's a time and a place (a very good place) for "services". Rarely updated pages that have unique content aren't one of them. Unless you have a full fledged CMS system in place that can also manage generic pages, I would say spending time developing a service for it is time wasted.

My 2 cents.
Mike Mainguy said…
I really don't know what to say, I think you are probably inexperienced with maintaining complicated and reliable production systems. If you where, you would never have taken such a curious position.

You're suggesting that we should compile the user orignated content for our application inside the code because the content doesn't change "that often". I'm OK with that position for things I KNOW don't change that often and are within my control (css, javascript, java code, Operating system stuff), but for content that doesn't originate from my team (news stories, job postings, other business related stuff) it is generally imprudent to take that approach. You will eventually die the death of a thousand cuts that our team currently faces...

A "full blown CMS" might solve the problem, but I've seen too many "full blown CMS/ERP" solutions become money hungry boondoggle solutions in search of a problem. If I had to guess I'd say you've spent some time roaring into a new company, writing a bunch of software, then bail out when it gets too difficult to maintain all the crap you wrote (blaming management, the "users", and all those other pesky irritations that get in the way sitting down and hacking out half assed solutions).
Jason Konen said…
1) I'm suggesting that you focus on things that are larger than simple content pages like rewriting the Parts Catalog so that it's easy to manage and has a better hook into all the existing LeMans websites. Ability to manage that catalog > ability to manage job postings. There's a time to add the ability into your system to manage such content, but there are bigger fish to fry.

2) I'm all for a well written system, I'm in the process of helping implement one at my current job. When at LeMans I was really looking forward to the new system you and your team were working on because maintaining the old websites was a pain in the ass in the old system(s). I wasn't responsible for writing the systems, my duties were to use the systems given to me by people like you.

3) You're guesses are wrong. I have never blustered in and left because maintaining things got "hard". How DARE you insinuate so. I left LeMans for 1 reason and 1 reason only and that was my direct manager, and it was a very hard decision to make because I both liked the team (including you) and the projects we worked on and I could see that there were some huge opportunities to work on some very cool sites and work in some very cool systems. You assume I jumped ship because things got hard. You ignorant jackass. I actually tried very hard to make things work, even approached HR to try and mediate issues, however being a contractor they didn't care about me as they do full-time employees (employees I might add you made threats against their jobs in your posting, and you being a contractor as well...where do you get off doing that?). So I took the best course of action and left when the opportunity presented itself.

4) It's a very small market here in the Midwest...I sincerely hope you don't find yourself looking for a new job someday and find me on the other side of the interview table.

5) Oh, get maintaining that jobs posting site...
Wow, I see that things haven't changed at all since I left. Platypus, I'm with you on having made the difficult decision to leave such a potentially great job. I still laugh with a cringe of dismay at how much impact one person can have on a team (and I use the word team lightly because typically it means a group of people WORKING TOGETHER). The turnover at that place since the vacuum started has been disgustingly high and I really feel bad for the people who are still there.

Popular posts from this blog

Please use ANSI-92 SQL Join Syntax

the myth of asynchronous JDBC

The difference between Scalability, Performance, Efficiency, and Concurrency explained