What’s So Great About Reuse?

Another in my series of occasional articles espousing Enterprise Heresy… published now so that someone can read it; alas, unfinished.

Imagine this scene: the guy (and it usually is a guy, boringly enough) whose job it is to defend an IT department’s existence sitting, with his head in his hands, saying, “There’s just not¬†enough damn reuse in these systems.”

Hmm. Assign it a probability score from 1 to 10.

Now imagine the same scene, only he’s saying. “It just takes/costs too¬†damn long/much to deliver anything in this place.”

Is the probability score on this higher or lower than your previous answer?

Continue reading What’s So Great About Reuse?

Po: Reuse Is Harmful

  • It can create unnecessary coupling in a system if pursued with naive vigour
  • It can create an enormous governance overhead — which then has to add on a whole extra bunch of costs to prove that it’s delivering value and not just cost
  • No business ever asked for more reuse. Businesses ask for less cost and less lead time. Reuse used to be a proxy for these, but Agile may often be a better answer.
  • It was an IT mantra. IT mantras overshadow business realities. Few companies complain that their IT departments are too engaged or understand the realities of business too well.

PS. I did say “po”

Light relief: Three logicians…

… walk into a bar. The bartender says “Would you all like a beer?”

The first one says, “I don’t know.”

The second one also says, “I don’t know.”

The third one thinks for a moment and says, “Yes!”

Hat tip to Language Log for that one…

(This reminds me of the much shorter joke: One behaviourist walks up to another at a party and says, “You’re doing fine. How am I?”)

I’ll get my coat.

The Missing Constant

Of course, in my last post I forgot the one true constant in IT: change.

I’ve never really understood the level of unhappiness that change can generate within IT departments, which are usually about driving through as much change as possible to the rest of the business. Now I understand graduate coders getting shirty about requirements changing, and I’ve put enough change management in place to understand why you do it. But once you hit a certain level of experience and professionalism, whether or not it’s Gladwell’s 10,000 hours, surely you ought to stop being surprised by change and start being prepared for it?

Tons of practical consequences from that. In a SOA, from a technical viewpoint, it means get your contracts right, understand forward and backward compatibility, understand how your users are binding to your services and make sure you give yourself some wiggle room, because you’ll need it. In a larger context it extends to your supplier relationships, the developers your recruit or source… and to pretty much everything you do.

Are vendors just moving industry IT forward from one steady-state to the next? I can’t help but think a lot of people believe that This Time Is Different….

QCon London session now online….

Arjen kindly pointed out the other day that InfoQ has published the video and slides from my QCon London 2009 session with my colleague Stewart. I take full responsibility for my choice of shirt.

It was a great experience to spend three days doing nothing but listening to incredibly smart people talk about the things they’re passionate about in software. In fact, it was positively luxurious, and it really fired Stewart and I up to start getting a fresh current of ideas into our everyday work. I left wanting to learn Erlang immediately (Joe’s talk was a particular treat), to have my systems continuously available, to base everything on a web architecture, to do JIT architecture and, oh, everything all at once, even if the enthusiasms were mutually incompatible (write it all in Scala! AND Erlang! and Ruby!).

Of course, a set of unstructured enthusiasms does not a plan of action or a coherent system make. But all those sessions felt like a set of design patterns for approaches, rather than for software problems – and that’s a useful resource for anyone in any business.