Adopting this mindset has provided me some benefits during the last few years. I guess my first touch with slow, even though not conscious, had to do with exercise. Some years ago I decided to get fit. You've got one life (not three or more like for Mario) so why not to spend it while being fit? Besides, you might be around a bit longer.
I remember starting really slowly. I did something like one long and slow walk per week and then some shorter exercises (a bit of running even). It was important not to start too fast. By draining yourself physically early on, you'll lose the will to continue. It takes a while for the body to adapt to the new regimen. After you get around the initial hump, the benefits are just huge.
Since then I've discovered barefoot running shoes, road biking and skiing even. Just today I finished a 135 km tour, something I couldn't have even dreamed of doing a couple of years ago. During the last summer I finished my first "epic" biking trip (three days, from Oulu to Jyväskylä). I've never been fitter in my life.
So how does it show? I simply have more stamina, my muscles won't hurt anymore after exercise, I rest easier, I don't get really sick anymore, my feet have seemingly repaired themselves (flat arch before, normal now). Better yet, if I feel a bit weary, all I need to do is to go for a ride for a fresh dose of endorphin. Man, that stuff is powerful.
Software Development - Too Fast for Its Own Good
Okay, now that I got that out of the way and hopefully got the message through (being fit is cool) I can get back to the topic at hand. One of the main things I've learned from exercise is that you cannot simply go fast all the time. You will need to take it easy at times. Especially in exercise regimen it is important to vary the type of exercise you perform, otherwise your body just adapts to the exercise a bit too well and you won't gain the benefits as well as you could. Sometimes you might need to push it a bit or do something different altogether.
Consider a typical software project. Commonly it's a frantic race against the clock. Longer term this is just draining, both mentally and physically. Worse, it's likely you won't have time to codify the things you've learned. Instead you might have to resort to hacks again and again just to beat the clock. Dave Moran actually discussed the disadvantages of developing this way a while ago. The core point is that by going too fast you might lead a more disciplined team for a while but long term you'll lose. This reminds me of marathon and the dreaded wall.
Can we provide better software, faster? I believe that yes, we can (to quote Obama). Software, and quality, are fractal, scale-free, by definition. It has certain kind of self-similarity. The structures are more or less similar on each level. By spending time and effort to make sure we don't build the wrong thing the wrong way this turns to our advantage. We'll be able to retain our cadence while providing the customer value continuously.
One problem that constantly faces us in the field of software development has to do with the nature of information. Either we know it or we don't. We also might have some idea of what we don't know. But most importantly we don't know what we don't know. This category is also known as unknown unknowns (thanks Rumsfeld!).
This is actually the reason why the first version most likely sucks. The second will suck a bit less and the third will be better even. It is extremely hard to get everything right the first time. We can improve our first guess somewhat, though.
The Answer
I believe the answer to this problem has to do with the speed of development. We'll end up better of if we have patience to understand what the users are after. This sort of lean approach to UX provides us means to provide better results faster. Going slow doesn't necessarily mean we cannot go fast long term. Software development isn't just a series of sprints, it's a marathon.
I'm not saying that lean UX is the answer to everything. It's not. It still takes a lot of craftsmanship and experimentation even to figure out nice ways to solve actual problems. Every person working on a project has to take responsibility for its quality. This responsibility implies ownership. You aren't building just something for someone to get some bucks, you are doing it for a good reason.
Just treating the user as a black box won't do. Usage of personas can help quite a bit. Instead of trying to imagine what the generic user wants (or rather the customer) we'll have a better way to justify our decisions. What would Joe the plumber do? What motivates Joe to use this accounting software?
Conclusion
I certainly hope lean UX and related approaches become more popular amongst software developers around the world. We have to take pride in what we do. Programming isn't just a job amongst others, it's a passion. By tweaking our approach, we can perhaps provide better service for our clients.