Posts Tagged ‘metrics’

It’s All About Me

January 2, 2014 Leave a comment

According to the stats helper monkeys, these metrics summarize my 2013 blogging output:

WP 2013 Numbers

Since conjuring up dorky, childish, clipart pictures seems to be my “strength“, it’s not surprising that I uploaded over twice as many pretentious pictures as blog posts.

The WP monkeys didn’t stop there. Those animals also tallied up my most-viewed posts of 2013:

WP 2013

Even though I don’t post on the topic as much as I do on other “stuff“, every single one of my top five “best sellers” explores some aspect of programming in C++ that piqued my interest. But that’s not surprising. Members of two sites with large C++ programmer followings, and, decided to share links to my top five on those sites.

In addition to being a blathering blogger, I was fairly active on Twitter in 2013. The talented programmers at gratuitously compiled a nice little video of my 2013 Twitter activity (you can see it here) and tallied up my most impactful tweets:

Top 10 Tweets 2013

If and can create synopses like these, just imagine what the NSA can do.

The Same Old Wine

September 3, 2013 2 comments

Goldman McKinsey

Investment is to Goldman Sachs as management is to McKinsey & Co. These two prestigious institutions can do no wrong in the eyes of the rich and powerful. Elite investors and executives bow down and pay homage to Goldman McKinsey like indoctrinated North Koreans do to Kimbo Jongo Numero Uno.

As the following snippet from Art Kleiner’s “Who Really Matters” illustrates, McKinsey & Co, being chock full of MBAs from the most expensive and exclusionary business schools in the USA, is all about top-down management control systems:

…says McKinsey partner Richard Foster, author of Creative Destruction. If you ask companies how many control systems they have, they don’t know. If you ask them how much they’re spending on control, they say, ‘We don’t add it up like that.’ If you ask them to rank their control systems from most to least cost-effective, then cut out the twenty percent at the bottom, they can’t.” (And this from a partner at McKinsey, the firm whose advice has launched a thousand measurement and control systems.)

A dear reader recently clued BD00 into this papal release from a trio of McKinsey principals: “Enhancing the efficiency and effectiveness of application development”. BD00 doesn’t know fer sure (when does he ever?), but he’ll speculate (when does he never?) that none of the authors has ever been within binoculars distance of a software development project.

Kim Jong Un Approval

Yet, they laughingly introduce a…

..viable means of measuring the output of application-development projects.

Their highly recommended application development control system is based on, drum roll please…. “Use Cases” (UC) and “Use Case Points” (UCP).

Knowing that their elite, money-hoarding, efficiency-obsessed, readers most probably have no freakin’ idea what a UC is, they painstakingly spend two paragraphs explaining the twenty year old concept (easily looked up on the web); concluding that…

..both business leaders and application developers find UCs easy to understand.

Well, yeah. Done “right“, UCs can be a boon to development – just like doing “agile” right. But how often have you ever seen these formal atrocities ever done right? Oh, I forgot. All that’s needed is “training” in how to write high quality UCs. Bingo, problem solved – except that training costs money.

Next up, the authors introduce their crown jewel output measurement metric, the “UCP“:

UCP calculations represent a count of the number of transactions performed by an application and the number of actors that interact with the application in question. UCPs, because they are simple to calculate, can also be easily rolled out across an organization.

So, how is an easily rolled out UCP substantively different than the other well known metric: the “Function Point” (FP)?

Another approach that’s often talked about for measuring output is Function Points. I have a little more sympathy for them, but am still unconvinced. This hasn’t been helped by stories I’ve heard of that talk about a single system getting counts that varied by a factor of three from different function point counters using the same system. – Martin Fowler

I guess that UCPs are superior to FPs because it is implied that given X human UCP calculators, they’ll all tally the same result. Uh, OK.

Not content to simply define and describe how to employ the winning UC + UCP metrics pair to increase productivity, the McKinseyians go on to provide one source of confirmation that their earth-shattering, dual-metric, control system works. Via an impressive looking chart with 12 project data points from that one single source (perhaps a good ole boy McKinsey alum?), they confidently proclaim:

