Testing and Design

Just watched a great video - The Deep Synergy Between Testability and Good Design, by Michael Feathers.  Combining this with JBrains' blog post How test-driven development works (and more) and his video Integration Tests are a Scam would make an excellent intro to TDD, and maybe I'll get a chance to use it soon.

Not so fast, Otaku

That last post was a little over the top, particularly the part about "good, true and beautiful".

Strike "good".

Although XP does have an ethical component in terms of how team members should relate to each other (and, to some extent, to the customer),  it doesn't deal with some wider issues.

You might never do a website for Kim Jong Il or Osama bin Laden.  That's an easy call.

What about Goldman Sachs or BP?

That's me at the pairing station, practicing my religion

The metaphor of programmer-as-craftsman and the concept of apprenticeship are great up to a point ... and that point is where it gets medieval.

I don't think software development is a craft - I think it can and should be (and - in XP teams - is) an alloy of art, science and religion.

For models, I look first to the Renaissance, to people like Michelangelo, who studied anatomy as seriously as any practitioners of "scientific medicine" of the time,  and to DaVinci, who studied physics equally seriously.  They were both also brilliant artists.

The medieval role that comes closest to a model for me is not the craftsman but the monk  - particularly the scribe whose faith in a divine perfection drives the work.

But the scribe is a soloist.  And so were Michelangelo and DaVinci.

Renaissance artists who weren't simply soloists were businessmen.  The master/journeyman/apprentice hierarchy in the art biz survives even now - e.g., Andy Warhol and his "factory".

What happens when software development organizations use the guild as a model?  In two big "Agile" consultancies I know of and will not name here, the result is ... architects.  Oh yes, they code.  But they also do BDUF.  And they radiate "authority".  This doesn't meet my understanding of Agile.

XP is not a solo activity but a communal religious action with a particularly clear vision of the sacred.  In OO we have an esthetically and logically balanced basis for design, still evolving.  In XP, we have a concept of perfection - the sacred - that is dynamic and minimalist:  the simplest system that does exactly what the customer wants, no more no less.   (I'm using the term "sacred" here the way social anthropologists since Durkheim have used it - there's nothing intrinsically supernatural about it,  except to the extent that symbols themselves are supernatural [for which I will make a case elsewhere].)

The closest modern analogy might be a Charismatic congregation (Catholic, Protestant or ...?)  with a lay leader who is not a priest (architect), who has no special connection to the sacred.  These groups are radically democratic.

What makes XP more than any of these models is the unification of art, religion, science and commerce.

It's the wisdom of a small crowd focused on the good, the true and the beautiful.

Nano-nit

As I've said before, JBrains is a freakin' genius.  I've never disagreed with anything he's said - except now for this one trivial point:  about 27 minutes into "Stop It Or I will Bury You Alive In A Box"* at Agile Bengaluru 2010,  he says that unit tests without assertions test nothing.

Well, it's not quite nothing:  if the test actually executes some target code and doesn't throw an exception, it's testing something.   But it's nano-next-to-nothing, it's still crap, and JB is still right.

* Okay, two nano-nits:  this is not correct title case.

 ------------------

P.S.  I forgot to say that you have to watch this whole presentation.  JB is - as usual - moving the state of our art-science forward.

More hardlining

Matt Heusser says

If your company is just starting to talk about "agiling up" it's software process, my advice is to forget about timeboxed iterations and test driven development. Oh yes, those are good things, and they can enable agile software development, but let's be very clear:  if the team isn't self-directed, cross-functional and respecting of its people, it's not Agile software development. It's ... something else.


Hold on to those ideals. Communicate about them clearly. Fight for them, leave no room for misunderstanding, and you might just make your little part of the software development world a better place.
I think that is noble, and worth fighting for.

Read the whole thing by Matt Heusser.

Hardlining

