Agile Racecar: Software, Magic, and Life

While searching for a metaphor for "Entrepreneur", I came across this very interesting blog by Tom Evslin: Entrepreneurs Are Predators Predators are smarter than prey. Hare-brained is an insult; sharp as a fox is a compliment. I have an evolutionary theory to explain this (full disclosure: except for reading voraciously on the subject, I am totally unqualified to have evolutionary theories).  A leopard chasing an impala can make a mistake, lose the quarry, learn from the mistake, and hunt more wisely on another day. If the impala makes a mistake, it becomes the leopard’s lunch.  Predators fail often;  Prey fail only once. So it would be a waste of energy for prey to have a large analytical brain or to divert any resources into learning while running away. Better just to have long legs, good ears, and a healthy paranoia.  Thinking could be fatal.  It also doesn’t take a lot of smarts to eat grass. On the other hand: Predators learn terrain;  they can le

Formally known as the Pareto principle, the 80-20 rule states that "80% of the consequences stem from 20% of the causes." Startups - who by definition are starved for resources - would do well to apply the Pareto principle to everything they do. From Wikipedia: It is a common rule of thumb in business; e.g., "80% of your sales come from 20% of your clients." It also applies to a variety of more mundane matters: we wear our 20% most favoured clothes about 80% of the time, we spend 80% of the time with 20% of our acquaintances etc. In business, dramatic improvements can often be achieved by identifying the 20% of customers, activities, products or processes that account for the 80% of contribution to profit and maximising the attention applied to them. The idea has rule-of-thumb application in many places, but it is commonly misused. For example, it is a misuse to state that a solution to a problem "fits the 80-20 rule" just because it fits

I have not met a single person who doesn't acknowledge the inherent values in XP when we talk about the values and not "this thing called XP". It is obvious to *anyone* who has enough years of experience behind them. * The challenge then they often face in accepting XP/Agile is their own conflict-of-interest. * You see, XP and Agile are brutal if you are lazy or if you are (or have become) mediocre. There's no place to hide in XP- everything is exposed. You can't create the anecdotal "job security hacks" so that you can't be replaced- because there are others in your team who know your code and can replace you if you're not pulling your weight. Or if you're a contractor, you now risk being caught for overbilling if you don't have "velocity" commensurate with the hours you're billing. I speak, of course, from my experience as a programmer. But more currently, I speak from my experience as the founder of a startup- as the em

The problem I see with most objections to Extreme Programing (XP) and Agile development is that they are often speculations on theory, rather than wisdom based on actual practice. It's amazing to see the amount of time and energy people spend in *discussing* process than actually building something and learning from the experience. The following is my real-world take on this subject, directed at no one in particular, but at everyone in general who is critical or afraid of XP (often the same people who don't have meaningful experience of using it): XP is a process that has *evolved* through the collective experience of programmers through the mess that the software industry had become- always late, always over-budget, always buggy. And we were told to accept it as a fact of life. In the midst of all the chaos, there were programmers working after hours doing what they weren't allowed to do during the day - writing tests for code (TDD), automating builds

While browsing the web randomly, I found this very cool article on the value of testing. Says the author, Gerald M. Weinberg: "Throughout my career, I've watched in dismay as one software manager after another falls into the trap of achieving delivery schedules by trimming tests. Some managers shortcut test work by skipping reviewing and unit testing in the middle of their project. Others pressure the testers to "test faster" at the end. And, most frequently, they just drop planned tests altogether, hoping they "get lucky." I've written several essays about the dangers of test trimming, but nobody seems to understand, so I asked myself, "What am I doing wrong?" Perhaps I wasn't practicing what I was preaching. Perhaps I was trimming tests myself. Perhaps my writing needed more testing! So, I wrote a story about taking shortcuts and read it to my granddaughter, Camille."