Monthly Archives: October 2005

BSM and Heros Don't Mix

Posted by —

0

David Norfolk sums up the problem with all systems management and BSM quite well:

Nevertheless, underlying all this BSM and SORM vision is an assumption that the parent organisation is reasonably mature — that it is committed to knowing or measuring what it has and how it is performing (for purposes of improvement, not blame), to documenting its goals, and to reducing the gap between reality and aspiration. This could be one of the reasons Gartner put CMDB maturity some 10 years out. If you work for the sort of company that values fire-fighting heroes and technical efficiency over effective business service delivery, attempts at implementing BSM or SORM may be doomed to failure.

Systems can measure, and even react, ’till they’re blue in the face, but in the end, it’ll always rely on people to do the right thing.

Tags: , , , , , .

[DrunkAndRetired.com Podcast] Episode 26 – Commodifying Enterprise Software, Standards by Monopoly

Posted by —

0

In this episode, we talk about The Paradox of Enterprise Software Innovation, how small companies can exploit their constraints to sell into the Enterprise Software market, and The Ambassador as an analog for technology monopolies.

Show-links: d&r_26.

Send us Comments!

As noted previously, we’d like to start splicing your audio comments into future episodes. If you’d like to comment, record the comment yourself, and email it to comments@drunkandretired.com. We’d prefer MP3s, but we’ll take whatever you can give us.

Tags: , , , .

Remember Management?

Posted by —

0

Developers are often the ones on the hook to make the date. Our man in XP land begs to differ:

If the primary issue is to “make the date”, and in my experience it usually is, then whoever has that responsibility needs to have the authority to apply people and resources, and to set the detailed objectives and goals. Unless we plan to give our developers the authority to hire and fire, to buy computers, to bring in contractors, we’d better not imagine that they can be responsible for the date. Unless we plan to give our developers the authority to decide which features will be delivered on the date and which ones will be deferred until later, we’d better not suppose that they can be responsible for the date. They can’t: they don’t have enough authority to steer.

To deliver the best possible combination of features by a given date, there must be control over the resources, and over the feature list. There’s no way out of this. If you go to the store with a huge shopping list and twenty dollars, you need the authority to go to the money machine for more cash, or the authority to make changes to the list. And shopping is a lot easier than software development.

Making the date requires managing resources and scope. Those are business functions, not development functions. What’s to do?

(Via rosimmons)

Tags: , , , , .

Submitting Comments for DrunkAndRetired.com Podcast

Posted by —

0

As suggested by Carlos, we’re going to take comments about the podcast. The quickest way to do it is to simply splice in MP3s that you, dear listeners, send our way.

In the future, we might setup a Skype voice-mail box, but for now, this quick and easy solution should work just fine.

So, if you’d like to record a comment, please export it as an MP3 (or other format if you really can’t create MP3s) and email it to comments@drunkandretired.com. The Windows “Sounds Recorder” can export MP3 files, so all you Windows people have something at your disposal.

If we get any, we’ll probably start splicing them in next week (as I’ve already got this week’s episode put together).

We’ll look forward to them comments, ya’ll.

Tags: , .

The Brisket Taco

Posted by —

0

As many of you know, dear readers, I’m a big fan of breakfest tacos. Between the hours of 9AM and 9:30AM, it’s about all I think about — having finished a cup of coffee. I am ruled by those two morning vices: coffee and tacos. Thankfully, only one of them has become a monkey on my back, the sweet, sweet dark, dark coffee-coffee.

My work is kind enough to buy everyone tacos once a month, and today was once such day. I came across an interesting taco: the brisket taco, seen above. It’s got eggs, cheese, and crumbled brisket.

While the taco confuses me — good ol’ boy food-stuff in a taco is out of the ordinary — it’s damn tasty. So, my advice to all of you out there is to try one of these out the next time you have the chance.

Tags: , , , .

Customer Therapist/Technical Spinmiester

Posted by —

0

In larger organizations — esp. in enterprise software — there are many people who play the dual role of Customer Therapist/Technical Spinmiester. This is a role that almost no organization wants to admit they need and have, but that every organization of large enough size has many, many people doing.

