Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number

comment on

( #3333=superdoc: print w/replies, xml ) Need Help??

/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.

In reply to Re: Nobody Expects the Agile Imposition (Part VII): Metrics by sundialsvc4
in thread Nobody Expects the Agile Imposition (Part VII): Metrics by eyepopslikeamosquito

Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":

  • Are you posting in the right place? Check out Where do I post X? to know for sure.
  • Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
    <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
  • Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
  • Want more info? How to link or or How to display code and escape characters are good places to start.
Log In?

What's my password?
Create A New User
Domain Nodelet?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (6)
As of 2021-10-19 15:12 GMT
Find Nodes?
    Voting Booth?
    My first memorable Perl project was:

    Results (77 votes). Check out past polls.