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.
January 18, 2010 at 7:40 PM
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.
January 22, 2010 at 2:50 PM
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).
January 31, 2010 at 2:52 PM
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...
February 7, 2010 at 11:05 AM
Swimming Mindclouds said…
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.
February 10, 2010 at 10:50 AM
Post a Comment

Popular posts from this blog

Please use ANSI-92 SQL Join Syntax

-
Image
Way back in 1992, a standard was published for SQL. In it, the syntax for specifying joins in SQL Database was finally standardized. This was a good thing because (for folks who've been doing this a while), trying to decode the vagaries of how various Databases handled outer joins could drive you bonkers yielding different results depending on the parse order of things in the from and where clauses. Unfortunately, some DBMS vendors took a while to adopt this standard (Oracle didn't support it until 2001), but at this point if you're using a major RDBMS and NOT using it, you're probably mired in a tradition or habit that bears changing. As an example of what I'm describing, here are some examples of what I mean. Old School (no standard syntax + implementation and evaluation of predicates varied by vendor [and query]): select * from customer, order where customer.customer = order.customerid ANSI way (agreed to standard, predicate evaluation has some rules ...
Read more

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

-
I thought I'd give some explanation of the difference between scalability, performance, Efficiency, and concurrency. To make things more accessible (and because I'm watching a cooking show on TV) I'm going to use a baking metaphor to help explain the differences. In our case, the system in question is baking cookies for consumers. Scalability, is how well something responds to adding more resources. If we can double our capacity by doubling the number of resources, we've got linear scalability. In our baking example, if we add more ingredients, we can scale to a larger number of cookies. To contrast with our other metrics, this doesn't actually increase the performance of creating a single cookie (they still take 10 minutes to bake), and the efficiency is the same (we just have more capacity). We also cannot bake more cookies in a fixed time period, but over a larger time period we can produce more cookies. Performance is how fast something can get done, u...
Read more

the myth of asynchronous JDBC

-
Image
I keep seeing people (especially in the scala/typesafe world) posting about async jdbc libraries. STOP IT! Under the current APIs, async JDBC belongs in a realm with Unicorns, Tiger Squirrels, and 8' spiders. While you might be able to move the blocking operations and queue requests and keep your "main" worker threads from blocking, jdbc is synchronous. At some point, somewhere, there's going to be a thread blocking waiting for a response. It's frustrating to see so many folks hyping this and muddying the waters. Unless you write your own client for a dbms and have a dbms that can multiplex calls over a single connection (or using some other strategy to enable this capability) db access is going to block. It's not impossible to make the calls completely async, but nobody's built it yet. Yes, I know ajdbc is taking a stab at this capability, but even IT uses a thread pool for the blocking calls (be default). Someday we'll have async databa...
Read more