I wrote the following toward the end of my last contract.  I hesitated to post it because I didn't want to offend the folks I worked with, and because I worried about the effect it might have on my own marketing.  With some distance now, it doesn't seem that offensive,  and if it eliminates some potential opportunities, they're likely to be in places I wouldn't want to spend 40 hours a week in anyway.

My current "engagement" has turned me into a hard liner. I was burned, and I saw the light. I'm not going to go into details, because I don't want to be blacklisted as a troublemaker.

But I suspect I have no choice: I am a troublemaker.

I'm a true believer, and what I believe is this:

There is no Agile but XP and success is its profit.

Anything else that calls itself Agile is just a compromise with an increasingly myopic business/bureaucratic culture obsessed with short-term profit and the illusion of control and predictability via hierarchy.

Scrum may rein in some of the worst tendencies of that culture, but it doesn't get at the heart of the problem.

XP is about two things: one is communication - the dynamic perfection of process.

The other is perfect software.

This is not the static Baudelairean perfection of BDUF.  It's dynamic, minimalist, infinitely flexible.  To be an XP developer is to be a Zen calligrapher inscribing sacred language, to apply all one's intellect and energy to creating and maintaining software that does exactly what the stories say, no more, no less.

XP originated in the context of OO.  Unlike relational databases,  OO didn't spring full-blown from simple, elegant mathematical models, but it has evolved into something damn close.

This vocation is absolutely incompatible with the hierarchical/centralized model in which coders have no autonomy.

The bureaucratic model runs on the differential presence of one human emotion: guilt.  You rise to the top of a bureaucracy by becoming (or being born) a sociopath,   pushing risk downward.  Those stuck at the bottom accept this burden because they are guilty. The vision of future reward,  through graduation to heaven,  winning the lottery, or the application of sheer pluck and grit, is a consolation, not a motivating force.

I've been there - recently - I know exactly how that guilt works. People who work in the environment I'm talking about  would recognize the power of that guilt - if not for the protective psychological repressions and distractions - the bread and circuses - that make it bearable.

XP flourishes in startups and small businesses that can't afford IT departments.

But I want to take it into the belly of the beast.  XP is strong medicine, tough love.

Part II - Heroism

Waitaminit!  The success of TradDev [i.e.  waterfall/hierarachy/cmd&ctl] is not all about fear.  There's a carrot, not just a stick.  It's the solitary pleasure of heroism.   And the dark side of that is empire building and job-security-thru-opacity.

