Skip to content

"…you kind of suck at your job…"

Note that I don’t put any qualification on the heading!

Well:

If you’re waiting around for users to tell you about problems with your website or application, you’re only seeing a tiny fraction of all the problems that are actually occurring. The proverbial tip of the iceberg. Also, if this is the case, I’m sorry to be the one to have to tell you this, but you kind of suck at your job — which is to know more about your application’s health than your users do.

This reflects a common battle I have had at several sites. My argument (in compressed format) goes something like this:

Why aren’t we telling the users about the state of our systems?
Why do we wait until they report problems to us?
Monitoring software is soooo easy to get or to build; plop a few biiig plasma screens around in well-frequented places; put websites up; put widgets on the intranet home page.
We could be advertising our server statuses, we could be identifying scheduled downtimes.
If we do this, the users aren’t surprised; they won’t start filing bugs when they can see a scheduled outage.
“What gets measured, gets optimised”: if we do this, we can start tracking system reliability, and planning. We’ll have some figures and history to use to help us kill off unreliable hardware, to maintain critical software, fix high-profile problems.
“What gets measured, gets optimised”: if we do this we will find that it’s easier to ask for resources to fix a problem when the problem is clear, rather than beeing a ‘feeling.’
“What gets measured, gets optimised”: if we do this will we look bad? Perhaps intially, yes. But we’ll (have to) improve.
“What gets measured, gets optimised”: if we do this, we will be ‘proactively’ driving improvement.

(I hate the word ‘proactively’ but sometimes one has to talk to the enemy in terms they understand…:-))

I really like the Agile term “Information Radiator”…sums up the activity and the aim perfectly.

Agilists typically (but not exclusively) talk about raidating information relevant to their development activities and team. The bee in my bonnet here is that we should think about radiating information at all stages.

Sadly, my arguments always fall on deaf ears. I wonder why…

Is it me?

Is it $$$?

My guess is that is it fear…fear of being somehow “caught out.”

(I’ll probably have more to say on the topic of fear, later.)

So why didn’t I qualify the heading? Because I am taking the huge leap here and guessing–no: predicting–that your team doesn’t advertise itself to its clients properly either.

It’s time to change the world…this little aspect of it, anyway.

Tags:

Java Enterprise Edition, JEE, JavaServer Pages, JSP, Tag Libraries, Servlets, Enterprise Java Beans, EJB, Java Messaging Service JMS, BEA Weblogic, JBoss, Application Servers, Spring Framework, Groovy, Grails, Griffon, Seam, Open Source, Service Oriented Architectures, SOA, Java 2 Standard Edition, J2SE