Superplatforms are Simple, Rebel Platforms are Hard

I listened to Richard Monson-Haefel’s recent podcast for the Burton Group on rebel platforms. The most shocking statement follows:

If they [your developers] value simplicity you probably want to go with a super platform.

According to the Burton Group:

  • Super Platforms are: IBM, BEA, SAP, and Microsoft
  • Rebel Platforms are things like: Hibernate, Spring, Struts, and Tomcat and LAMP.

Of course I really thought much of the J2EE community had come to ‘rebel’ platforms because the wonderful vendor driven EJB model was too heavyweight and complex. Entity beans are pretty much dead on arrival these days. And we’ve been dealing with Websphere for 6 months now only to constantly reminded how complex it is. Everything from handling class loaders, to logging problems with RAD make it significantly more complex and troublesome then anything from the open source J2EE community. Case in point we ran complex applications on JBoss up until now with relatively few issues.

Amazingly enough Monson-Haefel points out how much better the support you get with a super platform including things like documentation. Lets compare IBM’s documentation to say Hibernate or Spring.

IBM believes in Redbooks, which are a strange mixture of documentation and marketing. They have a few books they haven’t written themselves on the market, but they’re mostly not exactly hot sellers. Then if you go digging in their developerworks site you can sometimes find something relevant. On the other hand Hibernate and Spring both have multiple fairly popular independent books put out by multiple technical presses. They also have a huge amount of documentation to be found online since these are popular frameworks, that many developers actually use. I’d pick a popular open source for better documentation every time.

Monson-Haefel also seems to presuppose that you need ‘better’ developers to handle the rebel platforms and that the super platforms are more drag and drop, model driven, trained monkey, kind of development. Unfortunately all our recent anecdotal evidence has pointed to the opposite conclusion, that even our brightest developers find themselves spending tons of time dealing with configuration instead of coding, and that the drag and drop stuff generally sets you up for some pretty crappy code. And how many times are we going to be pointed to the just out of reach holy grail of model driven development where you hardly need a programmer.

I’ll take the simplicity of a rebel platform any day over the complexity and constraints of an enterprise super platform. I can see why this podcast was the lowest rated of the week for IT Conversations.

Less Syntax Errors

It occurred to me today while reading an article about Tiny Basic in the latest Dr. Dobbs that much of my childhood contempt for actual programming may have come from my propensity for syntax errors and the primitive nature of the editors I used back in my childhood.

I’m dyslexic, thus spelling has always been pretty difficult by nature. Modern IDEs and editors nicely include features like auto-complete or at least syntax coloring and error suggestions. This greatly reduces the impact for not being a stellar speller. Enough so that in the last ten years or so I’ve always enjoyed pure coding versus my earlier experiences.

I remember taking forever to work my way through simple basic programs on a TI 99/4A or the Commodore 64. I also remember working in vi and absolutely detesting it, and not for just its absolutely frustrating modal interface. I edited my first HTML in a raw text editor and quickly determined that not using a tool was for the birds. A simple download of BBEdit Lite and I was instantly more productive and making a lot less syntax errors or at least being able to instantly spot them. And that just had syntax coloring at the time.

Now I love working in IntelliJ IDEA with auto-complete, intention actions, and refactoring support. I probably start to make just as many syntax errors, but they’re identified so quickly I hardly notice. It certainly makes me a lot more productive. And I still hate vi. My old joke from Georgia Tech was that I knew the most important command in vi: Shift-Z-Z.

Acceptance Tests With Fitnesse

I’m in the process of taking all of my lab examples from a TDD/JUnit class which include Bob Martin’s bowling game example, a simple bug tracker, and a golf game. I picked up the book, Fit for Developing Software, to help me along since I never found the built in documentation quite sufficient enough.

The books helped, though the book is split into different sections for business analysts and developers so you do a lot of flipping back and forth. I have run into one small issue I haven’t been able to resolve yet in dealing with exceptions.

Exceptions are fairly easy to test for in your standard JUnit framework, and I figure there’s probably an easy way to to test for them in Fitnesse. Turns out you just put the keyword

1
error

in the table cell if the expected result is an error, such as searching for a bug that doesn’t exist in the bug tracker. The problem I’m having is that I can’t find any easy way to examine the message being returned. If I don’t check for error it prints out the exception message and the related stack trace which is very nice for debugging, but not to useful for QA and besides I’m expecting it to fail. If I check for error then it’s all fine and dandy and the test passes, but the message gets swallowed. Hopefully I’ll run across any easy resolution to this as well.

I actually think that the fact that it throws an error should be good enough for acceptance testing by a business user, but I’m certain that our QA and business analysts will want to check the error message text exactly since I’ve seen some of our requirements business rules that for some reason specify in text where a field and error message should appear on the page. This is despite the fact that there are already detailed HTML prototypes. If I get some time maybe I’ll dig into the Fitnesse mailing list archives.

Reverse One on Ones

I’ve been batting around the idea of starting up weekly one on one meetings with all my folks. As a front line manager my primary goal is to grow my people. Then of course if you slot out 30 minutes a week for 9 employees you get 4.5 hours per week. That seems like a lot at its face, but it’s really about 10% of my time. At the end of the day there some obvious benefits to meeting with your people semi-formally every week, especially the ones who don’t swing by your cube that often.

As an experiment I’ve been testing out a reverse one on one with my boss. I simply setup a weekly half hour meeting with him on every Friday for the last few weeks. It’s actually been going better than expected. I get some great feedback from all of his experience, and I can save up some more strategic questions for our weekly session. We haven’t held to the 30 minute schedule so far, because the discussion keeps spilling over.

Now I just have to schedule out the one on ones for my team starting next year.

Scrum Sprint in Waterfall World

We’re very much in the early adoption of Scrum at this point in my organization. So while my group of developers commonly run Sprints, hold daily standups, and use product backlogs, the rest of the organization rarely follows along.

So we ran into one of these clashes today on one project. The second Sprint will finish up successfully tomorrow, but then we go into a QA/UA cycle for a few weeks where they’re really won’t be any development.

Our solution for now is to do a sort of 2-3 week release Sprint where we work off a lot of design debt on the project. Due to the number of new technologies used on the project the amount of unit test coverage is pretty low, about 5-10% actually, plenty of debt.