Wasting Money On Expensive Enterprise Tools

I’ve seen the symptoms occur in every IT shop I’ve worked in, though rarely in consulting firms. They symptoms are:

  • The CIO/CTO sees something about a new product that’s buzzword compliant be that Y2K certified, agile, or SOA.
  • The tool costs at least six figures.
  • The tool is “enterprise class” whatever that means.
  • The tool is a must have when pitching the business on a new project. “Well, we need Product X to allow us to build a true enterprise system, otherwise it won’t scale.”
  • No one asks anyone who’s going to actually use the tool what they think about it.
  • It sits somewhere in a Gartner magic quadrant.
  • Once some momentum is started there’s no way the purchase isn’t going to happen.
  • It’s standards compliant–the vendor’s proprietary standard.

The end result is the product gets purchased and the line IT employees get screwed. Real alternatives to spending money on an expensive tool that may become just shelfware are ignored. I can think of tons better ways to spend six figures:

  • New developer boxes for developers who haven’t had a new machine in years. Total cost maybe $6000.00 per developer for a nice high end box with dual 30″ monitors. Productivity goes up and for $100k you can outfit at least fifteen developers. On top of that you get a huge morale boost because the developers actually believe the line about really appreciating the employees.
  • Bring in a high end mentor/trainer/coach at say $200/hr to teach things like TDD, real OO design, refactoring, XP practices. Total hours covered 500 or enough to spend an individual week with twelve developers.
  • At about $3500 per conference send 28 developers to conferences. Conferences like like TSS Symposium, JavaOne, OSCON, SD West, RubyConf, NFJS, ETech, etc expand their abilities and vision.
  • Setup a break room for developers and stock it with Foosball tables, video game systems, and free snacks, water, coffee, and soda.
  • Buy Areon chairs for all the developers and hand out the rest as bonuses for high performing teams.

Chris Richardson at SACJUG

On Jan 9th, 2007 Chris Richardson, author of POJOs in Action, gave a talk on POJOs using Spring and Hibernate. The talk was a pretty good overview and I learned a few things along the way. Chris’s current preferred TDD development stack is:

  • HSQLDB
  • Hibernate
  • Spring
  • Jetty
  • Selenium

The idea is to avoid anything that will slow down testing hence an in-memory HSQLDB, Jetty, and Selenium to deal with the view layer testing. Chris also expressed that he was really happy with using Selenium, which just gives me another reason to spend some time and actually try out Selenium. He also starts up Jetty in debugging mode to avoid having to do many restarts.

He was of the opinion that you really shouldn’t use Spring in unit tests. The dependencies are something you should probably mock, and Spring beans get in the way of unit tests. On most of our projects were just using a testing specific Spring contexts for the tests, so it might be worth exploring just taking out the Spring dependencies.

His opinion of options like EJB3 was that he wasn’t too impressed and out of the app servers he really disliked Websphere.

And again on the note of thought leaders who started off in things like Smalltalk, Chris explained he started out doing Common Lisp, and then mistakenly took a job doing C++ just because it was a 50% pay raise.

Hardware Upgrade

17″ Dual Core MacBook Pro came home today. It’s very, very nice. I love the backlight keyboard effect.

Ruby on Rails at a Java Users Group

For some reason our local java users group, SACJUG, wandered onto a discussion of Rails. As is not unusual in the .NET/Java camps Ruby and Rails are none to popular for some reason. The three reasons that got discussed were:

  • Sure Ruby on Rails works for small apps, but when you’re talking about large applications with 20+ domain objects it just doesn’t work/scale.
  • RubyC is just way to slow, and who wants to scale with hardware.
  • The Active Record patter isn’t really an ORM layer, and it just doesn’t jive well with domain driven design.

Ignorance of course is bliss as almost no one had tried out Rails and only a few had seen some demos. For me I never see the point of getting really defensive about new options outside the core language I happen to get paid for currently. I think I might need to sign up for a short Rails demo so at least they can see how nice the productivity gains are. Maybe find a way to show a quick load test as well.

Websphere Process Server Development Box Requirements

As a Websphere shop we acquired licenses to IBM’s nascent ESB product, Websphere Process Server about a year ago. Since that time only one developer at the company, our architect, has been able to successfully develop anything with it.

The partial secret to getting it up and running successfully was revealed to me recently. Another developer kept asking our architect if he was getting a number of random crashes, constant slowdowns, and was unable to run even an email client and Process Server/WID on his machine. Turns out our architect never runs it on his main machine. He has a dedicated box with 4GB of RAM that only runs Process Server. Mystery resolved. Maybe when we get to refresh our dev boxes we might actually be capable of running Process Server successfully.