No more nails: making good technology choices
May 28, 2005 | co.mments
There are times when the business needs to get out of the way and let developers get on with things. Warning: hokey analogies between kitchen units and software follow.
Screws and nails
So you're getting your kitchen refitted. New floors, new unit, a fresh coat of paint on the walls. You're looking through some swatches for the paint, when you see the people fitting the shelf doors to the units are using screws.
Now, you don't have any screwdrivers in the house, just a few hammers. That's because you use nails to fix things together. Sometimes you use glue or staples for paper stuff, but for anything else it's nails. That's how it's been in your family going back since forever. Nails, nails, nails. But think about it. You've never fitted a kitchen; your experience is limited to hanging a few pictures. Are you going to tell those folks to use nails and not screws because you're worried you might not have a screwdriver around or you might now be able to fix a door when it comes off? That would not be smart, not just because you don't have a screwdriver, but because the person who decided to use screws is almost certainly more competent than you are at fitting kitchens. As there's few things worse than someone expressing a strong opinion in something they know little about, you decide stick to picking colours from the swatches and let people do their jobs. Maybe you'll pick up a screwdriver at the store and see what all the fuss is about. In the realm of kitchens, screws and nails count as infrastructure, and infrastructure decisions are best left to experts.
And I'm not being snide about picking colours. At the end of the day the colour of your kitchen matters more than how the doors were fastened onto the units - unless they keep falling off. That will drive everyone that uses your kitchen nuts. And if they fall off with using nails, and you keep hammering those nails back in, there's a fair chance that you'll end needing to replace all or part of the unit to use screws. Like you should have done in the first place.
The situation in enterprise development is somewhat different. IT managers tell developers to use software nails, either because those nails are considered industry standard or because they believed someone else when they told them those nails are industry standard. That using screws here and there could be a good idea, doesn't matter as much as the perception of standardization and adequate support.
Here's Richard Monson-Haefel on why putting the programming languages Beanshell and Groovy through the Java Community Process matters:
"Standardizing these languages has very little to do with portability and everything to do with industry acceptance. If developers at Suit-and-Tie, Inc. want to use a scripting language in their Java development, they are going to have to convince their project managers that language X, although not standardize or recognized by any industry body, is a safe bet. In practice it just doesn't work. If you don't believe me go try and convince your boss to switch from Java to Jython. It's not going to happen. - Why Standardize BeanShell and Groovy?"
Richard is right; what's happening here is that Beanshell and Groovy are looking to join the list of acceptable software nails. We should all be happy about this. What is bothersome is not that it's been said so frankly, that's the reality after all, but the implicit message: inefficiency is to be accepted, this is how things are done and will be done in IT.
We can all shrug, and move on to the next kitchen, and if we're lucky somebody else will be called into fix that other kitchen a year from now. We might call this playing not to lose, but it's probably that whatever yardstick is being used to measure is wrong and is leading people astray. One can look at an institutionalized inefficiency as being inevitable or as being an opportunity to save money on operating overheads . When the developers are telling you one thing about technology and the models tell you another, chances are the models are broken. So it is very much about making good informed choices. Developers mind you can be too quick to accept a status quo instead of looking to present new technologies in terms of improved costs.
Putting the soft back in software
One immediate problem with this line of thought, that says more effective but non-standard technology loses out is that it makes Paul Graham look unnecessarily prescient :) But the irony here is that these scripting languages are simpler to work with Java or C#; that's the whole point of using them! If managers are worried about who will manage the system legacy they could do worse than consider the use of languages that were once considered toys due to their simplicity, but are now known to be up to the task.
What is interesting are the "Higher Order Programming" (HOP) facilities enabled by languages like Groovy and Jython. HOP allows developers to eliminate inessential boilerplate and 'plumbing', produce highly flexible code, focus on code-generation techniques and in certain cases write self-modifying code. These capabilities are not just pointless computer science; they are associated with higher productivity and malleable systems. They end up supplied to a lesser extent by enterprise middleware and web frameworks or through language extensions and preprocessors. Two things are worth bearing in mind. First, the chances are if one can deal with things like J2EE caching, clusters and session management and constructing .NET assemblies, that's implies more than a requisite ability to grasp HOP. Second, it's clear that all enterprise languages and middleware are evolving towards HOP - this is evident in the rise of lightweight frameworks, vendor support for dynamic scripting languages and extensions like comment metadata and aspect-oriention to Java. Put it this way - for a competent J2EE developer focused on application level development, Jython is not going to present much difficulty, and could well save customers and bosses money. The people working on JSF/Shale, the web development platform to succeed Struts, are taking a look at the facilities provided by Ruby On Rails, a web framework which garners at least as much of its power direct from the Ruby language as the framework's design.
Bottom line is that enterprise developers are going to adopt this dynamic stuff one way or another, it's about how much productivity can be yielded and how soon. The most likely problems one will have with these languages is the tools will not be as user-friendly, stock patterns and idioms will no longer apply, and things will seem weird and ugly and well, wrong. But even with better tools, it's difficult to argue that a language like Java or C# is dollar-competitive with something like Ruby or Python for application development. Dynamic languages put the soft back in software!
Let's look at a fine example of technologists not always being able to make choices they might want to make - Webservices APIs. Doing the rounds at the moment is the Alpine manifesto [pdf] , which tells us what was known 3 years ago about Web Services programming. Alpine seeks to build a new Java stack for Web Services and calls out the Java API JAX-RPC in particular as having issues; but it was always likely that JAX-RPC would have issues. It, like a number of WS APIs at the time, shipped in reaction to Web Services hype which made it hard to become a basis for lasting infrastructure. The official successor to JAX-RPC is JAX-WS (renamed from JAX-RPC 2.0).
On the relative merits, JAX-WS is looking better than its predessessors. The problem is that it could have been available 3 or even 5 years ago - it's a non-advance, a screw replacing a nail. The fallout is a series of misguided attempts to re-purpose distributed objects for the Web; that costs money. Some Java infrastructure is now going to get ripped out in favour of something with lasting benefit, largely because short-term thinking about markets drove technology infrastructure decisions. That means some people are going to end up buying two kitchens for Web Services.
Skate to where the enterprise will be
There's been a lot of emphasis about focusing on what businesses and enterprises need out of software, that in particular the IT industry is too focused on the T . I think that is good, but sometimes business stakeholders need to get out of the way and let developers get on with things. Language choice for application development is arguably one such area, software APIs living the network edge are another.
When people who are good at technology are allowed to get on with things, and not be distracted by short term angles, there are benefits to be had. One place where that can happen is through Open Source development. Perhaps the key advantage in developing infrastructure in terms of Open Source is that it's difficult to subject it directly to market or bureaucratic agendas. Open Source is often accused of mere cloning of existing commercial software, and driving software value to zero. And yet a lot of interesting innovation, innovation that represents massive economic benefit, seems to be happening in that ecosystem. For example it's not impossible that instead of spending further millions of dollars trying to solve single sign-on on the server and growing webs of trust, it'll be dealt with along the lines of a GreaseMonkey script running on the client. If that happens, some will be quick to point out that it will never work, it will be unsafe, it won't scale, establishments won't buy into it, and so on. None of that will matter because it will be evident that the heavyset approach offers no further value, and the support systems needed to declare it a nail will coalesce around those who seem want to use it. It's a recurring pattern.
 The popular means to be seen to manage IT costs is to outsource development, but that is a race to the bottom if done without consideration. Most of the benefits realized from outsourcing are in supplying existing inefficiencies at preferred rates, something akin to paying less for what's bad for you.
 Currently it seems fads in IT are accelerating from the old 5 year cycle down to about 2-3 years. Nicholas Carr might have something to say about that, but hype acceleration wasn't in the Make IT Not Matter Plan, as I recall it.
May 28, 2005 05:44 PM