Send in the enterprise clowns

More on roles and titles: Architect or Circus Clown.  Good points, except for the Eastern-Western angle. [I.e., it feels like Orientalism.]

British Airways - more life & death

Both Croucher and emergn's consultants agreed there are areas of development where agile is not an appropriate choice or, in some cases, even an option. "Approximately 25% of our organization has already changed over to agile. And we are still working to grow that number; but in the process of growing that number we've identified areas where we are certain waterfall development is our only choice," Croucher said.

BA chooses to use the waterfall methodology in areas where there are a lot of requirements that can't be altered; where user communities are long established and the existing infrastructure is functioning at a level that can't be easily topped; and where major operational integration software has been built around an SOA foundation. "These are the 'big bang' areas where a tremendous amount of continuous integration is required and there is no room for discussion or testing of barriers," said Croucher.  


-- from Where Agile development works and where it doesn't: A user story

Digesting this....


Requirements that can't be altered?  How is that a barrier to Agile? Every project has constraints.

Ditto for SOA and, in general, legacy software that has to be accommodated.

"... the existing infrastructure is functioning at a level that can't be easily topped ...."  This smacks of arm-waving.  But if there really is a waterfall process that ain't broke, not only shouldn't you fix it, you should tell the world about it.



"... where user communities are long established ..."  This is the one real issue:  the difficulty of explaining the benefits of Agile to people who have major economic and emotional investments in the status quo.

This article is a specimen of a certain genre of "even-handed", "objective", "above-the-fray" punditry: sure, there's a time and a place for Agile, but NIMBY....

P.S. If you follow the link in that quote to "waterfall model",  you'll see this:

Alternatives to the waterfall model include joint application development (JAD), rapid application development (RAD), synch and stabilize, build and fix, and the spiral model. 

Something missing?

More life-and-death Agility

The Rogers Commission found that NASA's organizational culture and decision-making processes had been a key contributing factor to the accident. NASA managers had known that contractor Morton Thiokol's design of the SRBs contained a potentially catastrophic flaw in the O-rings since 1977, but they failed to address it properly. They also disregarded warnings from engineers about the dangers of launching posed by the low temperatures of that morning and had failed to adequately report these technical concerns to their superiors. The Rogers Commission offered NASA nine recommendations that were to be implemented before shuttle flights resumed.

-- from Space Shuttle Challenger disaster - my emphasis.


Individuals and interactions over processes and tools  - if Agile principles had been applied, the Challenger might be flying today.   This makes the quote in my previous post even more hypocritical.

(Thanks to Sasha and Andy at Pathfinder for reminding me of this.)

Life-and-death Agility?

-- picture from Space Shuttle Challenger Disaster

A software development life cycle model (SDLC) is a very important tool for successfully executing a software development project, and it’s important to choose the right approach for the right project.  Some of the factors that would go into choosing the right SDLC model are:

• Risk and Complexity of the Project – you would never choose a very agile approach for building the Space Shuttle software. The risk and complexity of the project is probably the biggest factor in choosing the most appropriate SDLC model for the project. 
• ...

-- quote from Agile versus “Non-Agile” Development


When I read this, my first impulse was to say "just another old-line management type who doesn't get it".  But now I have an uncomfortable feeling about it.  Do I really believe that choosing waterfall development over Agile is a mistake - that the chances are good that it will come back to bite you?  I do - I'm pretty sure I do.

Then do I believe it would be prudent or even possible to use an Agile approach to building shuttle software?  Would I be a fanatic if I said yes?  Would I be inconsistent if I said no?  Don't I believe that Agile is the best way to deal with risk, uncertainty, unknowns? Can there be such a thing as "mission critical Agile", or are there some things that have to be done "the old-fashioned way"?

I certainly don't want to be a fanatic, but I think that if I don't believe that the best way to build the shuttle is with Agile, then there's something deeply wrong with what I do believe.

If I look at it from the standpoint of user acceptance testing, maybe the issue goes away.  Just as skeptics say, "extraordinary claims call for extraordinary proof",  we can say, "mission critical software calls for mission critical testing".

Suddenly this reminds me of how I overcame my fear of Ruby.  I spent years fighting for type safety, and now you're telling me to start typing like a duck?  I thought I could never trust a language like that. But then I realized that TDD is the answer - thank Dave for Rspec! - and I love Ruby to death.

If NASA doesn't have rock-solid acceptance testing, then it doesn't matter what approach you use - you can't trust the product. And if they do have rock-solid acceptance testing,  you're free to pick the most efficient and effective approach, because your problem is now insulated by the solid walls of a black box.

And the most efficient and effective approach will be ... Agile.

This doesn't mean that things don't have to change:  maybe we'd need a higher level of structuring of testing, above Fitnesse and XUnit and Cucumber and Rspec.  Maybe we need automated requirements traceability, but with stories and tests and coverage testing, not BDUF and humongous documents.

But change is what we embrace, and risk is what we face - with

 

Courage!

 

 [Bert Lahr pic from No Cowardly Lions Please!, which did not attribute source]

Because the world is round, you can't always say what you mean

Mercator projection, from Map Projection.  (Never knew they had such mathematical sophistication in the 16th century!)