Analysis therefore supports the conclusion that UCPs’ have predictive power.

Ooh, the words “analysis” and “predictive” and “power” all in one sentence. Simply brilliant; spoken directly in the language that their elite target audience drools over.

The article gets even more laughable (cry-able?) as the authors go on to describe the linear, step-by-step “transformation” process required to put the winning UC + UCP system in place and how to overcome the resistance “from below” that will inevitably arise from such a large-scale change effort. Easy as pie, no problemo. Just follow their instructions and call them for a $$$$$$ consultation when obstacles emerge.

So, can someone tell BD00 how the McKinsey UC + UCP dynamic duo is any different than the “shall” + Function Point duo? Does it sound like the same old wine in a less old bottle to you too?

Same Wine

Possibly The Worst Ever

“It is wrong to suppose that if you can’t measure it, you can’t manage it – a costly myth” – W. E. Deming

“You can only measure 3% of what matters.” – W. E. Deming

Even though he’s more metrics-obsessed than I’d prefer, in general I’ve been a fan of Capers Jones‘s contributions to the software development industry. In his interesting InfoQ article, “Evaluating Agile and Scrum with Other Software Methodologies“, Capers defines, as one of his methodology candidates, possibly the worst software methodology ever conceived:

CMMI 1 with waterfall: The Capability Maturity Model Integrated™ (CMMI) of the Software Engineering Institute is a well-known method for evaluating the sophistication of software development. CMMI 1 is the bottom initial level of the 5 CMMI levels and implies fairly chaotic development. The term “waterfall” refers to traditional software practices of sequential development starting with requirements and not doing the next step until the current step is finished. – Capers Jones

I shouldn’t laugh, but LOL! In the “beginning“, virtually all software projects were managed in accordance with the “Chaos + Waterfall” methodology. Even with all the progress to date, I’d speculate that many projects unwittingly still adhere to it. Gee, I wonder how many of these clunkers are lurching forward under the guise of being promoted as “agile“.

Moving on to the scholarly guts of Mr. Jones’ article, he compares 10 of his personally defined methodologies in terms of several of his personally defined speed, quality, and economic metrics. He also uses his personal, proprietary models/equations/assumptions to calculate apparently objective results for evaluation by executive decision-makers.

I’m not going to discuss or debate the results of Capers’ comparisons because that’s not why I wrote this post. I wrote this post because personally, I don’t think personal and objective mix well together in efforts like these. There’s nothing wrong with smart people generating impressive numeric results that appear objective but are based on hidden/unknown personal assumptions and mental models. However, be leery of any and every numeric result that any expert presents to you.


To delve more deeply into the “expert delusion“, try reading “Proofiness: How You’re Being Fooled by the Numbers” or any of Nassim Taleb‘s books.

Still Waiting…..

February 10, 2012 Leave a comment

Holy shite! Look at what my wordpress blog dashboard says today:

One thousand freakin’ published posts. BD00 is quite the bullsh*t l’artiste, no?

Alas, I’m still waiting for my….

Report Card

January 8, 2012 2 comments

Movement And Progress

September 24, 2011 Leave a comment

In collaboration with a colleague, I’m currently designing, writing, and testing a multi-threaded, soft-real-time application component for a distributed, embedded sensor system. The graph below shows several metrics that characterize our creation.

The numbers associated with the most recent 9/22/11 time point are:

Of course, the pretty graph and its associated “numbers” don’t give any clue as to the usefulness or stability of our component, but “movement” is progressing forward. Err, is it?

Don’t confuse movement with progress – Tom Peters

What’s your current status?

2010 Blog Metrics From WordPress.Com

January 3, 2011 Leave a comment

Note: The content of this post was auto-generated by the folks at

The stats helper monkeys at mulled over how this blog did in 2010, and here’s a high level summary of its overall blog health:

Healthy blog!

The Blog-Health-o-Meter™ reads Wow.

Crunchy numbers

Featured image

A Boeing 747-400 passenger jet can hold 416 passengers. This blog was viewed about 10,000 times in 2010. That’s about 24 full 747s.

