Clearly this has fallen into desuetude as an outlet for my personal vision of the world. I’ll keep it hanging around while my hosting deal works its way thought, but I’m rebooting over on medium where you’re welcome to join me.
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?
If you’re trying to implement it because you’ve heard of it and it seems to be The Thing, then that plume of smoke on the horizon is the boat you missed.
I would argue it’s never about the killer app or killer hardware.
It’s about meeting the killer requirement.
- 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”
… 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.
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….
Thinking about estimating and realism, I wondered if anyone had listed out what I think of as the IT Constants…
Continue reading The IT Constants
My company doesn’t do bad business, but some preliminary sizing figures I saw the other day suggested we’d get through something like 4.9 billion customers a year. Even the most ambitious growth plan doesn’t see us in anything like that ballpark…. Continue reading Keep Your Eyes Open
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.