The Case for Slow Programming

Obligatory cite to SQL On Rails http://sqlonrails.org/

Glad he doesn't touch type? What a lame excuse for not mastering the tools of his trade! That's like a carpenter saying he's glad he never properly learned to use a hammer. There is a time and place for a steady pace and thorough design process, but not in the early stages of a startup. If you can't keep up with your user's feedback and market demands then you'll lose to a scrappy team that can, no matter how beautiful and elegant your code. 95% of software startups that become wildly successful were built on an initial base of excrutiatingly ugly code. Gold plating code for a business that is bound to change directions is a great way to ensure failure.

There are three types of "good architectural choices"

The first: The ones that can be made after the original, bad ones. The second draft, which is an improvement in the first draft, in every field.

The second: His (or her) own. We all know there are developers out there who think they're the greatest thing to ever write code, and that everyone else's decisions are bad.

The third: The ones that really should have been made, in place of the ones that really shouldn't have been made. As in, "You wrote your own SQL parser using hardcoded strings and no grammar parsers?"

This post resonated with me as well, but I think for different reasons.

At the beginning a team doesn't really know exactly what kind of flexibility and functionality will be required as they iterate. Teams can of course leverage experience with similar projects to come up with possible future requirements, but these are just educated guesses at best, and self-inflicted scope creep at worst.

Because very little is known about the stakeholder's needs a team needs to iterate to become more familiar with the domain and the problem space so they can make informed decisions on how to proceed. And in my experience it's easier and less costly to evolve (or replace) something that's dead simple and wrong than to iterate on something very complex and sort-of right.

Attempting to anticipate requirements at the outset is always a gamble. If you get it exactly right then you can save months of development time. However, if you get it wrong, even a little bit, then you may find yourself saddled with a not-quite-right solution requiring compromises with every enhancement request. I think part of "slow" (let's say "deliberate") software development is the willingness to put up a straw man for the purposes of getting feedback from the stakeholder and then going back to the drawing board with information gained to build a more appropriate solution.

And that's what agile is about--timely feedback and course correction. If in the span of a sprint a team can get a hard-coded form out and learn all of the reasons it isn't a viable solution, then that's valuable information gained at relatively low cost. The alternative, investing many sprints in a more complex solution, may (and often will) yield more technical debt and cost, especially in the long term.

That being said, once the project takes form and everyone has a good handle on what the needs are, there is definitely value in shifting priorities from features to design. At that point the insights gained from stakeholder feedback will ensure that the system can be as simple as possible, but no simpler, i.e. easy to understand and test while being abstract and extensible (only) where needed.

I agree with you to a point. I am a touch typist. There's something to be said about a lack of friction.

However, at the same time, there is also something to be said for friction and learning to work with friction. It is about time and the amount of deliberation the concentration of holding a thought in your mind for longer.

I am a touch typist and I appreciate that I am. However, I also find that spending some time periodically with a quill pen, writing thoughts down with that, is extremely valuable for the opposite reason.

One of the core challenges is how to slow down thought. This is something which has many, many benefits, and touch typing at the speed of thought would not be conducive to quality code.