RSC 2009 – Making Software More Important

I was at RS(D)C earlier last week. Rational’s messaging, along with some supporting product announcements, was along the line of what you’d expect from a contemporary IBM software talk: raising the discussion and concerns “up” the chain as close to the business as possible. The talk is less of features and flashy demos (see Bill Higgins’ Jazz/cloud blog for some product-pizaz), and more of what all that can do for a business. Here, the conversation largely boils down to:

• Specifying – tools and practices to help companies describe what they want their software to do. “Requirements management,” we’d call it. Rational, esp. with the addition of Telelogic last year, has a bevy of tools to help collect and track requirements. Ask them why they have multiple tools for this same task, and their answer is that different types of software folks need different types of requirements tracking tools. People who develop “traditional” server/desktop driven software (what most people think of when they talk about developing software) don’t need all the detail and discipline as systems people (or “embedded software,” as it’s more traditionally called), who need “engineer” level seriousness and complexity.
• Practices – continuing the spirit of RUP in the sense of putting together a library of software development practices that companies can choose from. That is, helping companies figure out the best way to go about the day-to-day activity of developing software, from Agile, to water-fall, to whatever fits their needs “best.” Hidden below the management level “IT/business alignment” talk are team-level practices like continuous builds, unit tests, and the usual software development cud we’ve all been chewing over for the last 10 or so years. Here, the Measured Capability Improvement Framework (or MCIF) is the big announcement. From what I can tell of MCIF, it’s sort of like traditional, RUP/CMM/Waterfall development philosophy sent to Agile boot-camp and then shipped off to get an MBA. During an analyst call, Ovum’s Tony Baer called MCIF “management consulting for software,” which put it well.
• Reporting – when any “process” is concerned in the enterprise software world, the “alignment” in “IT/business alignment” means reporting, and then manager making decisions based off that reporting. More than just gathering together a bunch of paper-work, the point of the reporting is to allow The Business to make decisions about the process in question, largely without understanding or participating (day-to-day) in that process. Much to the consternation of software developers everywhere, The Business that decided what development’s fate really have no understanding or care about the actual “craft” of writing software. Instead, The Business wants to establish metrics (fed by inputs from the development process – insert magic enterprise software here! ;>) that roll-up to reports, where those reports tell The Business everything from “is it going to be delivered on time?” to “am I on budget?” to “if I add more money, will be deliver on time…get more features?” etc. Here’s where the other cluster of Rational announcements fit in with Insight and (a bit lower down the chain) Focal Point.

Much of the Rational messaging emphasis the last point, reporting and The Business. The promise is that we’ll (The Business, the non-technical folks who run things) finally solve the problem of knowing what the hell is going on in software development and, consequently, be able to control it like we would any other business asset like, say, a fleet of vehicles or the practices a sales associate uses to stocks shelfs or tries to up-sell customers. The promise is that software will stop being an impenetrable necessity you sink money into, and start being a tool that you, The Business, can use to drive new and improved business strategy and, thus, revenue.

Managing the Impossible

Now, this kind of marketing falls into the category I like to call snidely “isn’t that what was supposed to be happening all along?” We all know that software development is, largely, impossible to manage with easy success: the Standish group comes out every year and tells us how terrible a job the industry does. Software is just difficult, and it has a certain observer effect wherein the more you worry and futz with the process, the more complicated you can make it.

It’s easy to throw rocks at people trying to fix this problem – early Agile Priests made a whole industry out of it! My belief is that maturing software development as a practice will take more time: much more time. As an industry, we seem to have solved the problem of software development with small teams, and there’s also the Garbage In, Garbage Out rule when applied to the process: most companies develop software on the cheap, and are naively shocked when the result is cheap software. Call it the American Software Development Methodology.

Developing “perfect” software is far from being a cheap or quick process, and much “improvement” in software development comes from being pragmatic: scaling back expectations of how much value software can deliver and how quickly the software can get done. Beyond being pragmatic, the next level of getting more value out of software bumps up against the vagueness of “be more like Apple”: maybe the CEO should care about every tiny thing in a business process from how a barista serves coffee to the software that prints out receipts. Or, you could just compete on low-priced goods and crushing your competition. (See Douglas Rushkoff for a sort-of post-captalism take on this.)

In a positive slant, caring more about the software that enables your business is actually part of Rational’s big picture vision.

When you’re your problem…

For many years now, Agile methodologies have been the current silver bullet for solving all our software development process problems. Much of the discussion from Rational of late has been about hoisting up the success of Agile in the small up to Agile in the large – it goes by other names, “Enterprise Agile,” “Agile at Scale,” etc. From what I’ve seen from Rational over the past few years, like most everyone else, they seem to be figuring out how to get ponderously big customers to shift to Agile development.

The part that’s difficult to analyze here is what exactly their types of Agile are (seems to be all?) and if it’s rigged up cheap enough. The danger is that all of the extra layers of “tooling” that give The Business reports and controls are an excuse, intended or not, for Rational and its partners to sell more tools and consulting. That is, does a large company really need to buy all these tools and philosophies from Rational, or can they just be simplify their large and complex (read: expensive) processes? And even in the positive version: how much should you pay to get more simple? To use re-word one of my favorite Mark Pilgrim phrases, “a lot of complexity went into making this simple.”

This is the moment of doubt where the likes of Atlassian jump in, selling functional simplicity for less. The reply from Rational would be that teams of 1,000’s working on things like missiles or global banking systems require lots of complex tooling: I mean, have you seen all the levels of meetings required to develop <Insert State-of-the-Art Airplane or Killing Device Here>?”

…but the problem is worth paying for

The “systems” angle that Telelogic added to Rational gives them a thick snark-shield from the above. Businesses who use software as a component of their overall system (like a car or cellphone) are more capital “E” Engineers than so-called software engineers. We’re told that they require more discipline, thus more complexity, and thus more tools. There’s certainly some feeling of truth there, and you can see that the emphasis that Rational puts on software as an overall component of a business strategy instead of just part of IT fits well here: if software is clearly involved in the core business, it’s worth spending more money on. The alternative is that software is just part of IT (the people who run your email, not your business), who indirectly supports the business and doesn’t so clearly contribute to revenue.

When looking at what Rational talks about and how it positions itself, then, you can expect it to be very similar to one of it’s sister IBM software brands, Tivoli (see Al Zollar above: indeed!), and talk less about the day-to-day life of the IT department employee (developers and operations folks), but more and more about those who consume that IT, The Business. ‘Cause, as they say, that’s where the money is.

Disclosure: IBM is a client and paid travel to RSC 2009. Watch for some upcoming RedMonk videos they sponsored there as well.