Wednesday, March 4, 2009

Who needs developers when you have IBM?

It used to be that software vendors sold customers bridges based on the lie that business analysts could write the software with their awesome new tools...eliminating the need for programmers.

I just ran across some interesting marketecture for IBM's Integration Developer product. They appear to have conceded that a BA can't program with the tool. But possibly even worse, the introduction to the product advertises the following:
WebSphere Integration Developer enables integration developers to assemble complex business solutions that require minimal skills, whether they involve processes, mediations, adapters, or code components. Users can construct process and integration solutions using drag-and-drop technology without having a working knowledge of Java.

Sounds like a great plan, huh? Hire an "integration developer" to implement a java-based integration without a working knowledge of java. Because you're just "assembling" complex business solutions...IBM's products take away the complexity for you! Show me someone that fits their target audience that can even properly define the words mediation and adapter.

A couple years back, I saw a presentation at NFJS by Neal Ford that pretty much matched my viewpoint exactly in my own experience. He sums it up in this blog series. Yes, integration is hard. Yes, it takes very experienced developers to get it even done at all, and even those very experienced developers will make a lot of mistakes and produce less than ideal solutions because this is a new field, and remote computing sucks regardless of how smart the solution is.

The bottom line is that you can't hide the complexity under a rug. Products like this will get you 80% of the way there, and by the time you figure out that they're not the right solution, it might be too late. You might have run out of budget, haven't finished, and have a bunch of unhappy customers mad at you. But congratulations, you've just helped your can't-get-fired-for-buying-vendor fund their next line of bridges to sell you.

Want to do it right? Simplify your problem by defining what information needs to go from A to B first, and then listen to the right people that have done this before and aren't getting paid based on how much of their product you buy.

Sunday, March 1, 2009

The Development and Infrastructure Team Dysfunctional Relationship

If you spend any time making software in a big company whose primary job isn't making software, the following patterns about the development and infrastructure teams probably apply:
  • The development and infrastructure manager are different people.
  • The managers and their staff sit too far apart for osmotic communication.
  • They are in calls or meetings together all the time.
  • Yet angst abounds between the two groups all the time, whether it's overt or simple passive aggression.
If you're lucky, the managers are technically competent and secure enough to have the good hard conversations that are necessary, thinking about things from the customers perspective and from each others perspective. Or if they're not technically current enough to have the conversation themselves, hopefully they can step aside and get the right heads together from each team to figure out things out together correctly.

Unfortunately, as the mighty MC Hawking likes to riff, Order from disorder is a scientific rarity.

Whether it's outright silly and misguided arguments, or the "WTF are they thinking?" kinds of conversations had within each group after a meeting, it seems these two groups consistently spend too much time acting like slashdot commentors and not enough time reading Peopleware.

What's difficult about this problem is that it's not a technical problem. It's the natural result of two diametrically opposed organizational forces.

If the developers would just stop writing crappy software.

If the infrastructure manager would just stop being such a grump.

If the business would just go away.

Believe me - they'd love to. This whole time they're wondering why your crappy system costs them millions of dollars, and still doesn't work as well as their free Picasa photo album, which arguably does more than your system that's shoveling bits from A to B just like all the other thousands of companies exactly like yours. But that's a whole 'nother story coming up...(the software sausage factory from a normal person's point of view).