I love this presentation because it adds strong economic arguments to a lot of practices that are quite common in software engineering but typically lack good argumentation as to why they are good.
He covers a lot more ground in this presentation. Well worth your time if you are involved in any way in planning software development. I love his notions of option value and cost of delay. Cost of delay is exactly the economic argument why working quickly is important. Once you get it, is obvious that you should do agile, release early, and avoid embarking on long/uncertain refactoring/redesign efforts unless you can justify the payoff.
In short, any development that ships early maximizes the useful economic life on the market. If you ship something new earlier than your competitors, you get to charge a premium until they catch up. At some point your new thing becomes a commonality and the value drops. In some case, OSS just gobbles it up and the value becomes 0$.
So shipping 3 months earlier means you get to earn revenue for 3 months extra when it is still most lucrative. If you instead delay for 3 months because you are doing some thing that make things better in some way, you have to consider the cost of doing that AND the cost of missing out on that early revenue.
Don Reinertsen suggests you simply do the math consider the cost of delay when e.g. deciding on a big refactor vs. a lets get this to market ASAP type strategy. You don't even have to do a particularly good job at doing the math to out-compete gut feelings here.
Efficiency is also more important than it seems. You can have lots of low quality, half-baked output. How much forethought do we put into what we will work on to begin with? Some projects and ideas are not worth the effort. Or an alternative solution to a problem is preferable over one you’ve been hammering away at for days, and would be easier to implement.
And in the realm of programming, it’s often easy to take shortcuts even though later on they wind up costing more time for you or others involved: omitting documentation, not making something reproducible, poor code quality, etc.
Having spent most of my career in academia I see a lot of the work makes this trade off: efficiency is sacrificed for a sloppy, immediate “speedy” solution. You need to find a balance and think through problems, considering not only what is immediately in front of you but also what you’ll be doing in a month or year. Otherwise you’ll wind up with a project or codebase that begins to drag your productivity and output with it.
Not every product is maintained for years. In many cases it's good to be able to choose between a quick solution and a good solution, as long as these are concious decisions and some record of accrued technical debt is kept.
There is also a possibility that your predictions about the future turn out to be wrong.
It's definitely a balancing act.
One extreme is always going for the instant gratification, paying no attention to how things fit into the overall design.
The other extreme is trying to design everything up front with no feedback and getting more and more divorced from the practical reality as time without implementation goes on.
When I feel progress goes slow, or a task is too hard, I will use test driven development: Just implement the bare minimum in order to make the test pass, basically dividing the task up into many small steps.
When I do dev stuff with a slight sense of urgency, the probability of my mind wandering somewhere else goes down drastically.
At this mode, my mind uses all available time slots to make the best of them. For example, by the time my program compiles, my brain visualizes possible breakage scenarios and possible solutions, in case the compilation fails.
I could be on confirmation bias here, but this seems to be a neat trick to get more things done.
For me, after years producing software, I've set myself up to be able to say no.
I disregard urgency when it exists for urgency's sake, coming out of business despair or a gut feeling. I will gladly work for 2 - 3 months on hyper mode, giving away my mental and physical health for a feature that will actually provide business value and for which the business can make a good case for why it's needed yesterday.
Working with multiple companies on executive and / or consulting levels, I feel like a lot of business rush is done because business 'needs it now' in the hope that it will improve the bottom line because it's easier to expect a miracle than it is to take a good look at your fundamentals.
The businesses with the most solid foundation I find are the ones that rarely need to rely on speed and instead rely on quality and produced value... once in awhile, a feature idea comes up that can propel the company - especially in the face of competitors - and it needs to be done as fast so that the producer can get as much value out of it before the competition catches up. That's a good reason to expect speed.
Today's society expects hyper growth, hyper speed, hyper scale, but that is because this is what is mostly advertised and we as humans have a tendency to expect the world to work as is advertised, when in reality, there are a lot of smaller companies that don't create anxiety filled working days for their employees.
>I will gladly work for 2 - 3 months on hyper mode, giving away my mental and physical health for a feature that will actually provide business value and for which the business can make a good case for why it's needed yesterday.
I feel sorry for you.
As some who's been around the block a few times, I will never, EVER, give away my mental or physical health for someone's business.
My health is more important than their quarterly targets.
ThalesX, your comment here is better than the linked article. Well said.
Looking back over the years of software development I've been involved in (jeez, 27) and remembering the things that were developed with all haste, not one of them, not a single one, met with success. There were some that were developed quickly, usually to meet contractual deadlines, that were good and gave the customer what they needed, but even then, if they could have just waited one more month, I think they would have gotten something better and been more successful.
> I will gladly work for 2 - 3 months on hyper mode, giving away my mental and physical health for a feature that will actually provide business value and for which the business can make a good case for why it's needed yesterday.
I felt the same way until I caused permanent damage to my eyesight from stress. It isn't worth it.
That might be a really good idea. Over the years I've tried multiple website blockers, but I keep turning them off (no judgment please...).
Artificially slowing down those time waster websites instead might do the trick. Not so slow it becomes unusable (or I'll turn it off) , but slow enough that over time I start associating it with a bad experience.
I’ve seen this used to good effect with coworkers that habitually ask for help before trying to solve the problem themselves. Instead of ignoring them or complaining that they’re wasting your time, wait to respond for a few minutes so that you’re no longer faster than looking the information up for themselves.
Obviously this only works over some kind of messaging service; face-to-face conversations have significantly different expectations around long pauses.
They both have the habit of very frequently interrupting me to ask me questions they either know or can find the answer to easily, or asking me to do things they can do for themselves.
I try to avoid just giving a blunt "no" because I'm also trying to instill in them the idea that family is about helping each other. So I try to say, "Yes, but I'm in the middle of ___. Give me a few minutes then I'll help you."
More often than not, as if by magic, it turns out they have the capacity to do it themselves all of a sudden.
I really like this idea of a Chrome extension that makes every load on Twitter/Facebook/Hacker News/[your vice goes here] just take something like 0.5s longer. If no one else builds this, I think I will at some point.
My data plan goes to 3g (feels like 2g) speeds when my data runs out. Its actually awesome, I still get email etc, but browsing crappy content becomes really slow so I avoid it. I wish you could buy cheap 3g only plans
I don't know if that's why, but HN is usually way faster than the linked sites, and I more often than not end up browsing the comments instead of the intended content.
This is one of my favorite blog posts of all time. It's applicable not only to just work work but a lot of other things, if you can shorten the feedback loop, you get a much better chance to improve the end result. It affects _everything_ else too.
You make a good point. How do you compare your idea to the one that we need to take time to smell the rose? I think that idea suggests that we need to slow down and watch the world more closely. Just wanted to know what you think of that.
A counterintuitive thing I've discovered us that working fast let's you solve more complex problems. At first it seems that you should try to go slow to make sure that all the cases are properly treated. Proceeding this way can result in nearly endless refinements as you go and losing sight of the main goals from time to time and repeatedly forgetting exactly where you are in the grand plan and which direction/step you were headed.
Going fast doesn't allow for secondary concerns and produces a single simple solution. Of course you can now do everything else it needs that you think of but code written this way with a clear core path is so refreshing from bottom-up generation where every detail has equal importance.
I even recall a time where I was performing a cascade of rebases and merges across three git branches and 4 or more submodule branches. Each feature update/sync took so many tries to get right. I eventually got fed up and just brute-powered through it without prethinking it. Because it was a short time from start to finish I was able to clearly see each commit in each tree I was working on without a pause wondering where I was or doing next. It was also less error prone than going slow. It fact I just did the whole process twice in a fraction of the careful time and compared results. No diffs were taken as correct and any diffs were examined and the correct variant used.
Going fast doesn't allow for secondary concerns and produces a single simple solution.
That doesn't sound like going fast, so much as "the simplest thing that could possibly work." Once you have that running, you can see where the shortcomings are and start to fix those. That will often proceed faster than trying to envision the whole complex thing up-front. (And that often results in a complete, but illusory vision, which ignores something which only becomes apparent once it's realized.)
Actually this is great advice, I should do it more. I already found it was great writing essays back in school - instead of painfully trying to be perfect, just knocking something out becomes a first draft. Same with getting kids to tidy the room, making it a fun race instead of slowly considering each piece gets chores done more quickly.
Work fast, don't think things through, make mistakes, pay for your haste by spending more time fixing your mistakes than you would have had you thought things through.
You can definitely go the other way to overthink a problem, even as high to induce the halting problem. Absolute optimization is mathematically impossible, and an imperfect choice has to be made at some point.
> But it does mean, push yourself to go faster than you think is healthy
I really disagree with this. Aiming for something you actually think is unhealthy means you either think you should be working unhealthily ( :( ) or you don't trust your measure of healthy (in which case recalibrate that).
Speed derived from managing scope is the real value IMO. It's not about working faster, but rather minimizing scope constantly to ship faster and collect feedback.
My view is that all programmers produce roughly the same amount of bugs per hour, it is just the bugs per feature which differ. Of course bad programmers can spend a lot of time fixing bugs as they go making the end result have few bugs, but still the main time-sink is fixing all of those bugs.
So to become fast, learn to write code which is very easy to verify that it works. If you get surprised when things work the first time you try then you are not fast.
Meanwhile there are martial arts and other physical disciplines where you go slowly to make sure you train the muscles along the entire movement instead of going in jerks and starts (which is how you damage yourself).
Fast iteration isn't about doing things faster. It's about requesting feedback more frequently. Which often means doing less, not more, and then evaluating the effectiveness of that small amount of work. Then adjusting your plans.
In writing, doing an entire book before your editor can tell you you're accidentally stealing a storyline from another author is bad. His analogies seem to be equating to this sort of behavior but missing the cause.
I have a different experience. I did lots of well thought work, that after management decision ended in the thrash. I prefer “working quickly” now, if it doesn’t end in the thrash, I can fix it later.
> I’ve noticed that if I respond to people’s emails quickly, they send me more emails
And I thought they wanted argue for faster replies...
But I think there is some truth to that. If a task seems overwhelming, it can sometimes help to look back at something you already completed.
I don't have that impression for programming at work, since I have a set schedule anyway, but for projects outside of that the kick-off seems to be the hardest part in awe of all the work before you. But then there is all the projects you already completed, which were mostly labor intensive as well.
For anybody reading the comments here without reading the article, and assuming some toxic-management-friendly nudge to burn-out style working (as implied by some of the comments); it's actually a very useful and thought-provoking self-help essay that may help as a tool against procrastination.
"when you punch someone you need to pull your arm back, before you launch it forward. If you don’t your hit will be weak."
It's a cute way to think in opposites, but unfortunately as punching advice, it's untrue. Punch force comes from body mass x acceleration, not arm mass x acceleration.
40 year old here. Speed doesn't matter as much as WHAT you deliver. First of all, people do not know how much time something takes. And secondly, they will forget how much time it took, but not how well it was made.
Responding fast to emails is just crazy. I lost count on how many urgent problems got resolved automatically. "Hey can you help me with this". 15 minutes later "Nevermind, found it".
> And secondly, they will forget how much time it took, but not how well it was made.
Absolutely. Not saying speed is never an important metric, but virtually all complicated engineering and construction projects are difficult to schedule and exceed their time budgets. If the end result is worth it those birthing pains are quickly forgotten. But a poor output will never be forgotten.
Another 40 year old here: I mostly agree and I've also found that thinking deeply about a problem for a long time before trying to build anything pays huge dividends. In particular I spend a long time thinking about how I can simplify the design to save implementation time, which means actually building it is faster. I also think a lot about UX and DX: simplifying installation, interface, maintenance, removing unnecessary knobs, choosing the right algorithms and tooling, etc.
I think waterfall style development works for one person inside one's own mind, but not beyond that.
A lot of the stuff I see from 20 year olds these days is monstrously over-engineered and Rube-goldberg like. Many keystrokes, sure, but less thought. This also yields bloatware that hogs resources and is hard to install and maintain.
Seems to me, that the recent spate of online coding interview techniques are basically looking for people who type fast. I suspect that they're finding people who are actually "10X" coders, and people who have memorized the typing out of the solution.
(EDIT: A problem with such 3rd party companies, is that the incentives are subtly misaligned, as they are for any recruiter. If they can present a good image, and a steady stream of candidates who produce videos where they're going claka-claka-claka on the keyboard at a good clip, like a hollywood hacker (which runs and compiles) then they're golden. It doesn't matter to them, if they're missing out on good, thoughtful candidates. False negatives are the order of the day.)
This post wasn't written for people who don't suffer from procrastination and perfectionism. As I sit here being anxious about what to work on next, holding onto tasks that aren't quite done YET, nothing could feel more like a breath of fresh air than this blog post.
This sounds like people who quote "slow in, fast out" in racing. Just like here it's not true. It's a "rule of thumb" for beginners. It has use in that context. The way to win a race is fast in, fast out, same with software.
Delivering something after it is needed is useless. Chronically delivering things the day after requirements change due to the world turning, is uselees.
Musicians and other technical performers practice both slow&carefully and quickly, so that over time they can be more correct and more quick (as quick as the task can appreciate)
> That doesn’t mean be sloppy. But it does mean, push yourself to go faster than you think is healthy. That’s because the task will come to cost less in your mind; it’ll have a lower activation energy. So you’ll do it more. And as you do it more (as long as you’re doing it deliberately), you’ll get better. Eventually you’ll be both fast and good.
Speed matters in other fields as well. I'm a former academic surgeon, now in semi private practice.
I would a always tell my residents that to start a medical practice, the 3 "A"s are important, and in this order. Availability, affabilty, and then ability.
People have a problem, and they want it taken care of. If you can be that guy, or company, that's there for them, then you'll get there business in the future, as long as you do a good job.
[+] [-] jillesvangurp|6 years ago|reply
I love this presentation because it adds strong economic arguments to a lot of practices that are quite common in software engineering but typically lack good argumentation as to why they are good. He covers a lot more ground in this presentation. Well worth your time if you are involved in any way in planning software development. I love his notions of option value and cost of delay. Cost of delay is exactly the economic argument why working quickly is important. Once you get it, is obvious that you should do agile, release early, and avoid embarking on long/uncertain refactoring/redesign efforts unless you can justify the payoff.
In short, any development that ships early maximizes the useful economic life on the market. If you ship something new earlier than your competitors, you get to charge a premium until they catch up. At some point your new thing becomes a commonality and the value drops. In some case, OSS just gobbles it up and the value becomes 0$.
So shipping 3 months earlier means you get to earn revenue for 3 months extra when it is still most lucrative. If you instead delay for 3 months because you are doing some thing that make things better in some way, you have to consider the cost of doing that AND the cost of missing out on that early revenue.
Don Reinertsen suggests you simply do the math consider the cost of delay when e.g. deciding on a big refactor vs. a lets get this to market ASAP type strategy. You don't even have to do a particularly good job at doing the math to out-compete gut feelings here.
[+] [-] danielecook|6 years ago|reply
And in the realm of programming, it’s often easy to take shortcuts even though later on they wind up costing more time for you or others involved: omitting documentation, not making something reproducible, poor code quality, etc.
Having spent most of my career in academia I see a lot of the work makes this trade off: efficiency is sacrificed for a sloppy, immediate “speedy” solution. You need to find a balance and think through problems, considering not only what is immediately in front of you but also what you’ll be doing in a month or year. Otherwise you’ll wind up with a project or codebase that begins to drag your productivity and output with it.
[+] [-] sejtnjir|6 years ago|reply
[+] [-] realharo|6 years ago|reply
It's definitely a balancing act.
One extreme is always going for the instant gratification, paying no attention to how things fit into the overall design.
The other extreme is trying to design everything up front with no feedback and getting more and more divorced from the practical reality as time without implementation goes on.
[+] [-] z3t4|6 years ago|reply
[+] [-] lewisjoe|6 years ago|reply
At this mode, my mind uses all available time slots to make the best of them. For example, by the time my program compiles, my brain visualizes possible breakage scenarios and possible solutions, in case the compilation fails.
I could be on confirmation bias here, but this seems to be a neat trick to get more things done.
[+] [-] ThalesX|6 years ago|reply
I disregard urgency when it exists for urgency's sake, coming out of business despair or a gut feeling. I will gladly work for 2 - 3 months on hyper mode, giving away my mental and physical health for a feature that will actually provide business value and for which the business can make a good case for why it's needed yesterday.
Working with multiple companies on executive and / or consulting levels, I feel like a lot of business rush is done because business 'needs it now' in the hope that it will improve the bottom line because it's easier to expect a miracle than it is to take a good look at your fundamentals.
The businesses with the most solid foundation I find are the ones that rarely need to rely on speed and instead rely on quality and produced value... once in awhile, a feature idea comes up that can propel the company - especially in the face of competitors - and it needs to be done as fast so that the producer can get as much value out of it before the competition catches up. That's a good reason to expect speed.
Today's society expects hyper growth, hyper speed, hyper scale, but that is because this is what is mostly advertised and we as humans have a tendency to expect the world to work as is advertised, when in reality, there are a lot of smaller companies that don't create anxiety filled working days for their employees.
[+] [-] ChuckNorris89|6 years ago|reply
I feel sorry for you.
As some who's been around the block a few times, I will never, EVER, give away my mental or physical health for someone's business.
My health is more important than their quarterly targets.
[+] [-] redleggedfrog|6 years ago|reply
Looking back over the years of software development I've been involved in (jeez, 27) and remembering the things that were developed with all haste, not one of them, not a single one, met with success. There were some that were developed quickly, usually to meet contractual deadlines, that were good and gave the customer what they needed, but even then, if they could have just waited one more month, I think they would have gotten something better and been more successful.
[+] [-] bg4|6 years ago|reply
I felt the same way until I caused permanent damage to my eyesight from stress. It isn't worth it.
[+] [-] skybrian|6 years ago|reply
This seems like a good idea for a browser extension. Maybe sometimes you want to undo the work that the website did making things go faster?
[+] [-] monsieurbanana|6 years ago|reply
Artificially slowing down those time waster websites instead might do the trick. Not so slow it becomes unusable (or I'll turn it off) , but slow enough that over time I start associating it with a bad experience.
[+] [-] kd5bjo|6 years ago|reply
Obviously this only works over some kind of messaging service; face-to-face conversations have significantly different expectations around long pauses.
[+] [-] munificent|6 years ago|reply
They both have the habit of very frequently interrupting me to ask me questions they either know or can find the answer to easily, or asking me to do things they can do for themselves.
I try to avoid just giving a blunt "no" because I'm also trying to instill in them the idea that family is about helping each other. So I try to say, "Yes, but I'm in the middle of ___. Give me a few minutes then I'll help you."
More often than not, as if by magic, it turns out they have the capacity to do it themselves all of a sudden.
[+] [-] jordn|6 years ago|reply
[+] [-] rb808|6 years ago|reply
[+] [-] jmartinpetersen|6 years ago|reply
[+] [-] _____s|6 years ago|reply
[+] [-] hi41|6 years ago|reply
[+] [-] karmakaze|6 years ago|reply
Going fast doesn't allow for secondary concerns and produces a single simple solution. Of course you can now do everything else it needs that you think of but code written this way with a clear core path is so refreshing from bottom-up generation where every detail has equal importance.
I even recall a time where I was performing a cascade of rebases and merges across three git branches and 4 or more submodule branches. Each feature update/sync took so many tries to get right. I eventually got fed up and just brute-powered through it without prethinking it. Because it was a short time from start to finish I was able to clearly see each commit in each tree I was working on without a pause wondering where I was or doing next. It was also less error prone than going slow. It fact I just did the whole process twice in a fraction of the careful time and compared results. No diffs were taken as correct and any diffs were examined and the correct variant used.
[+] [-] stcredzero|6 years ago|reply
That doesn't sound like going fast, so much as "the simplest thing that could possibly work." Once you have that running, you can see where the shortcomings are and start to fix those. That will often proceed faster than trying to envision the whole complex thing up-front. (And that often results in a complete, but illusory vision, which ignores something which only becomes apparent once it's realized.)
[+] [-] rb808|6 years ago|reply
[+] [-] alimbada|6 years ago|reply
[+] [-] Nyandalized|6 years ago|reply
[+] [-] avip|6 years ago|reply
[+] [-] IanCal|6 years ago|reply
I really disagree with this. Aiming for something you actually think is unhealthy means you either think you should be working unhealthily ( :( ) or you don't trust your measure of healthy (in which case recalibrate that).
[+] [-] munificent|6 years ago|reply
[+] [-] mnort9|6 years ago|reply
[+] [-] dang|6 years ago|reply
[+] [-] username90|6 years ago|reply
So to become fast, learn to write code which is very easy to verify that it works. If you get surprised when things work the first time you try then you are not fast.
[+] [-] hinkley|6 years ago|reply
Fast iteration isn't about doing things faster. It's about requesting feedback more frequently. Which often means doing less, not more, and then evaluating the effectiveness of that small amount of work. Then adjusting your plans.
In writing, doing an entire book before your editor can tell you you're accidentally stealing a storyline from another author is bad. His analogies seem to be equating to this sort of behavior but missing the cause.
[+] [-] piyush_soni|6 years ago|reply
[+] [-] lnsru|6 years ago|reply
[+] [-] raxxorrax|6 years ago|reply
And I thought they wanted argue for faster replies...
But I think there is some truth to that. If a task seems overwhelming, it can sometimes help to look back at something you already completed.
I don't have that impression for programming at work, since I have a set schedule anyway, but for projects outside of that the kick-off seems to be the hardest part in awe of all the work before you. But then there is all the projects you already completed, which were mostly labor intensive as well.
[+] [-] mellosouls|6 years ago|reply
[+] [-] kstenerud|6 years ago|reply
It's a cute way to think in opposites, but unfortunately as punching advice, it's untrue. Punch force comes from body mass x acceleration, not arm mass x acceleration.
[+] [-] koonsolo|6 years ago|reply
Responding fast to emails is just crazy. I lost count on how many urgent problems got resolved automatically. "Hey can you help me with this". 15 minutes later "Nevermind, found it".
I'm in the "Slow is smooth, smooth is fast" camp. https://www.lesswrong.com/posts/4FZfzqMtwQZES3eqN/slow-is-sm...
[+] [-] markbnj|6 years ago|reply
Absolutely. Not saying speed is never an important metric, but virtually all complicated engineering and construction projects are difficult to schedule and exceed their time budgets. If the end result is worth it those birthing pains are quickly forgotten. But a poor output will never be forgotten.
[+] [-] api|6 years ago|reply
I think waterfall style development works for one person inside one's own mind, but not beyond that.
A lot of the stuff I see from 20 year olds these days is monstrously over-engineered and Rube-goldberg like. Many keystrokes, sure, but less thought. This also yields bloatware that hogs resources and is hard to install and maintain.
http://www.ariel.com.au/jokes/The_Evolution_of_a_Programmer....
More thought and less typing young padawan.
[+] [-] stcredzero|6 years ago|reply
Seems to me, that the recent spate of online coding interview techniques are basically looking for people who type fast. I suspect that they're finding people who are actually "10X" coders, and people who have memorized the typing out of the solution.
(EDIT: A problem with such 3rd party companies, is that the incentives are subtly misaligned, as they are for any recruiter. If they can present a good image, and a steady stream of candidates who produce videos where they're going claka-claka-claka on the keyboard at a good clip, like a hollywood hacker (which runs and compiles) then they're golden. It doesn't matter to them, if they're missing out on good, thoughtful candidates. False negatives are the order of the day.)
[+] [-] rconti|6 years ago|reply
[+] [-] erik_landerholm|6 years ago|reply
edit: I'm 42, if the matters.
[+] [-] papln|6 years ago|reply
"A stitch in time saves nine."
"Haste makes waste."
Speed helps you deliver more.
Delivering something after it is needed is useless. Chronically delivering things the day after requirements change due to the world turning, is uselees.
Musicians and other technical performers practice both slow&carefully and quickly, so that over time they can be more correct and more quick (as quick as the task can appreciate)
> That doesn’t mean be sloppy. But it does mean, push yourself to go faster than you think is healthy. That’s because the task will come to cost less in your mind; it’ll have a lower activation energy. So you’ll do it more. And as you do it more (as long as you’re doing it deliberately), you’ll get better. Eventually you’ll be both fast and good.
[+] [-] pjmlp|6 years ago|reply
Fully agree, including some of the sibling comments.
[+] [-] _bspline|6 years ago|reply
[+] [-] spineboy|6 years ago|reply
I would a always tell my residents that to start a medical practice, the 3 "A"s are important, and in this order. Availability, affabilty, and then ability.
People have a problem, and they want it taken care of. If you can be that guy, or company, that's there for them, then you'll get there business in the future, as long as you do a good job.