<rant>
Once upon a time – think 2006’ish – a complete revamp of a product was unveiled. The revamp went under the codename Hannover after the name of the city it was unveiled in. The revamp was to blow competition away and make the supplier of the product rule to World with the new product platform, new technologies and all the amazing stuff the client would be able to do. And it was amazing. It was like magic and provided access to new and amazing features and exposed great API’s that allowed developers to build sweet apps to bridge the gap between the proprietary world of yesteryear and the new internet era. It was built on a proven open source source platform and built using a proven industry standard programming language that many developers knew. It could be said that the language was the Lingua Franca of its time. To make it even better the client would be backwards compatible and run all the apps of its predecessors – like all the way back to the very first version of the product from the good ol’ DOS days. In many ways it was almost too good to be true.
It did however also not quite turn out the way the supplier had hoped. There was a problem with all this goodness. Not in the product. Not in the ambitions. Not in the chosen platform. In many respects it was a good idea, a good launch and the product delivered in most – if not all – of the areas it had promised new and amazing solutions for.
The problem was in the application developer support. They failed the product. Or maybe more to the point – the supplier failed the developers.
For the last 5-10 years nothing much had happened on the platform. Sure the platform had adopted JavaScript and Java and sure it had brought incremental improvements to the appdev experience. New feature here. A new simply action there. But nothing massive. But now the supplied threw this completely new way of developing apps on the market. The change was so massive and all the supplier would talk about was all these new capabilities – why wouldn’t they? Problem was that they had lulled developers to sleep with histories of declarative programming and how visual programming and laying out elements on screen was enough. One client to rule to them all. Simple actions and formulas to solve complex issues. But then all of a sudden developers was expected – from one day to the next – to grasp component development (called JSR 168 portlets at the time), data coming from different backend sources, UI threads, async programming, regex’es and low level widget development.
I’ll go out on a limb and state that the product was a failure. Sure customers migrated to the new client but many hesitantly. And it took a long time. Many never reaped any of the benefits of the new platform and ended up jumping ship.
Some developers did make the jump however as they were real developers. But many did not. It sounded too complex to them and it was. It didn’t align with the World they knew. They were business peoples trained to be developers – not developers by trade which was really a requirement. They chose to ignore the revamped product and all the features it brought. So all the good effort, energy, time and money put into product fell by the wayside. Sure it was used by some (including yours truly) but for many it was never adopted. So sad…
But why is this important and why am I writing it now?
Well to be completely honest it’s just a brain dump of thoughts. I find it interesting as time passes how often I see the same pattern reappear. Different products, different ways they try to reinvest themself and different results. In my opinion completely reinventing the way things are done in a product without making absolutely sure you either address the new message to the right audience or make sure the story is complete when told is due to fail. Of course some products are better than others and some suppliers are better at listening than others. But it’s interesting to watch.
But boy that Hannover product could have ruled the World if the supplier had been better at preparing developers beforehand and making sure they got on board.
</rant>
lekkimworld.com 
I don’t think it’s as simple as business people vs developers. I’m personally someone who came from a business background, did minimal coding in my youth and had no IT background before joining IT. What I had was a desire to learn and an awareness to look beyond where I am today and prepare myself for the future. That’s an attitude I often see lacking and I think is the root cause for a developer not modernising. As I know you’re aware of, there are some excellent training materials out there provided by companies to help modernise their developers. But no matter how good the training materials, they will fail if the developers have no desire to modernise and are allowed to continue doing what they’ve always done. In this case more could have been done to promote modernisation, but some people will always just stay with what they know. I think the key to being happy and secure in IT is accepting that change is constant and being willing to embrace what’s new. That’s down to a person’s culture, not technological background.
LikeLike
Oh yes I’m very aware – training and retraining is key. No doubt about it. In all fields but IT especially. Maybe my point is badly made – my point is not blaming developers or business developers. My point was more the consideration that needs to go into the planning and messaging when suppliers make leaps in their functionality or how they expect people to behave on the platform. Making the leap required too big can mean leaving too many on the – now – wrong side of the chasm… Hannover was just the example as I was there making the jump with few others…
LikeLike
Having been there, I would say the idea was to tap into an existing ecosystem of developers, namely the eclipse RCP crowd. But RCP didn’t really make it either. I would say a successful adoption of new tech was xpages, which was a better target for the supplier’s developer audience.
Chris
P.S. we will not speak of W—— but the portal tech has a good run.
LikeLike
Hey Chris – it’s been a long time. Right – let’s not speak of W… although it’s a product that with Liberty Edition really has transformed itself and made itself applicable in the new Cloud era.
LikeLike
I’m talking about the other W product from us. 🙂
LikeLike
Lol 🙂
LikeLike
Sounds very similar to Salesforce and their Lightning and DX plans… couldn’t happen to them, right. I was actually making this same comparison just last week.
LikeLike
Really?! You think so?! Shocking!! 🙂
LikeLike
Not only the developers were misled by the stories of declarative programming and how visual programming and laying out elements on screen.
Because the failure to properly sell the notion that yes, there is a steep learning curve, but the benefits are so great this will compensate handsomely led people responsible for managing developers and investment decisions to not understand the need for proper education and introduction to the new technology. Leading to very frustrated developers now looked upon as stupid because they did not deliver the magically new applications. And with them the platform and the supplier.
So the next time an enthousiastic IBM sales rep communicates about a wonderful new piece of kit, the receiver thinks: meh, another pipe dream… Let’s look at what the competition has to offer.
IBM not only shot itself in the foot, but managed to lop off the entire leg. Which is really sad because there is a lot of wonderful stuff made by IBM.
LikeLike
Don’t think I agree. By 2008 most of the planned improvements were already obsolete before they were even implemented. The ugly mix of the basic client and Java client (tremendously slow even on todays machines) was doomed. And of course LotusScript and Java always-incomplete-mix with strange designer, again, a combination of the old beast and Eclipse… Using Eclipse for the client was a horrible idea. The only viable way to do something useful was may be to open source the whole thing. I am still grateful I worked with this since I keep finding how stuff like NoSQL, distributed systems, asynchronous indexes and cross-location replication are being in trend today. This should have been kept. Proper REST APIs and messaging system on the programming level should have been delivered to developers, it was possible to do. Proper support for external mail clients and good application server would have done it. But, the APIs were delivered way too late. Messaging system for object was never delivered. A lot of time was spent to revamp the client, which should have been dumped in favour of server-side web apps. May be server-side rendering or even that bloody “plugin” would be enough to support users with legacy app.
LikeLike
Point is well taken and I agree with many of your arguments. As one who was heavily involved in the ecosystem and spent countless hours learning and building real applications on the platform (maybe I one of the very few who ever did?) I felt the pain as well. I too was severely frustrated and downright angry at IBM many times for missing the opportunity they had.
That was however not the main point of the post.
The main post which I might not have communicated clearly was not to lay it on IBM or to point out how they failed with Hannover. The point I was trying to make was more along the lines of how I see the same mistake being made by other suppliers in the industry and that I find it fascinating. One commenter (and I won’t name names) actually picked up on it very nicely so the post cannot have been a total failure. But maybe I could have written it better.
Thank you for taking the time to comment. Appreciate it.
LikeLike