Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine

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

by sundialsvc4 (Abbot)
on Jul 21, 2015 at 23:40 UTC ( #1135734=note: print w/replies, xml ) Need Help??

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

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.

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

Replies are listed 'Best First'.
Re^6: Beyond Agile: Subsidiarity as a Team and Software Design Principle
by einhverfr (Friar) on Jul 22, 2015 at 01:18 UTC

    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?

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

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (4)
As of 2020-01-28 09:27 GMT
Find Nodes?
    Voting Booth?