In 2010, there were 350 new posts, growing the total archive of this blog to 587 posts. There were 614 pictures uploaded, taking up a total of 25mb. That’s about 2 pictures per day.

The busiest day of the year was March 2nd with 127 views. The most popular post that day was Strongly Typed.

Where did they come from?

The top referring sites in 2010 were, Google Reader,, and

Some visitors came searching, mostly for quantum physics, do you design the classes diagrams before writing code, accountability, sysml, and quantum.

Attractions in 2010

These are the posts and pages that got the most views in 2010.


Strongly Typed February 2010


UML And SysML March 2009


Quantum Consciousness July 2009
1 comment


What The Hell’s A Unit? November 2009


About Me March 2009

Esther Tweets

August 31, 2010 Leave a comment

I’m passionate about all aspects of software development, including, uh, project management (I really am). Since Esther Derby is an insightful and pragmatic thinker filled with valuable tips, techniques, and methods for successfully executing hairball software projects, I follow her on Twitter. Check out this trio of sequential tweets.

My answer to Esther’s last question is: “It would be great!“. Alas, most managers don’t, or aren’t allowed to, think in terms of systems. Systems thinking isn’t valued in siloed, CCH corpricracies, so managers have no incentive to learn or apply it’s principles and techniques for continuous improvement. In really badly run orgs, it’s too dangerous for one’s career to think or act horizontally in silo-city. It’s too bad, because orgs of people are richly interactive dynamic systems of systems that require constant shepherding to keep every person and every group and every unit aligned and connected.

Metrics Dilemma

October 15, 2009 2 comments

“Not everything that counts can be counted. Not everything that can be counted counts.” – Albert Einstein.

When I started my current programming project, I decided to track and publicly record (via the internal company Wiki) the program’s source code growth. The list below shows the historical rise in SLOC (Source Lines Of Code) up until 10/08/09.

10/08/09: Files= 33, Classes=12, funcs=96, Lines Code=1890
10/07/09: Files= 31, Classes=12, funcs=89, Lines Code=1774
10/06/09: Files= 33, Classes=14, funcs=86, Lines Code=1683
10/01/09: Files= 33, Classes=14, funcs=83, Lines Code=1627
09/30/09: Files= 31, Classes=14, funcs=74, Lines Code=1240
09/29/09: Files= 28, Classes=13, funcs=67, Lines Code=1112
09/28/09: Files= 28, Classes=13, funcs=66, Lines Code=1004
09/25/09: Files= 28, Classes=14, funcs=57, Lines Code=847
09/24/09: Files= 28, Classes=14, funcs=53, Lines Code=780
09/23/09: Files= 28, Classes=14, funcs=50, Lines Code=728
09/22/09: Files= 28, Classes=14, funcs=48, Lines Code=652
09/21/09: Files= 26, Classes=10, funcs=35, Lines Code=536
09/15/09: Files= 26, Classes=10, funcs=29, Lines Code=398

The fact that I know that I’m tracking and publicizing  SLOC growth is having a strange and negative effect on the way that I’m writing the code. As I iteratively add code, test it, and reflect on its low level physical design, I’m finding that I’m resisting the desire to remove code that I discover (after-the-fact) is not needed. I’m also tending to suppress the desire to replace unnecessarily bloated code blocks with more efficient segments comprised of fewer lines of code.

Hmm, so what’s happening here? I think that my subconscious mind is telling me two things:

  1. A drop in SLOC size from one day to the next is a bad thing – it could be perceived by corpo STSJs (Status Takers and Schedule Jockeys) as negative progress.
  2. If I spend time refactoring the existing code to enhance future maintainability and reduce size, it’ll put me behind schedule because that time could be better spent adding new code.

The moral of this story is  that the “best practice” of tracking metrics, like everything in life, has two sides.

Product Development Systems

April 24, 2009 Leave a comment

The figure below shows two (out of a possibly infinite number of) product development systems. Which one will produce the higher quality, lower cost product in the shortest time? Would a hybrid system be better?


%d bloggers like this: