Tuesday, September 15, 2009

Deliberate Practice in Software Development

Leading Lean Software Development: Results Are not the PointAt Agile 2009, Mary Poppendieck gave a talk on the theory behind craftsmanship. She starts out by giving some stats on Hockey Players from the book Outliers. 40% of elite Canadian hockey players were born between January and March, 30% April – June, 20% July – September, 10% October – December. The cut-off date is the end of the calendar year. So the ones born in December are at a disadvantage since they will be the youngest. The same applies for European football players.

Mary then defines talent (nature) as abilities, powers, and gifts bestowed upon a person; natural endowments; general intelligence or mental power. Also, talent (nurture) is a special innate or developed aptitude for an activity. Talent is overrated. The most accomplished people need around ten years of deliberate practice before becoming world class (ten-year rule).

Next Mary defines deliberate practice: Identify a skill that needs improvement, devise a focused exercise designed to improve the skill, practice repeatedly, obtain immediate feedback and adjust accordingly, focus on pushing the limits expecting repeated failures, practice regularly and intensely up to 3 hours a day.

Then Mary elaborates on the four elements of deliberate practice:

1. Mentor: masters, teachers, deeply knowledgeable and involved. They hire and grow people, review and guide work, set technical standards, and ensure technical excellence.

2. Challenge: do it frequently and it will become easy, test/integrate/release early and often, change the code frequently, assign challenging work assignment, focus on constant improvement of the product, process, and people. Don’t get comfortable, get better.

3. Feedback: Immediate feedback: Design reviews with mentors providing guidance, common code ownership with peers providing visibility, TDD, CI, customer feedback at every iteration, escaped defect feedback and analysis. Focus on what’s not perfect so it can be improved. You have to ask constantly “why are we doing this?” Bad news first!

4. Dedication: skill development takes time in place, time to learn, and time to invent. Also need motivation, and career paths for technical experts.

Implementing Lean Software Development: From Concept to CashMary wraps up by stressing the importance of clean code and going over the Software Craftsmanship manifesto. We value not only working software but also well crafted software, not only responding to change, but also steadily adding value, not only individuals and interactions, but also a community of professionals, not only customer collaboration but also productive partnerships.

This presentation is available on InfoQ at  http://www.infoq.com/presentations/poppendieck-deliberate-practice-in-software-development

Integration Tests are a Scam

At Agile 2009, Joe Rainsberger gave a talk about integration tests. Joe states that integration tests (end to end) are a scam. He defines integration tests as is any test were the result of the test depends on the correctness of more than one interesting behavior (multiple objects, multiple unrelated methods, complex enough to be tested on their own).

Next Joe covers some basics system object classifications from Domain Driven Design:

1. Values: Simple like string or number, transient, equality depends on value rather identity, light weight enough to be created when needed and thrown away when not

2. Entity: values with entity semantics have essential identifier and end up getting stored somewhere, equal if ids are equal.

3. Services: Stateless action of some kind.

Joe explains that any test that verifies 1 entity or service behavior possibly with multiple values involved is as focused a test as we can expect. Values are our inputs and values are our outputs. We do not want to test multiple entity or service behavior at the same time as this will lead to long running test suite. These result in slow feedback that eventually lead to no feedback since we stop running them. The tests lose their power of a pool of change detectors. The later a mistake is found the more costly it becomes. This also leads to a false sense of security. Over a long running time, the value of having the tests is roughly the same as not having tests at all.

Tests consist of arrange (put together the things you want to test), act (invoke what you to test), assert (check result). Next Joe discusses the problems with excessive test setup that are usually needed for integration tests. Due to all the setup, we end up having multiple asserts per test or even worse, multiple actions per test. Alternatively we copy/paste setup into multiple tests. The hard coding of dependency is making it impossible to check something without executing something else that we do not want to check right now.

Next Joe explains that when integration test fails it is not clear where the failure is. Integration test are slower than focus tests. # tests needed is the product of the code path(4*3*5=60 test to be thorough). The # of test is not exponential but combinatoric. In reality if we do a really good job we end up with less than 1 % coverage. It is like the lottery, when the odds of winning are 1 in 40 million, buying 10000 tickets is not that much better than buying 10. When we need 4 million tests, writing 20000 tests is not better than 2000.

Monday, September 14, 2009

I Come to Bury Agile, Not to Praise it

Agile Software Development: The Cooperative Game (2nd Edition)Alistair Cockburn gave a talk at Agile 2009 about software development. He explains that developing software is about people making concrete ideas in an economic context. It is about people inventing, deciding, communicating, solving problems and creating solutions that they don’t yet understand and keep changing, expressing ideas in primitive languages to an interpreter unforgiving of errors, making decisions with limited resources and where every choice has economic consequences. All of engineering and team design patterns kind of fall into this definition.

Next Alistair describes one pillar of software development as a cooperative game. Games have positions, moves, and strategies. Some are competitive like chess which is finite and goal-directed or poker which is open-ended. Others are cooperative like rock climbing which is finite and goal-directed, or jazz and music which are open ended games. Some fall in the middle like both like organizational survival and career management. These are infinite.

He explains that software development is cooperative, finite and goal oriented (funding model): 1 round is a deployment of the system. IT system is cooperative and open ended games. They live until we get tired of them, retire them, rebuild them or buy a commercial system. Product Line Management maps to infinite games. After one release 3.0, a competitor comes out with something new, and we follow our release with a .x release just to stay in the game and so on.

The game has two conflicts, to deliver the software and to setup for the next game by refactoring architecture, adding tests, making sure juniors are ready to lead, and adding documentation, etc. Both are competing for finite resources. Only three moves are allowed: invent, decide, and communicate. Also, the situations (almost) never repeat. The strategy that worked on last project, odds are it might not work on the next project. We have to always be alert.

Next Alistair states that we have to adapt to your situation based on the number of people to coordinate and the criticality to the application. Communication and control structure change and strategies, setup, conventions need to change accordingly. Face to face is the most effective form of communication. When there are question and answer the best form of communication is people at whiteboard, then people on phone, then people on chat. If there are no question and answer then best is videotape, then paper.

Crystal Clear: A Human-Powered Methodology for Small TeamsAlistair describes distance as expensive. If we assume that 2 programming in pairs communicating once every 20 minutes cost nothing then 12 people on same floor but in different rooms cost 100K/yr penalty in communication speed, and 12 people on different floors cost 300K/yr penalty in communication speed. People issues determine a project’s speed. Setup a project so people can detect when something is not right. They need to care enough do something about it and effectively pass along the information. Speed of the project is the speed of which ideas moves between minds (attitude and mechanics for communication).