I had a heroism moment of my own:  successfully refactored some legacy Flex code without a net - i.e., no tests.  That was scary, and given the pathological coupling of the undocumented/untested codebase, it could have been a disaster.  (Actually, it still could be.  While I'm on that subject, instead of working effectively with legacy code by building a test harness around it, the team is drawing diagrams to document it. This will just contribute to its rigidity.)
...
As I write this, two heroes are talking near my desk.  It's a happy conversation. They're reinforcing each other's sense of being on top of things, and the buzz of working without a net in a risky environment. So what if it's about BDUF?
...
Now I'm idle.  No corkboard with cards for this iteration waiting to be picked up,  no pairing.  Waiting to get a JIRA (i.e., a task) assigned to me by our manager, who's working from home.  Yet another example of waste in the TradDev world.  I'm here waiting, so I'll bill for it, but it feels nasty.  If I offered to go home, what would happen?

Agile Manifesto Reprise - This Time it's Personal

Stole this from Ron Jeffries and I'm posting the whole thing cuz it's my story too except for maybe the cars:

>    Where will YOU be in 3 years?

Well, in my case I want to be alive and in good mental and physical
health. 


Looking back over various places I might have "wanted" to be, here's
what I think today: 


I thought I wanted promotions, to be given more "power" as a
recognition of how good I was. This reflected the organization I was
in, which valued power. I was wrong. I didn't get a lot of joy from
power. I did get joy from being able to solve harder and larger
problems by having more people working on them with me. 


I thought I wanted more money. This reflected my good taste in cars,
and has certainly given me some pleasure. However, the highest
paying jobs I have had were also the least pleasurable, and
ultimately my lack of pleasure in them caused me to perform poorly. 


I thought I wanted more women. You can imagine how that worked out. 


I thought I wanted to be like people I admired. Many of them were
major jerks (even more so than I am naturally) and emulating them
did not serve me well. 


What I want, today, is to spend every possible moment doing things
that I enjoy, with people I enjoy doing them with. I enjoy doing
things that I do well, and things where I can sense that I am
improving. I enjoy doing things that other people appreciate. 

Clarification of previous post

Actually, that last post was a nitpick - things are going well on this project.  My bottom line is in the black:  the question I've learned to ask myself about a job is whether it is an energy source or an energy sink, and this one has become a source.  The team is coalescing, including management, customer reps, etc., in spite of the legacy ceremony.

Trust/coherence is building, and the only question is whether/when management will perceive this and start dismantling the ceremonial edifice.

Efficiency and Trust

Haven't posted for a while because I've started a new contract.  The team is nominally Agile, the customer is nominally on board, but ... not really.   There's a lot of ceremony, no pairing or TDD expected (although we would not be punished for doing it),  a lot of micromanagement of time with JIRA (be sure to charge that 15-minute daily standup to the right task!).

And I finally made the connection....

What do you do when your team/company is all excited to be “agile”, while your customers want to operate in the traditional, heavy-weight, documentation-driven approach?  ...  In most cases it turns out that they don’t trust the software team and hence they want to push all the risk to the software development side.
-- I Say Agile, You Say Traditional, Document-Driven

Ceremony is the cost of doing business in an environment without trust.  Agile is efficient because trust allows us to eliminate ceremonies of security/CYA/blame/risk-shifting, which waste resources.

The word "ceremony" as used in Agile circles could almost be glossed as "institutionalized Muda (waste)".  As an anthropologist, I think of it from the perspective of Durkheim: He saw religion as a mechanism that shored up or protected a threatened social order. 

For example, estimates "cast in stone" are sympathetic magic, telling a highly structured story in the hope of imposing certainty on a situation involving major unknown risks.  Estimates in a traditional environment are not a tool but a prayer - or an oath.

...

I will not identify the customer or the consulting company I'm subcontracting through.   Not for any reasons of trade secrets or confidentiality, but because of this:

The customer's dress code is the new biz casual - i.e., jeans, polo shirts and sneakers are fine for everyone.  The consultancy requires us to wear the old biz casual - no jeans, no sneakers, dress shirts.  I was told this is because we want to impress the customer by being "a level above them".

Consistent so far.

But then - we have casual Fridays!   Not the customer - they're always casual. Just the "one-level up" consultants.

WTF?

It's like

... but because we really care about all our ... uh ... development associates ... ,  no beatings on Friday.

Moo-dada!

I won't believe a consulting company is Agile as long as it carries the baggage of the Old Biz Religion.

[UPDATE: see the clarification.]

Rockclimbing, Baguettes, Agile Skills and Opposing Forces

Got into some interesting conversations recently - check out Slack: we're not slacking off! and FORCES Behind Skills.

Life/Death/Agility 6: How Many Deaths Will it Take?

Milo passed this little gem on to me. It was published eight years ago and it makes just about every argument I've been making in this mini-series.  Why so long and still no change?

The passage quoted below may explain why "critical XP" still isn't happening:  a chicken-and-egg problem.  Read the whole thing for details on "Ron's project" and "the audit".

The theory of punctuated equilibrium holds that biological species are not likely to change over a long period of time because mutations are usually swamped by the genes of the existing population.  If a mutation occurs in an isolated spot away from the main population, it has a greater chance of surviving.  This is like saying that it is easier for a strange new fish to grow large in a small pond.  Similarly, disruptive technologies (new species of technologies) do not prosper in companies selling similar older technologies, nor are they initially aimed at the markets served by the older technologies.  Disruptive technologies are strange little fish, so they only grow big in a small pond. 

Ron’s project was being run under a military policy, even though it was a commercial project.  If the company policy had segmented off a commercial area for software development and explicitly allowed the team to develop its own process in that segment, then the auditor would have been satisfied.  He would not have seen a strange little fish swimming around in a big pond, looking different from all the other fish.  Instead he would have seen a new little fish swimming in its own, ‘official’ small pond.  There XP practices could have thrived and grown mature, at which time they might have invaded the larger pond of traditional practices.


But it was not to be.  The project was canceled, a victim not of the audit but of the economy and a distant corporate merger.  Today the thing managers remember about the project is that XP did not pass the audit.  The little fish did not survive in the big pond.


...


[in case you don't recognize How many deaths will it take...]

Learning as a design skill

  

the question isn't how good you can make it, it's how fast you can learn about it. that's a design skill too.

-- Kent Beck tweet 


Can we come up with "learning cycles" as powerful and satisfying as Red-Green-Refactor?


Hmm - downshifting tweets to blog posts ... too retro? I would have retweeted it, but nobody follows me on Twitter.  At least here there's a chance folks will check out the blog later....

Anything wrong with this picture? - 2

"Our team was perfectly aware that we sold scareware," says a translator who worked for the company in Kiev in 2008. "The manager never made a big mystery of that." The team the translator was part of had 10 staff and 15 freelancers to translate the text of IM's products into 28 languages. "Not everyone was happy about it, but money is money," the translator says. IM was paying around 60 per cent more than similar jobs elsewhere offered.

A mid-level employee, who left three years ago after realising what the company was doing, says that initially IM employed skilled developers to create genuine products. As managers became increasingly concerned with making money, quality declined and the fake scans came into use.

Roughly half the people working there knew the full story, says the employee, but again money talked. "There were a lot of young people working there who did not care about the product. They just took their salaries."

-- 'Infections found': Inside the great scareware scam

Anything wrong with this picture?

As an example, consider one of our first Agile projects. Its goal was to provide field representatives with handheld clients to access a back-end application for submitting and tracking loan applications for high-end recreational purchases such as boats, airplanes, and exotic cars. Without such a tool, the field representatives could not tell customers whether their loan applications had been approved for several days. In that time, customers often came to their senses and canceled the purchase. To finalize more sales, we wanted to be able to approve loans and notify customers while they were still in the showroom and still excited about the purchase. Furthermore, the business unit manager had calculated an opportunity cost for delayed delivery of the solution: If we missed the spring sales rush, we could lose up to $2 million in revenue per year, as well as losing market share and conceding the market leadership position to a competitor. That is an example of an urgent project. (The traditional IT group put in a bid of 10 months at $850,000; we did it with 4 people in 6 weeks at a cost of $73,000.)

-- from the otherwise great Dave Nicolette post that deFUDs Boehm and Turner (cited earlier in the Life/Death/Agility thread here). 

Reminds me of something I worked on once for an insurance company I won't name....

Integration Tests are a Scam - Quantified!

JBrains is brilliant, no way 'round it.   He wrote, directed and starred in this great indie, and if you want to see testing approaches dissected by the numbers, you'd better watch it.

Life/Death/Agility 5: Criticality and Changeable Requirements

Milo Todorovich has pointed me to the granddaddy of FUD-on-Agile, Life/Death division:  Balancing Agility and Discipline: A Guide for the Perplexed  by Boehm and Turner.  I'm trying to find a copy (IEEE wants $19 - hello, I'm broke!).  I intend to post episode 4 of this series shortly, where I magically demonstrate the ultimate Agile approach to criticality, but meanwhile, here's a corrective to B&T - read the whole post:

The Boehm and Turner book is generally very informative and useful; I still turn to it as one of a handful of books that help me with Agile project management on a practical level. But here they seem to reflect the fear of adaptive development that was common in the early days. Organizations were reluctant to risk an important project on an approach that was, in their experience, unproven. Circa 2002 or 2003, the authors' guidelines made sense. In the 2006-2007 time frame, as the industry moves toward institutionalizing adaptive development at the enterprise level, we need decision criteria that are more in keeping with the realities of large organizations, and with the (now) proven ability of adaptive development to deliver high value and high quality results. 

Criticality and Changeable Requirements

Because the criteria presented by Boehm and Turner are reiterated on Wikipedia , and will therefore be read by many, let's begin by re-examining them. First, I disagree with the authors' understanding of the criticality criterion. In our experience, it is precisely on projects of high criticality that adaptive methods have shone. Predictive methods tend to bog down in paperwork and procedure. By the time project teams have completed the heavyweight up-front analysis required with the predictive approach, the criticality of the proposed project may well have escalated to crisis proportions. An adaptive approach enables us to deliver results incrementally, and thus to begin to chip away at the critical problem almost immediately. Customers are usually more satisfied with that outcome than with the typical outcome of predictive projects. Increasing the chances of success is surely all the more important when the project is critical. 

-- When to be Agile, by Dave Nicolette

More FUD on Agile

The notion that the XP team leader tells the customer "Sorry, I can't commit to anything" is a bit of anti-XP propaganda that has been spread around. I can't imagine I'd get much business if I told people that.

-- Charlie Poole on Contractor Rate Based On Velocity - thread in Yahoo XP group

I haven't seen that, but it's not that different from the unbearable lightness of requirements.

Return of the Stakhanovites

One of the realities of development these days is that our software teams have heterogeneous skill levels. Most teams contain a mix of veterans and rookies. There can be large differences in how seriously people take continuing education, too. My team, for example, has a member who just announced that he never learned any of the Java 5 features and so couldn’t work on areas that used generics. Considering that we’re now migrating from Java 6 toward Groovy, this team member is pretty far behind the curve.

-- Testing as Contract: A Modest Proposal


That would be a really serious problem for any team, but particularly one that hopes to be Agile.

I hope that - as the subtitle implies - the author is kidding when he suggests that the solution is for the "veterans" to write all the tests.

Life/Death/Agility 4: The Unbearable Lightness of Requirements

Another in the ongoing miniseries, Life/Death/Agility.

I've seen this argument online and heard it in conversation: the reason you can't use Agile on serious projects like the Shuttle is that there are hard requirements that can't be changed.

Apparently it's a principle of Agile that the developers can change requirements. 

I can just see a team explaining to a NASA manager, "We understand you thought you had this requirement, but you have to get over it and embrace change: because of the Agileological refactorization/cohesion principle, we're going to have to make the heat-resistant tiles out of Charmin."

Us:Language::Fish:Water

Watching The Pluto Files, what struck me wasn't how upset non-scientists got about the "demotion" of Pluto, but the way astronomers, astrophysicists, etc. got all hot and bothered over it.

Whether Pluto is designated a "planet" is completely orthogonal to any practical/technical/scientific issues/research/hypotheses.  Nobody's disagreeing about any non-linguistic facts about Pluto or the "legit" planets.  This is exactly what people mean when they deride some controversy as "mere semantics" (and the opposite of what "semantics" is about).

We swim through this transparent, intangible medium all our lives, but every once in a while it hits us with a compression wave and we wonder - what the hell was that?

Career Pathing/ology - Getting at the obstacles

Great analysis by Tim Ottinger: Career Pathing.

The biggest obstacles to Agile adoption are the built-in pathologies of industrial organization, the ways human motivations are manipulated.  As Tim says,

In a typical career path, employees compete against each other for increasingly rare positions at higher levels. Esther Derby has written much about how this defeats morale and teamwork. In some situations one might find the "kiss up, kick down" strategy to be successful, where one panders to his bosses while sabotaging his peers and underlings. By political maneuvering, he is promoted (even "fast-tracked"), at the cost of productivity and harmony within the company. Distructive abuse of the career path discredits and defames the process.

The command-and-control model of organization (military-industrial complexity!) is echoed by waterfall methodology:  an unchangeable truth is emitted from authority and governs all following behaviors (horizontal) and all subordinate personnel (vertical).  This process gets its energy via the motivational patterns of the selfish gene/will-to-power/original sin.

More to come ...

Laziness in Moderation

A good programmer has to be just the right amount of lazy. If he is too lazy, he will simply copy & paste his code and modify a few lines. In the end, his codebase will be unmaintainable, but he might be promoted due to the amazing lines-of-code (LOC) he has achieved. If he is not lazy enough, he will not shirk from doing something over and over again. Both character flaws (too lazy and too eager) result in code that is hard to maintain. 
-- Heinz Kabutz, Generating Static Proxy Classes 2/2

Laziness is a subtle thing.  I always figured "copy & paste ... and modify a few lines" was more work, and it strongly resembles "doing something over and over again".

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.

Yet another frakkin' metaphor...

Vintage Trek from 1984, courtesy of YakShaving

This is beautiful, brilliantly engineered by master craftsmen and insanely efficient, but it's not what I want to build.  However,  it's what I do for a living, and I have to exhibit enthusiasm...

Wright Flyer 1, courtesy of Wikipedia

This is ugly and somewhat makeshift, and is pretty lousy at its intended purpose.  But....

Low-Hanging Fruit vs. High Risk

Among my various misunderstandings of Agility is the algorithm for deciding what story/task/monster to attack first.  It's either:

Go after the low-hanging fruit, get the process rolling with an easy win, warm up your tools and environment.

or

Jump into the biggest unknown first to reduce the uncertainty, start requesting external resources or services that you might end up waiting on, start researching something you may have a serious learning curve on.

With Sudoku, it's easy. I always go after the low hanging fruit - anything else would be absurd. Every cell filled in adds one more constraint to each of three cross-cutting sets - it lowers other fruit.  There are no externals and no research.

With my linguistic ... uh ... hobby, it's radically different. I want to jump in and BDD me up some Rails, but I have so much linguistics to catch up on...  The low hanging Rspec fruit is tempting, but biting into it won't bring me that instant knowledge of Good and Evil linguistic theories I need.

Who's More Agile - CSI-V or Leverage?

The Leverage team is all specialists, no real diffusion of knowledge or skills.  Of course, now they've got Seven of Nine, who's used to mind-melding....

The CSI-Vegas team all seem to know and do just about everything - including when to call themselves cops and when not to.  (This struck me in the latest episode [two dead pseudo-hookers and a pseudo-Jekyll] when Catherine was running a major lab op to get fingerprints off a DB with neither of the med examiners in sight.)  There have been learning experiences - when Greg (and later, Hodges) left the lab for field investigations.

Given that CSI-V has an aura of forensic science (in spite of - don't get me started - a major absurd fail at the MSI exhibit last year) and an imaginary lab to drool over, it does have some educational moments.  Leverage has its post-hoc scam "reveals" - clever, but it's not in the same league.

Character personalities are front and center in Leverage and tend a bit more toward cartoons. CSI-V is darker (in all ways).

Toward the end of Dollhouse (just watched the penultimate episode),  a team gels.  The distortion here is that skills are "learned" instantly via technomagic.

Bones  has the scientific aura of CSI-V and the rigid specialization of Leverage. 

Okay - so I love these shows, but there's an issue here:  pop culture inevitably provides role models.  Are they good models for real work teams?

P.S. What is it about the techies' names on these shows?  Bones has Hodgins (although Angela's the software geek), CSI-V has Hodges (who seems to have taken over Archie's responsibilities), and Hardison on Leverage is played by an actor  named Hodge.

P.P.S.  CSI-NY is a yawner and CSI-Miami is an obscenity - I won't even link to them.

...

Where have I been lately? Looking for an "engagement" and Railing on my linguistics hobby.