All Posts in Metrics

|In: App Dev Methodologies|Last Updated:

Metrics seems like such a good idea. If you can’t measure, after all, you can’t manage, or so Peter Drucker asserted a long time ago. He’d be horrified at how this dictum has been misapplied.

Drucker was talking about business processes, where if you can’t measure you really can’t know when something has broken down and needs attention. That’s the proper scope of Drucker’s Metrics Dictum. It applies to business processes. Too many business managers think it applies to everything.

We’ve been talking about DevOps, whose name comes for the inclusion of Ops members in Dev teams, but whose most interesting characteristic is that it replaces waterfall’s big-bang deployments, and even Agile’s large-scale releases, with a continuous stream of small deployments that are subjected to automated testing and then automatically promoted to production without so much as a rubber stamp from a Change Advisory Board.

The metrics question of the day: Do Agile and DevOps speed things up?

The answer is that there is no easy answer. To understand the challenge, answer this question instead: Which is faster, the Internet or a truck?

Figure the truck has a 4,000 cubic foot capacity. You fill it with SanDisks, each holding 64GB of data. The truck drives 1,000 miles at an average of 50 mph. If I’ve done my arithmetic right, the truck delivers more than 35 million terabits of data in 20 hours, yielding a bandwidth of just under 500 terabits per second.

Imagine your MPLS monthly bill for that kind of bandwidth. The truck wins by, you’ll pardon the expression, a mile.

Fortunately, network engineers recognize that bandwidth only tells half the speed story. The other critical network metric is latency. Here, the truck doesn’t fare so well. The first data packet doesn’t arrive until 20 hours after it’s transmitted, compared to a typical Internet ping of maybe 15 milliseconds.

So which is faster, the Internet or the truck? Answer: It depends on what you need more, high bandwidth or short latency.

Waterfall methodologies are the trucks of application development. They deliver a truckload of software features in one big delivery. The business waits for six months or more before anything goes into production, but when the wait is over it gets a lot of new functionality all at once.

Agile methodologies, and DevOps even more so, are the Internet of app dev, delivering new functionality more frequently but in smaller increments.

Where the metaphor breaks down is that with our truck vs Internet comparison we had a useful standard unit of data delivery – the bit.

Comparing app dev methodologies, we don’t. For a while we had function points, but they never really caught on, mostly because they’re too durned complicated to properly count. Also, they’re useless for Agile because function point analysis has deep connections to waterfall’s up-front specifications, which is one reason Agile replaced them with user stories and story points (estimated degree of difficulty).

So trying to compare waterfall and Agile for the speed of software delivery just isn’t going to happen in any reliable way. Even comparing Agile and DevOps is dicey. Agile delivers user stories weighted by story points. Increasingly, DevOps delivers microservices, not full user stories.

Try to apply Drucker’s Metrics Dictum to application development and you’ll find you’re trying to answer the question (to change metaphors mid-stream): Which is better for beating the other team — a great passing game, or the knuckleball?

And oh, by the way, these things have strong connections to the type of business change you need to achieve. Standard Agile practices are just the ticket when your goal is continuous improvement. Waterfall actually can work well, assuming you’re implementing a new business process you’re able to specify with precision and that will still be relevant when the multi-year initiative wraps up.

When designing a good metric turns into an intellectual quagmire, the problem is probably that we’re asking the wrong question. IT’s goal isn’t software delivery, after all. It’s supporting the achievement of intentional business change.

That being the case, what we should be looking at is whether, for a given desired business change, IT’s app dev methodology is a major source of friction.

Increasingly, business leaders care more about the organization’s ability to change direction quickly to address threats and pursue opportunities, and less about organizing and implementing large-scale strategic change.

With this change in the style of business change there’s no longer much doubt. The Agile/DevOps spectrum of methodologies is far more likely to keep IT from being sand in the company’s gears of progress.

Comments

|In: Industry Commentary|Last Updated:

Did we give up too easily?

We used to automate processes. Back in the early days, before we called ourselves Information Technology, Information Systems, or Management Information Systems, that’s what we did.

We didn’t optimize processes, orchestrate them, or develop metrics to assess their performance. We obliterated them, replacing them with computer programs that called on humans only when an input or decision was required the computer couldn’t handle on its own.

To be fair, we didn’t always do this all that well. Some of these automations sped up business processes that contributed little business value beyond keeping some people busy who otherwise might have caused all sorts of mischief.

There were also quite a few cases where the program paved a metaphorical cow path, faithfully reproducing in automated form every process step that had previously been executed by a bored human being, even if these steps had nothing at all in common with what an engineer might construct if given the goal and a blank sheet of paper.

But even with these flaws, IT’s predecessors delivered orders-of-magnitude improvements in business efficiency. And then Something happened, and suddenly, overnight, IT became the biggest bottleneck to business improvement.

My theory is that Something = Methodology, but perhaps I’m being unfair. I’m not, after all, a business historian, so while I lived through some of the mayhem, my personal mayhem experience isn’t a statistically significant random sample.

Based on my personal experience, direct and second-hand through colleagues, here’s the way process automation happened back in the good old days we neocodgers see in the warm glow of imperfect memory:

Someone from the business would drop by EDP (electronic data processing, IT’s ancient forebear), sit on the corner of a programmer’s desk, and ask, “Can you get the computer to do x?”

After a short discussion the answer was either yes or no, and if it was no, a longer discussion usually led to a useful alternative the computer was capable of.

The programmer would go off and program for a week or so and call the business person back to review the results and suggest course corrections. In not all that long the computer had automated whatever it was the business person wanted automated.

Usually, in the interim, other notions occurred to the business person, who, while reviewing how the solution to the initial request was progressing, would ask, “Can you also get the computer to do y?”

Over a span of a few years these solutions to business problems accumulated, turning into the big legacy systems many businesses still rely on.

If we’d only had the wit to call what we were doing a methodology and label it Agile.

Had we done so we might have avoided quite a lot of the discreditation that happened to IT during the years of waterfall wasteland that, starting in the early 1980s, transformed us from the department that automated stuff, generating enormous tangible business benefits, to the Department of Failed Projects.

For that matter, had we continued in our quest to automate the bejeezus out of things in our naively Agile sort of way, disciplines such as Lean and Six Sigma might never have achieved their current level of prominence.

Not that Lean and Six Sigma are terrible ideas. In the right contexts they can lead to solid business improvement.

What they’ve turned into for some businesses, though, are Strategic Programs, and religions for some practitioners. For these devoted adherents they’re the answer to all questions, before actually asking the questions.

What they’ve also turned into is a sort of IT-less shadow IT — a way to improve business processes without any need to involve IT, and, more important, without having to ask the Department of Failed Projects to deliver very much.

Let’s imagine the executive team at some enlightened (or misguided — your call) company reads the above and, convinced, calls to ask how best to return IT to its process automation roots. What would a modern version look like?

Mostly, it would treat each process as a black box that turns inputs into outputs. IT’s job would be to understand what the inputs and outputs are, and to develop, through a combination of inference and listening to the experts, an algorithm that reliably turns the defined inputs into the desired outputs.

That’s it — the entire methodology in one paragraph, understanding that “algorithm” can hide a lot of complexity in its four syllables.

Might this work? Beats me. It’s an idea I’m just starting to play with. Next week I might strenuously disagree with this week’s me.

Don’t hesitate to weigh in.

Comments