Because the Earth is - sort of - a sphere, any attempt to project its surface onto a plane inevitably leads to distortion of some metric.  Mercator projection is great for navigation because every straight line is an arc of a great circle, but it distorts the sizes of land masses as you move toward the poles.  That's why there's not just one kind of projection - different maps for different apps.

One of the longstanding questions in linguistics is: why are there different grammars? For example, every possible ordering of subject, verb and object can be found in at least one language.  Claims for universal grammar get pretty abstract.

Well, here's my two cents on it:  because your mind is round, you can't always say what you mean.

Your neurons form a three dimensional network. Propositions/knowledge/ideas are tiny subnets of this network.  Language is a great human invention, but with the significant exception of sign language, it involves a lossy projection of a three dimensional structure onto a one-dimensional medium.

And just as in the case of map projections, no matter how you do it, something is going to get distorted - some kind of information is going to be lost.  This is why we have things like anaphora - for example, pronouns - that allow us to refer to the same "thing" in several different "places".  In our minds, that thing is in one "place".

There's a dynamic tension in syntax between what's easy to generate and what's easy to understand. The syntax of any one language at any one time represents a dynamic equilibrium - tradeoffs in different dimensions. Syntax mutates and responds to a changing sociocultural environment because the relative perceived costs of different projective distortions change. 

The same essential pattern applies to phonology - at any one time a language has a repertoire of phonemes that represent selection within two "competing" multidimensional spaces:  the variety of sounds we can distinguish with our ears

(the domain of acoustic phonetics) and the variety of sounds we can make with our mouths

(the domain of articulatory phonetics).  The tradeoffs are in terms of difficulty of distinguishing sounds vs. difficulty of generating them. And what determines those tradeoffs would have to be factors outside of language, as exemplified in various explanations of the the Great Vowel Shift.

When I first studied classical Greek, it amazed me that the people who spoke it apparently believed that it was so hard to pronounce a vowel followed by a 'b' sound that they had to put an 'm' between them, but the initial sequence 'pt' (as in "pterodactyl") was no trouble at all.

Anyway....

I'm sure this has all been said before, and I've oversimplified and overgeneralized up the wazoo, but it's a revelation to me, and I hope it will help me in my quest to ... uh ... do... whatever it is I'm trying to do....

[All illustrations are from Wikipedia]

More roles and titles

I'm posting this posted reply to the post I posted about in my previous post because

1. Ron Jeffries is cool
2. Charlie Mingus is cool (is-not-was, even tho....)

 Hello, Jerry. On Thursday, February 4, 2010, at 9:46:46 PM, you
wrote:

> To come up with what to code is the job of requirements analysts.
> So in most cases the wrong is not with coders but with
> requirements analysts. If requirements analysts were doing a good
> job, most, if not all, coders would be doing a good job.

Well, not according to how one does things in Extreme Programming,
in two regards.

First, the team includes what we call a Customer, who is ideally a
business person, not a "requirements analyst". The Customer, helped
by the Whole Team, expresses what is needed in three forms that I
call "Card, Conversation, Confirmation" , namely a small token to
remind us of what the "Story" is, and to use in tracking its status;
discussion of the need until the team and Customer understand the
problem; and tests, "owned" by the Customer but typically written by
the team, to determine that it works.

Second, your notion that coders would be doing a good job if
requirements were clear does not hold up in practice. In order to
write programs that actually work, we do need to know what to do. We
also need to know how to test that code, how to refactor it as our
understanding changes, and how to make sure that it keeps working.
It turns out that many would-be programmers do not have all the
skills necessary to turn "requirements" into viable "code", much
less the additional skills needed to be effective members of the
teams that create software.

Ron Jeffries
www.XProgramming. com
www.xprogramming. com/blog
Anyone can make the simple complicated.
Creativity is making the complicated simple. -- Charles Mingus

UPDATE - from another poster:

I would also like to suggest that the semantics in this case are important. Job titles like Architect, Requirements Analyst, etc. will pigeon hole people, and will cause folks to see boundaries that shouldn't exist.

Roles and Titles

I just saw this post on the Yahoo extreme programming group (my emphases):

I came across a while ago sth like below:
"to code is easy; to come up with what to code is hard."
To come up with what to code is the job of requirements analysts. So in most cases the wrong is not with coders but with requirements analysts. If requirements analysts were doing a good job, most, if not all, coders would be doing a good job.

Would you think there's any chance the poster works in an Agile environment?

Earlier today I  was phone-screened by a very friendly and smart guy from a consulting company who introduced himself as a technical architect.  He said he does pure architecture sometimes and hands-on development other times.  He later explained that Agile and Waterfall are per-client and per-project-lead options.

I've been a supervisor and a project lead. I was a manager once. I've been offered architect positions, but....

I'm a developer.

And a floorsweeper.

Tracking muck on the floor

Kent Beck tweet: unit tests and source control are muck boots for the programmer's mind--you just don't have to worry where you walk

That's the thing of it!  I'm screwing around with my Pragmatic module now - anything goes because I have enough Rspec coverage.  I don't worry - I be happy.


Well, as much as I can under the circumstances.