Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical

Re: Nobody Expects the Agile Imposition (Part VII): Metrics

by sundialsvc4 (Abbot)
on Jul 13, 2014 at 17:32 UTC ( #1093452=note: print w/replies, xml ) Need Help??

in reply to Nobody Expects the Agile Imposition (Part VII): Metrics

/me nods ...

“You’re over-thinking this thing,” he muttered, thinking about the book, Cheaper By The Dozen.   (A hilarious book by the daughter of an early process-management consultant ...)

Fundamentally, the writing of computer software has to do only with the success or the failure of the computer software to fulfill the purpose for which it was written.   Infrequently, the cause is programmer incompetence.   Usually, it’s because people are not-working together on a project that has never been completely specified in the first place.   And they’re not continually testing what they have done, to know if it actually works and keeps working.   In other words, yellow-stickies or not, it’s hopeless.   Whether or not you are measuring “progress,” the project’s taking one step forward and two steps back.   You measure time that is being profoundly wasted.

The best idea I ever had, a couple decades ago now, was to base things on a contractually binding task-order and change-order system ... and to make task-order #1 (and beyond) consist of building the remaining task breakdown.   Charging the same money to do that, or more, than for building code.   It’s modeled after the construction trades, and it works.   If you systematically embrace all of the best-practices that are involved (start to finish ...) in constructing a building or a roadway, and apply these to software ... it works like nothing else does.   (A project to repair the potholes in 100 feet of bad-condition street might consist of more than 250 line-items and accumulate the data points of more than 1,000 tests.   They leave zero, nada, nothing, zilch to chance or “creativity.”)

The usual practice ... and Agile encourages it ... is for people to be “lone wolves, in a pack.”   They forget that they are building a machine, that will work entirely without human intervention.(*)   The process they use is the same one they used in school ... at 11:30 PM the night before the assignment was due.   They’re frankly entirely accustomed to “pantsing it,” with only a token nod to planning, and no more of a nod to communication than will fit on a 2" x 4" yellow piece of paper.   Almost invariably, one person will be tasked with devising and writing the code for some feature, and for telling the rest of the “team” what s/he did after the fact.   I don’t know why this is so, but I’ve seen it in far too many teams to think of it as accidental.

So, what you really need isn’t “metrics” at all, in the sense of lines-of-code, hours-worked and what-not ... except possibly for cost accounting.   You don’t need to measure what your programmers are doing.   Instead, you need to be checking-off their progress along a meticulously-prepared punch list, cleanly separating the process of “deciding what to do and when to do it” from “what the source-code writers are doing.”   It doesn’t matter if folks are standing up or sitting down.   If the plan is good and complete, the work will go according to plan.   (And, yes, that plan should called for staged delivery and for overlapping threads of progress.)   If the work has been spelled out sufficiently, the writing and testing of the corresponding source code is ... perfunctory.   And the resulting code will be damned near bulletproof.   If you measure anything at all, it should be the on- or off-schedule progress of the machine that is being constructed day-by-day.

(*) The best book that spells out that idea very completely, from a project-management point of view, is a little Kindle-only book called Managing the Mechanism, by Vincent North, which is available [only ...] on Amazon.   Find it, read it.

  • Comment on Re: Nobody Expects the Agile Imposition (Part VII): Metrics

Replies are listed 'Best First'.
Re^2: Nobody Expects the Agile Imposition (Part VII): Metrics
by bulrush (Scribe) on Jul 15, 2014 at 11:03 UTC
    Management use individual KPIs to reward high performers in Sales and other departments. They are contemplating doing the same for Software Developers.

    They've tried this before in the 1990s, it didn't work well. There are many variables, and a huge variable is: your vendor's modules/software doesn't do what it says it does. Keep in mind that marketing people, not software engineers, usually write the marketing material. Thus the marketing people really don't understand what a product does, and when programming gets involved, details matter. This was so bad that in one company I demanded to review all documentation written for changes I made. (We had a marketing person writing technical documentation. Sometimes it lacked important details, and sometimes it was just incorrect.)

    Example: In the 1990s I was using MS Access. The box said it was backwards compatible with all versions. It was not. It only converted forms, queries, reports, and macros, not code. When a new version of Access was installed, all code had to be retested, and sometimes rewritten. If you used a lot of code, it was a sure bet something was going to break, especially if you used a DLL that got upgraded. When the OS or another product (like Access) was upgraded, some DLLs had their data type changed to another larger type, from integer to long for example.

    My point: you really don't know if your vendor's software will do everything it says because you can't trust what's on the box or in the documentation. Good luck getting your vendor to fix something (that should have been designed correctly in the first place) just for you without paying through the nose.

    Perl 5.8.8 on Redhat Linux RHEL 5.5.56 (64-bit)

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://1093452]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (2)
As of 2021-10-28 05:47 GMT
Find Nodes?
    Voting Booth?
    My first memorable Perl project was:

    Results (95 votes). Check out past polls.