Agilistas talk about “velocity” as if that is the metric that matters.
It isn’t. What matters is how long it takes to create a reliable software product — how long it takes to get from Point A to Point B.
“Agile Vehicle Turns on a Dime,
Gets Nowhere Fast”
If the teams so-called “velocity” is high, but they are doing donuts in the parking lot and changing direction daily, constantly throwing out and rewriting code because they did the simplest thing possible, thinking only for today and not for tomorrow, they will and do take longer than a team that adopts a think first, code second approach.
Understanding the problem leads to a better overall solution — even if it takes time to understand the problem.
Consider flying from LA to Tokyo. Pretty much, Tokyo is directly west of Los Angeles. So, the so called “Agile” team would “do the simplest thing” which is, to fly directly west.
A more thoughtful team would realize that it takes more time and fuel to fly directly west than it does to fly a so called “Great Circle Route”.
The earth is narrower at the poles. Therefore, it is faster to fly northwest, towards Alaska, where the earth is a smaller diamater, then fly southwest, over Hokkaido. This is the shortest path between two points on a sphere.
The XP team would never have thought to even investigate such a beast. Next time you fly internationally, be thankful your airline didn’t use an “Agile” process to do your route planning. It would have added hours to your flight, while saving the XP team a few hours of coding. YAGNI? LMAO
The tortoise is indeed faster than the hare.
Slow Down. Think First. Understand the Problem Thoroughly. Then Code, Neo.
The Agents think they are Agile — but you’re faster than that.
The Practice and Art of Software Composition 
Wow you make me want to comment Oh Maestro!
Surely one of the major tenants of Agile Development is to not do the most simple thing but to solve the problem in the most simple manner.
As you set out the problem “Fly from LA to Tokyo”, the agile team would have solved the problem. However at the end of iteration one, the stakeholders (presumably including the odd pilot or two) would have broached fuel economy and distance traveled etc. Adding these parameters the team would have come up with a better i.e shorter route. YAGNI … maybe not but until we as developers and architects understand our domain (in this case air travel) better we will build the best solutions we are capable of.
I am not slating this post as it has great value. I particularly like the phrase:
“Slow Down. Think First. Understand the Problem Thoroughly. Then Code, Neo.”
I would precede the word understand with “Make efforts to …”
Again maestro, a thought inspiring post which I enjoyed commenting on.
Kindness,
Dan
Well, when I took my first College Programming Class, at age 12, the professor REALLY hammered in that we weren’t to even get close to the keyboard until we knew exactly what we were going to code.
Back then on timesharing hardware it was too expensive to have the terminals tied up pondering the problem.
How times have changed…. IBM used to have signs that said “THINK” in every office. In Agile offices it probably just says “CODE”.
But you’re right, after some complaints from passengers, pilots and global warming, agile would have gotten it right the 2nd time.
But why anger the customers and damage the environment by getting it right the 2nd time?
That’s why I advocate, and have always have advocated the think first, code 2nd mentality.
You mention “until we understand the domain better, eg air travel”… that is exactly what I mean.
Software Development used to be called R&D. RESEARCH and Development. Now it’s just D — code.
I advocate having the team spend as much time understanding the domain as possible, however long that takes. I do a lot more R than D.
The more Research I do the less Dev I need to do and the better the dev comes out…
Understanding the problem thoroughly saves much rework and rewrites that an XPish team would go through;
Cheers!
S.M.
I’m not at all persuaded the Business would ever have brought up fuel economy in the sense that they would have required an optimized route… That assumes they had a reference point someone else is providing. How else would they have known, “Hey – this trip could be more efficient if we flew northwest.” There’s a difference between what the Business THINKS they want and what they really want.