As we’ll find out, no one would want to admit that they have this role because the whole purpose of the role is to tell the customer “no” when it comes to fixing broken or otherwise screwed up things.

Cleaning the Bed

Obviously, I don’t have a perfect title for this role yet, but those those two titles capture the primary jobs of this role, in order:

  1. When your software shits the customer’s bed, you need to prevent them from going ape-shit and doing something like demanding a refund of all those millions of dollars they gave you.
  2. Control the spin of how the customer perceives your software. To a lesser extent, you want to control the spin of how the rest of the market perceives your software, but that’s usually only if news of the afore mentioned bed-shitting leaks.
  3. Containment: prevent whatever problems the customer is having from infecting the rest of your organization. For example, the customer could demand that you drop everything (like development of the next version of your product) and focuses exclusively on their problem. When someone’s holding a big wad of cash, this is always a huge risk. Another version of this is the dreaded mutual-assured-bundled-sale-descruction plan: “if you don’t fix these problems in product X, there’s no way I’m going to sign that multi-year/million dollar deal to buy products Y and Z!”

Software + Relationship

As many of you, dear readers, and I have spoken about face-to-face on several occasions, Enterprise Software deals are about half for the software, and half for the ongoing relationship that the vendor and the customer has. The customer wants to make sure the vendor will be there when things go pear-shaped. The role of Customer Therapist/Technical Spinmiester exists to take care of such times: they’re the relationship maintainers. The people who buy the flowers, give the massages, and promise “never to do that again.”

Small/micro-companies, of course, can’t compete on that level (despite being so God damn awesome): they don’t have the resources to provide an “enterprise-level relationship” with all their customers. (At least, it hasn’t been proven otherwise on a mass-scale yet.) Hence, the Enterprise Software Market is created and thrives where-in large companies sell software + relationship to other large companies.

As Charles and I start discussing in this week’s (upcoming) podcast, this constraint is something that small companies can use to drive features for their product(s)/services(s). But, you’ll have to wait until Friday for that.

Tags: , , , .

The Risk of Doing Nothing

Posted by —

0

Much of project management is managing risks. In the worst case, that’s all it is. So, when someone suggests doing something new, the project management part of your brain starts coming up with all the risks of the new things. Indeed, most of this type of thinking reduces to a strong belief in The One True Risk Theory: the primary risk is making any changes at all, no matter what those changes are. Changing course is risky.

When it comes to software I tend to think the opposite: staying the same is the primary risk. The status quo is doomed in most of the cases. In so many cases in the past decade, the real risk was doing nothing at all. And that’s certainly true now. As just one example: the telcos are taking a huge risk by not grabbing onto VoIP right now, full-throttle.

So, the next time you find yourself saying something is too risky, ask yourself: how risky is it to keep doing what I’m doing? What’s the risk of my current plan.

Indeed, this is a specific implementation of one of my favorite software laws, DeMarco’s First Law of Bad Management: if something isn’t working, keep doing it.

Tags: , , , .

"Trains running on time."

Posted by —

0

As most of you, dear readers, know, (1.) I was once an English major, and, thus, (2.) I have a weird and hyper-detailed attention to phrases people use. All that fucking lit-crit left it’s ugly burn in my brain. Thankfully, switching to philosophy at the last minute saved me from a malignant case of Englishmajorism. But that’s a story for another time…

IT Meets Il Duce

Another phrase people in IT/biz love using is “keeping the trains running on time.” This means, essentially, that the daily (even hourly) business processes that a business depends on are super-reliable. It’s the “99.99% uptime” concept.


Il Duce and Hitler

The problem I have with this phrase is that it’s associated with Mussolini, a freakin’ Fascists. You may also know him as “The Other Guy” the Allies were fighting in WWII in addition to the Nazis and Japanese

Biting You in the Ass

Oddly enough, the idea that Mussolini kept the trains running on time, according to snopes, is an urban legend. This makes the phrase even more rich, giving it the cyncical meaning that those who use it are blowing smoke up your ass. Or, as snopes puts it:

One of the best ways to gain the support of the people you want to lead is to do something of benefit to them. Failing that, the next best thing is to convince them that you have done something of benefit to them, even though you really haven’t. So it was with Benito Mussolini and the Italian railway system.

Tags: , , , , .