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