But Aaron, I hear you say...how do you make software more consumable?
Good question. Here's one handy definition: Time to Value. That means, from the time you identify that you'll use software to solve your problem, measure how long the interval is until you actually *deliver* a working software-based solution. Toss in a metric for average time to deliver maintenance and viola! Time to Value. Simple. Believable. Hard as s**t. But ultimately, we believe, doable.
IBM's idea, and this is portable across all software, everywhere, irrespective of origin/company etc. is this:
How effectively can clients identify the right IT solutions to solve a business problem, find the right IBM products and technologies to use, get the solution up and running, and maintain that solution? Our goal is to enable our clients to easily and effectively use our products to solve their business problems. Making this a positive experience leads to delighted clients, which in turn leads to strong references, repeat business, and revenue growth.
We're curious about your thoughts and as the months wear on, our progress (or lack thereof) in areas that you most need consumability.
4 comments:
Hi Aaron,
If I had to pick the #1 issue that new users of WID/WPS have when they are starting out, it's the incomprehensible exception messages that get generated when something goes wrong.
There's no association between the hardcore-low-level-exception and candy-UI-box-and-cloud view they designed the application in.
The way IBM currently deals with this is to just create a big table of exceptions with generic error handling steps that most of the time get you nowhere.
What I'd love to see is more emphasis placed on the developer who throws the exception to do more to explain what may have gone wrong. I realize its not a 'low hanging fruit' but the current format of 500+ line stack traces is overwhelming and needs to change.
Also differentiation between USER exceptions (Oops I forgot to initialize my variable) and SYSTEM exception (OOps, the developer forgot to initialize THEIR variable) need to be defined.
Halleujah, a real-live comment! Thanks for joining the social Dan and I do love your blog http://blog.danzrobok.com/... for you lurkers out there...you know who you are...
Anyway, you are right. We need to get much better about this and the disconnect we have between our SCA cloud and our Morlock-level (but damn reliable) JVM is vast. Connecting those two sensibly is our challenge. For starters, we educated our developers on proper IBM error message writing (i.e. why each one has three parts: what, why, how basically) and wrote automated scanners that caught bogus things like "call IBM tech support" for user action. This approach was also applied to our code base, for proper exploitation of FFDC (First Failure Data Capture), IBM's approach to catching unhandled or difficult to handle exceptions that hopefully add enough context to limit (ideally avoid) the need to recreate the exception with tracing on.
Thanks too for clarifying and providing an outside view of consumability of error messages and user vs. system exceptions.
The only issue with moving away entirely from stacked exceptions is that they're so damned useful to the proper crowd. We'd like to move that into FFDC where possible and leave stack traces in place for USER exceptions.
My question to you Dan, is Do you think that will work? We only want to throw stacks to users when they have control over the source. Otherwise, it's just noise you need to filter, and that causes needless stress. :)
One other research area is the semi-auto parsing of stack traces and cataloging of solutions related to specific, patterned matched traces (yes, we've patented the idea). It shows hope even for stack traces that you don't control, as it provides a fairly unique fingerprint to jump most directly to solution rediscovery and shared problem solving resource focus.
I was working with a customer recently and they made this comment. The problem with WPS is that it is too unpredictable!
Upon clarification what he was saying was that WID is unpredictable. You can't be sure of doing something and getting the same response every single time.
This has been a problem with WID since 6.0.0 and I am amazed we are still fighting with this.
The other issue they commented on was that the products don't integrate easily. They are using WPS/Forms/Google Web Toolkit. They found the way interface with HTM/BFM difficult and could not implement without help from IBM. They found the whole pipes architecture in Forms too complicated and were unable to get it to work without help from IBM. (In fact they needed PMR's to get it going)
The development manager then made the comment, "I have worked with other integration tools such as Web Methods, Seebeyond and others and although some were a bit more difficult than others, none of them compare to IBM's in terms
complexity and difficulty"
My view as an IBM consultant is that the breadth of the product set may also be it's down fall. This is a shame and if I had one request would be, lets have a freeze on new functionality and lets get the product set stable and simple to use. This may put me in ISSW out of a job but it would be far more beneficial to IBM as a whole.
Thanks for continuing the conversation Marvin. I agree, we don't hear feature demands as much as we hear demand for usability and predictability (tightly linked those two!).
One of the arguments we're trying to get traction on within IBM is that Consumability/Usability is just another feature...in fact, it's THE feature from where I sit (but I'm biased). Technology that is unusable (or overly difficult to use) is pointless. That's why I do what I do. As you note, at some point, even brilliant people will simply give up.
As we and our customers learn more about the ways in which our product is most useful to them, we need to partner on optimizing those workflows. Usability is making sure those paths are as simple as possible. IBM's tendency is to make the extremely simple relatively easy (high-end scalability), yet the things that are expected to be simple (initial install), harder than need be.
Post a Comment