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.