Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

Re^4: Beyond Agile: Subsidiarity as a Team and Software Design Principle

by Your Mother (Bishop)
on Jul 21, 2015 at 11:43 UTC ( #1135646=note: print w/replies, xml ) Need Help??


in reply to Re^3: Beyond Agile: Subsidiarity as a Team and Software Design Principle
in thread Beyond Agile: Subsidiarity as a Team and Software Design Principle

I was arguing the philosophy leading up to the statement was misguided and that a master plan (strategy) cannot be directly applied in daily work (tactics).

Segmented responsibility, which I agree is the way things work best in the world, not just project management, looks like anarchy from 10,000 feet or on a 10 year project plan. Intelligent design, crock that it is, has been a persuasive idea for all human history because self-interested "anarchy" churns out things like spider silk, gecko toes, echolocation, and mantis shrimp eyes and claws in immeasurable amounts.

  • Comment on Re^4: Beyond Agile: Subsidiarity as a Team and Software Design Principle

Replies are listed 'Best First'.
Re^5: Beyond Agile: Subsidiarity as a Team and Software Design Principle
by sundialsvc4 (Abbot) on Jul 21, 2015 at 19:40 UTC

    Actually, from a biological standpoint, that is just speculation.   But, in any case, we are not talking about Nature at all:   we are talking about a very, very human project.

    And in my specific case, I am talking from a very long history of working with projects that failed, or that were about to and I managed to help claw them back.

    The problem is that everything ... everything ... in a computer program of any size is functionally connected to everything else.   (“Software is a Mechanism,” again ...)   These dependencies exist, not only in the simple flow of information and control, but also in sequence and in time.   Even if “responsibility” is segmented, the finished software is not.   And, end-users and their specification documents can provide no useful information with regard to these, because these people do not know how to build software, nor how software is built or how it functions.   We do.

    Also, please:   I am not standing on a podium or a soap-box here, and I am neither speaking in absolutes nor trying to.   I look at a lot of “project failure-states,” and therefore get a pretty good idea of how they got there, but my goal and purpose is only:   to get them out of that state.   How, where, when, and why did the process fail?   (Pick a language, pick a platform.   Hell, for that matter, pick a methodology.)

    Fairly consistently, I find that there has been a lack of appreciation for the de-stabilizing consequence of “change, itself.”   Both on the part of the team, and on the part of management / owners.   Very, very often, there was some sort of “surprise discovery,” and this resulted in deep, rippling, changes.   (Imagine a sepulchral “gong” that just keeps reverberating down unknown cloistered halls at the Monastery ... Suddenly, one reverberation is accompanied by the ominous sound of a falling block of stone.   Somewhere.)   Very large chunks of the source-code could be seen in the change-control system (if they had one ...) as being changed at once, and there were a couple more commits to pick-up things that had been “missed.”   Again, I am seeing these things mostly from what is by that time a forensic perspective.

    In all cases, the projects were undertaken by professionals who never meant to fail at what they had set out to do.   For a while, the project is flying high.   Then, there’s a puff of smoke.   A little ... puff of smoke.   Nothing to be concerned about ... a puff ... of ... smoke.

      I think part of the problem is that human communication is bound by the CAP Theorem too.... But worse, our language is by nature inconsistent.

      This is why larger groups of small teams is better than smaller groups of large teams. If the teams have segmented responsibilities, you have fewer issues caused by breakdown of consistency.

      Thus I think the most important task in initial design is to get the teams right, properly small, and with appropriate division of responsibilities.

        A reply falls below the community's threshold of quality. You may see it by logging in.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (4)
As of 2019-11-12 08:34 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Strict and warnings: which comes first?



    Results (64 votes). Check out past polls.

    Notices?