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.
Measure once, cut twice, earn one to throw away.
Speed matters: Why working quickly is more important than it seems (2015)
41–50 of 177 posts
Re: Speed matters: Why working quickly is more important than it seems (2015)
#42Oh please. Our whole product is a side effect of "working quickly", and it's anyone's guess how difficult it is to make any change in that now.
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.
Yeah the farther I have gotten in my career, the more I ascribe to a disposable code philosophy. Of course it doesn't mean that it's a balance, and there's a time and a place for structure and thinking about design, but that is almost always done better when you have a working prototype than when you're starting something from scratch.
Re: Speed matters: Why working quickly is more important than it seems (2015)
#43This 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.
Re: Speed matters: Why working quickly is more important than it seems (2015)
#44Work 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.
Measure once, cut twice, earn one to throw away.
This is a bad analogy for software. One of the unique properties of software, compared to other crafts, is that the material cost of iteration is virtually zero. We should use that to our advantage instead of pretending we're carpenters.
Re: Speed matters: Why working quickly is more important than it seems (2015)
#45Earlier quoted context omitted.
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.
Rarely if ever in the beginning of the project it's 100% sure or guaranteed how long the project will be maintained. There might be some estimates, but in the long run upper management might change their minds at any time and then you are fucked if you didn't build robust architecture from the start. At least according to my experience and everyone I know in the industry.
If you work on legacy code you can be sure that your code will be used for years if not decades.
Re: Speed matters: Why working quickly is more important than it seems (2015)
#46Efficiency 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 sh…
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.
Re: Speed matters: Why working quickly is more important than it seems (2015)
#47Earlier quoted context omitted.
Rarely if ever in the beginning of the project it's 100% sure or guaranteed how long the project will be maintained. There might be some estimates, but in the long run upper management might change their minds at any time and then you are fucked if you didn't build robust architecture from the start. At least according to my experience and everyone I know in the industry.
But there are so many counterexamples to that too. I worked on a project following CI practices with a release every two weeks, and I can think of plenty of examples where we developed a feature, tested it with users, and scrapped it within a month. That team leaned toward strict practices, and we wasted so much time on code review and documentation of small details which only existed for a couple of weeks. I also th…
The question is, if the project you worked would be a mess from the beginning, would it allow your company to test and scrap features fast?
Yes, it's possible, but at what cost? E.g. long hours, unhappy devs, implementation taking too long.
Re: Speed matters: Why working quickly is more important than it seems (2015)
#48That's why the thing about "premature optimisation is the root of all evil" is mistaken and wrong in these modern times and yet many people still quote it and take it to heart and as a result don't prioritise speed when building software. "premature optimisation is the root of all evil" is a saying that came from 1974 when computers were slower, languages were less effective and development processes immature. Today…
You didn’t read the post, did you?
Re: Speed matters: Why working quickly is more important than it seems (2015)
#49Work 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.
Not ideal, but mistakes and experiments seem to be the best way people learn.
There's nothing wrong with making mistakes in experiments. However, when you're building financial systems, there's absolutely no room for mistakes.
Re: Speed matters: Why working quickly is more important than it seems (2015)
#50Earlier quoted context omitted.
But there are so many counterexamples to that too. I worked on a project following CI practices with a release every two weeks, and I can think of plenty of examples where we developed a feature, tested it with users, and scrapped it within a month. That team leaned toward strict practices, and we wasted so much time on code review and documentation of small details which only existed for a couple of weeks. I also th…
The question is, if the project you worked would be a mess from the beginning, would it allow your company to test and scrap features fast? Yes, it's possible, but at what cost? E.g. long hours, unhappy devs, implementation taking too long.
The point is there's a balance. I think it's perfectly reasonable to allow a certain amount of technical debt to accrue, especially when prototyping new features, and treat it as a priority to clear this debt by the time said features become a dependency to other parts of the project.
It takes a bit more nuance to get a team to work that way rather than just enforcing Best Practice(tm) always, but in my experience it can be much more productive overall.