Speed matters: Why working quickly is more important than it seems

* Typing on a keyboard

* Sharpening a knife

* Driving a car.

It seems more like a question of doing things a lot and very focused, than focusing on speed initially.

I feel like when you focus on speed you very quickly learn just enough to get the task done quickly. And then your progress stalls.

-=in defence of taking your sweet time=-

the arguments for speed and the arguments for quality are not either or. they both contribute to a product that works.

to introduce the case for slowness a natural precedent is appropriate. the development phase for human beings was on the order of 2 billion years.

and in that time a whole lot of nothing happened. all those evolutionary competitors at every level of the tree of life were more rapidly produced than humans. and now humans rule the world and in 200000 years have used that comprehensive development period to move rapidly and adapt so effectively to the world that we have changed it to support 7 billion of us and tripled our life spans. the hockey stick curve of our technology speaks to the benefits of long development, and the long tail of non-adaptive more-rapidly developed ideas that come to nought.

those practising rapid development and launch save costs during the development stage and increase costs during the much longer operating stage by code that has more bugs, takes more to maintain, is more brittle, and these things constribute to being slower to adapt to customers and competitors when it counts, that is, when you have customers, are burning operating costs, and competing.

it works better to develop comprehensively when it is cheap to and build the most efficient product to be really useful when you run with it. longer development, then move faster in operations.

otherwise you end up solving your terrible code base by hiring more brains, and those brains could be better put to use creating improvements for your customers and not fixing the consequences you shipped in a sprint.

pre launch development is cheap, so it works to take your time and not optimize that __process__ prematurely. everything is more expensive after launch when the stakes are real and where an advantage can be moving fast -- if the code you crafted creates that you can adapt quickly, then you've minimized costs over the operating period, and your brains can work on growing and retaining, rather than building an ozymandius of monkey patches.

the time when speed is important is after launch not before it. if you rush your pre launch development, you will be a slow operator, and this will cost you exponentially more than the linear increase in cost from a longer development time.

also the more robust the system you build is, the slower ( as in slow thinking ) you can create your decisions in the operating period to really consider strategy.

let your competitors ship first and watch the things they miss. let them pay for the experiments you now decline to run. if someone seems to be capturing the market through their business model then you are too slow anyway and the high order bit for you isn't code anymore. if that is not your market, then it is filled with competitors who are mimicing each others sub-monopoly strategies. so you can step in, be the last mover, and take the market. invest time during development to make code and tools that work, grasp your business plan, and have the possibility of thinking strategically about the business, in the operation phase, once you have launched.