The following entry was originally posted on Rickard’s blog.
For our new StreamFlow project I wanted to try and get management functions in properly right from the start, which basically means exposing configuration, service management and administrator functions through JMX. I figured that if I did that on my part the customer would simply be able to get a decent JMX console and get their work done efficiently through that.
But then yesterday I did some research into the current state of JMX consoles, and in particular downloaded and tested all the OpenSource consoles in Java. The end result of that is a realization that they all basically suck. There’s no point in naming names, and no point in going into detail, because they all seem to have the same basic problem: the developers haven’t talked to a domain expert.
Don’t get me wrong, these consoles have lots of features, and the features work. It’s just that those features are not helping administrators get their work done, and the features that would help them get their work done are missing. If the developers of these consoles had talked to actual system administrators to figure out what they need to get their work done, I’m quite certain that the consoles would have far less features, but the features they had would actually be useful. Kind of like a Mac-experience I guess.
This seems to be one of the profound and obvious insights of Domain Driven Design: you can’t get it right by guessing what your users want. You have to actually talk to them and ask them what they want, why they want it, and what problems it will solve. Most software today, especially in the packaged product sphere, seems to be done by developers who are sort of guessing what to include based on their own ideas and possibly what the sales guys and marketing folks think would make the product more sellable. But that doesn’t mean that the end result will be useful or even usable, and it’s a big fundamental problem with our industry.
As software developers we need to understand that having strong development skills is not enough. We also have to take the time to understand what it is our customers are doing, how they are doing it, and why. We have to be cross-disciplinary, to a large extent, or else our products will inevitably be doing things nobody really asked for. We will be creating waste, and lots of it.
So to the makers of JMX consoles in particular, here are some suggestions. Look into DDD. Look into BDD, Behaviour Driven Design, also, as this will give you the simple tool of “As an X I want to Y so that Z”, which will profoundly help you sort out the useful features from the useless features. “As an Administrator I want to Know when a server goes down so that Users won’t have to tell me”. Things like that. Then get a domain expert or two. Talk to them. Learn what they do, how they do it, and what they need to get things done. Learn their ubiquitous language. Then implement features that would actually help them. I guarantee you that if you start from scratch and follow this model you’ll be pretty far along after just 10 features, and none of them will be similar to what you already have in the consoles today. But they will be useful! And that is a good start.
ps. while the lack of decent OpenSource JMX consoles is depressing, during my tests I did find one product that seems really good, and have features that are related to things that administrators care about: the ManageEngine Applications Manager. Check it out!