6 ms·

Algorithms We Develop Software By

269 points by ksec 2y ago

lunarcave 2y ago
Although I disagree with the arbitrary limit of “one day per feature”, I agree with the broader point that useful constrains drive creativity.
082349872349872 2y ago
The generalisation I would make is: if you think, not just of a specific solution, but of the space of possible solutions, it makes it easier to find a point in that space which best "fits" (space, time, architecture) the program you're working on. Rather than trying paths in the dark, first look at a map, then try a few paths.
MillironX 2y ago
I fundamentally disagree with the "gun to the head" strategy. One of the major projects I worked on was a virus genome analysis pipeline. Our initial funding was for single-segment virus analysis, but about a year into the project, our grant collaborators needed to demonstrate multi-segment virus support within two weeks. My PI and I agreed on a quick and dirty method that would produce the analyses needed and could be done in the allotted time. That piece of code was fundamental to how the whole pipeline worked, however, and so as the pipeline grew, it took on the shape of the "gun to the head" decision we had made to the point where other, more essential features of the pipeline had to be delayed so I could come up with more workarounds. There were clearly other issues at play here (scope creep and lack of separation of concerns were huge). My time at the lab came to a close, but if I were to have a chance to continue that project, I would start over from scratch rather than deal with the baggage that that one "gun to the head" moment created. I understand that it's a heuristic and not meant to be taken as 100% truth for every situation. I also understand that it's trying to avoid that "paralysis by analysis" that's so easy to fall into. I just question how useful it truly is as a heuristic, especially since it seems to go against the "write everything twice" algorithms presented in the rest of the piece.
- tikhonj 2y ago
  I'd say it goes with the "write everything twice" heuristic! If you're in an environment where you can write things twice—you have trust and autonomy and aren't encumbered by process—then writing an initial version as fast as possible gets you started faster, lets you play with something concrete and leaves you more room for your second version. My best projects were like that. I'd figure out something quick—some combination of reducing scope and doing "things that don't scale"—then spend time refining the conceptual design and interfaces, and finally rewrite the initial piece based on that new design. This can absolutely work better than just trying to write something "good" the first time around, but it looks wasteful to somebody superficially tracking individual "tasks" you're working on.
- qsort 2y ago
  > I just question how useful it truly is as a heuristic I think the author is presenting them as analytical tools that might or might not be useful depending on the situation. Very often when faced with a difficult problem it's hard to know where to start attacking. Any idea, even if simplistic and wrong, can be useful to start gaining insight on what is going to work and why; even just refuting the original idea with a clear counterargument might suggest alternative avenues. OT: this is IMO part of the reason why people like LLMs so much. Maybe the answer is trash, but articulating why it's trash gets you unstuck.
- MajimasEyepatch 2y ago
  As the saying goes, there's nothing more permanent than a temporary solution. If you're going to do this, you either have to explicitly plan for the cost of the rewrite to do it the "right" way after doing it the "wrong" way, or you have to accept that you're probably not going to revisit the "temporary" solution for a long time.
neilv 2y ago
These are useful mental tools, to have in your mental toolbox, and apply them as they seem appropriate, but don't make a religion of any of them. A related old idea about writing/reworking software three times: "Do it. Do it right. Do it fast." Startups provide ample opportunities to get experience with what the article calls "gun to your head heuristic". You have to decide what and how to compromise. And, if you want your startup to be successful (not just hit your metrics/appearances, and then job hop), you can't just do it like school homework (where the only goal is to slip something past a grader, and forget about it), but you have to creatively come up with a holistically good compromise solution, given all the factors. If you do this well, it's creative magic that can't be taught, but can be learned, through experience and will.
- n4r9 2y ago
  > A related old idea about writing/reworking software three times: "Do it. Do it right. Do it fast." The version I've heard is "Make it correct. Make it readable. Make it performant."
  - rokob 2y ago
    These are all variants of Kent Beck’s saying: “Make it work, make it right, make it fast.” https://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast https://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast
    - boguscoder 2y ago
      And this is not about writing anything thrice at all, it’s about picking right priorities/order
mattlondon 2y ago
Gun to the head solutions: no tests, no quality, no future planning, hacks on top of hacks, tech debt. As a manager, this "thought exercise" is dangerous. You think it is a fun and harmless exercise to your reports to really focus, your reports at best think you don't trust them, and at worst think you are threatening them with violence (hypothetical or otherwise) unless they tell you what they think you want them to say. Psychology safety will be at rock bottom pretty quickly. Nice job you have there, would be a reaaaaalll shame if anything hypothetical happened to it huh? Now estimate again, and this time don't make me angry <imitates pulling a trigger of an invisible gun at someone's head>. Absolutely terrible behaviour.
- me-vs-cat 2y ago
  He does need a better name. > The purpose of the thought experiment isn't to generate the real solution. It's meant to put a lower bound on the solution. Then you think of a real solution with that lower bound in eyesight, and you'll find it's often better than your original solution. He does not say to actually implement the quickest hack you can imagine, nor to skip the mundane steps that avoid tech debt. He says spend 10 minutes imagining a quick hack after laying out your initial solution, and incorporate anything you learned into your actual work. To me, it sounds very similar to a startup chipping away at their original idea to get a MVP. > The purpose here is to break their frame and their anchoring bias. If you've just said something will take a month, doing it in a day must require a radically different solution.
kvemkon 2y ago
Previous discussion: Algorithms we develop software by (18.08.2024) https://news.ycombinator.com/item?id=41284409 https://news.ycombinator.com/item?id=41284409
ww520 2y ago
For "write everything twice" I would say write some parts many times. You don't have to write everything twice. Most code are optimal or good enough already, but you should be willing to re-write some parts over and over again.
w10-1 2y ago
People learn to work better by reflecting on work. So any framework for self-observation is better than none. I suspect that algorithms as a framework demonstrates the structural aspects (e.g., how some searches are more extensive), but might hide the driving factors. Indeed, the article examples were almost all hacking personality, not technical or process solutions. E.g., most over-engineered solutions are driven by fear, often itself driven by critical or competitive environments. Conversely, much of the power of senior/staff engineers comes from the license to cut corners afforded their experience. Or people use the tools they know. You can't get to great by holding onto good. It's easy to go from bad to good, but takes some courage to toss good to start over for great. The lesson there is that we stand (hide?) behind our work, and we need to let go of it to improve it. A meta-lesson is that managers need to deeply understand personal space of each developer and the social dynamics of the team before they can do their job effectively, and a key part of that is likely checking in with developers in a way that enhances their courage and self-observation instead of making them fearful and paranoid.
- trhway 2y ago
  > much of the power of senior/staff engineers comes from the license to cut corners afforded their experience. Absolutely. Jira is equally slow for everyone except for the ones who are allowed to skip it. At the places where i managed to become star developer it was by hitting hard early and achieving great results, and after that you’d get a lot of slack cut for you which allows you to continue deliver at the star level with relatively light effort, and definitely much easier than say the mediocre grind i produce at the current place where “Jira” is truely slow with us.
  - shiroiushi 2y ago
    So you were a "star developer" at some previous workplaces, but now you're not, and just produce at a "mediocre grind"? Why is that? And why work there now and not that the previous places? I suspect this is the common tale of poor compensation: despite being a star developer, employers won't pay for properly for this, just a mediocre annual raise, so you move on after a couple of years to another place, which offers you a huge raise (new starting salary compared to the previous job's salary). And the new place, while giving you a poor environment that hampers your productivity, still pays much better than the previous places where your productivity was much higher. And because of this common workplace dynamic, it's usually not worth it to put in much effort to be a star employee, unless you find the rare employer that actually rewards you for it. Is my guess correct?
dakiol 2y ago
I spent 90% of the time reading and trying to understand the business logic behind the code that lies in the place that I think I need to put my feature in. So far, no methodology helps much with this part of software engineering. The remaining 10% is rather straightforward.
vtodekl 2y ago
[dead]
rcgorton 2y ago
[dead]
declan_roberts 2y ago
> A piece of advice I've given junior engineers is to write everything twice. Solve the problem. Stash your code onto a branch. Then write all the code again. I discovered this method by accident after the laptop containing a few days of work died. Rewriting the solution only took 25% the time as the initial implementation, and the result was much better. This is true, and I've discovered it myself by losing a branch. However, who the hell has time to write everything twice? There's 1,000 things waiting to be written once.
- spiffytech 2y ago
  I think the mitigating factor is "slow is smooth, smooth is fast". If you raise the quality of your codebase, you can implement those 1,000 things faster, and you reduce the odds of they'll have to be reworked.
  - animal_spirits 2y ago
    This only works if you are in charge of the timelines or have a manager who values quality over quantity
    - ajmurmann 2y ago
      And/or an organization that has the faith and politics that allow to wait till smooth starts paying back and becomes fast. Frequently you also have everyone benefiting from smoothness but not everyone contributing to it which results in the folks who pump out tickets as fast as possible looking like they are just strictly better. Easy to adapt to and game as an IC, but I find it frustrating as a manager.
      - netdevnet 2y ago
        > wait till smooth starts paying back and becomes fast By that time, you will have probably left the company and someone with less care about code quality will come and undo your work. Also, like security, it is hard to show to a manager data and graphs showing how much we are saving
OutOfHere 2y ago
It is the worst advice I have read. If the goal is to divide everything to fit in a day, it would be better to use a static analyzer to enforce certain rules.
ilidur 2y ago
Review: An anonymous "distinguished CEO and engineer" suggests if you can't complete a feature in a day, delete your progress (except for tests) and start again the next day. The author then recounts advice he gives to juniors, which is to stash the work and rewrite it, claiming that the next day the work will be rewritten in 25% of the time and 2x quality. This is unsubstantiated though. For juniors this suggests it will help them develop their capabilities to reason about implementations of problems without needing to face a a large amount of them. The author then gives another advice which is to ask for a solution to a problem then after the initial proposal, ask for a 24h solution. This is meant to generate "the real solution". He likens it the a path algorithm heuristic to reach your goal quicker. Overall the methods are not well discussed in terms of pros and cons, nor substantiated with experiments. Opinion: I think they may help some juniors who need to build up experience and may become stuck in development patterns. But they would rarely be useful to develop someone to be a senior, if all they do is chase fast implementations. In a way the post gives conflicting advice: write twice and write better, and think twice and think about the fastest way to achieve the goal, instead of engineering a problem. The author hasn't really convinced me of these approaches, and especially the last one smells of eXtreme Go Horse.
- guappa 2y ago
  Scientific approach would be to try this yourself.
  - ilidur 2y ago
    I would say that's called an anecdote.
    - arzke 2y ago
      Exactly. The "it works for me so it works" type of thinking is what makes people mistakenly conclude that homoeopathy works any better than a placebo.
      - guappa 2y ago
vincnetas 2y ago
"Gun to your head" gives you quick working solutions. But then when you avoided the headshot you run away and leave that quick-fix-mess to someone else. So this should not be a long time strategy. Sure if your runway is approaching the end, do whatever is needed to stay alive.
- phrenq 2y ago
  Generously, I think the article is presenting it as a thought experiment to make sure you’ve thoroughly explored the solution space, while not literally recommending that you necessarily implement the “gun to your head” solution.
max_ 2y ago
Is the title a play on the "Algorithms to Live By" book. Sounds clever :)
arresin 2y ago
> Start working on the feature at the beginning of the day. If you don't finish by the end of the day, delete it all and start over the next day. How experienced is this “CEO and engineer”?
- booleandilemma 2y ago
  I know, I laughed out loud and stopped reading after that sentence.
marhee 2y ago
Side note: “write everything twice” (WET) is originally meant as a reaction to DRY (“don’t repeat yourself”). I think the author uses the credo here for something else (which is still good advice).
jasfi 2y ago
If you write a design doc first, you can save yourself a lot of time. It's very quick to write a new design, and designs are also much faster to revise than code is.
wiremine 2y ago
I agree 100% with this approach, and I'd love to see some research to back it up. I think a lot of software development is "way finding" - Experimentation to figure out an architecture, an implication, a performance improvement, etc. We often don't a) call them experiments, and b) we don't constrain them well. I.e., we use the scope of the feature to bound the experiment, instead of taking a step back to figure out the right approach, we dive into implementation. I'm curious if there's a more formal way to think about this all?
anonyfox 2y ago
A thing that took me several years to agree to is that almost everything can be coded within 24 hours if really needed - gun to the head situation. Will it be perfect/efficient/beautiful/... probably not. But it should roughly work like its supposed to. If something cannot be coded within that 24 hours, something else is odd, not the feature. Transitioning from SWE to DevOps and then Leadership roles, most of my day actually is spent with all the reasons/excuses why "it cannot be done", and try to eliminate them. Probably my developers hate me for it, but I always push hard for an immediate first solution instead of doing days of soul-searching first, but over time we encounter and solve enough roadblocks (technical, social, educational, ...) that it actually happens more often than not to have surprisingly fast (and good enough) solutions. That speed is a quality in itself, since it frees up time to come back to things and clean up messes without the shipping pressure mounting up over days/weeks - something working is already there on day two. The trick is of course to _not_ sell this 24 hour solution to upper management ever, or else it will become a hell of a mess fast once this becomes the outsider expectation.
whatnotests2 2y ago
Nice play on words from Lakoff's "Metaphors We Live By"
- ayewo 2y ago
  Surprised you were the only one to pick up on the pun on the title of George Lakoff’s seminal book from 40+ years ago :)
perrygeo 2y ago
The "write it twice" strategy should be more common. The alternative is "write it once and be stuck with it". You want tech debt, cause that's how you get tech debt. By definition, the first time you do something, you will learn a ton. So you've gained two things: 1) hard-won technical knowledge and 2) a bunch of sub-optimal code written before you obtained that knowledge. The way I see it, keeping that proof-of-concept code around forever is a terrible tradeoff - giving up #1 to save #2 at any cost. Code isn't that special, especially on the first pass.
albrewer 2y ago
> "gun to the head" heuristic Never underestimate the power of hiring a new employee and training them how to do what the software would do, thereby writing zero lines of code. That $250k in initial feature development costs + maintenance might only be $75k in personnel costs a year, which is a break-even of ~4 years. Depending on the problem, that might be the best option.

269 points by ksec 2y ago

Although I disagree with the arbitrary limit of “one day per feature”, I agree with the broader point that useful constrains drive creativity.

082349872349872 2y ago

The generalisation I would make is: if you think, not just of a specific solution, but of the space of possible solutions, it makes it easier to find a point in that space which best "fits" (space, time, architecture) the program you're working on. Rather than trying paths in the dark, first look at a map, then try a few paths.

MillironX 2y ago

I fundamentally disagree with the "gun to the head" strategy. One of the major projects I worked on was a virus genome analysis pipeline. Our initial funding was for single-segment virus analysis, but about a year into the project, our grant collaborators needed to demonstrate multi-segment virus support within two weeks. My PI and I agreed on a quick and dirty method that would produce the analyses needed and could be done in the allotted time. That piece of code was fundamental to how the whole pipeline worked, however, and so as the pipeline grew, it took on the shape of the "gun to the head" decision we had made to the point where other, more essential features of the pipeline had to be delayed so I could come up with more workarounds. There were clearly other issues at play here (scope creep and lack of separation of concerns were huge). My time at the lab came to a close, but if I were to have a chance to continue that project, I would start over from scratch rather than deal with the baggage that that one "gun to the head" moment created. I understand that it's a heuristic and not meant to be taken as 100% truth for every situation. I also understand that it's trying to avoid that "paralysis by analysis" that's so easy to fall into. I just question how useful it truly is as a heuristic, especially since it seems to go against the "write everything twice" algorithms presented in the rest of the piece.

tikhonj 2y ago
I'd say it goes with the "write everything twice" heuristic! If you're in an environment where you can write things twice—you have trust and autonomy and aren't encumbered by process—then writing an initial version as fast as possible gets you started faster, lets you play with something concrete and leaves you more room for your second version. My best projects were like that. I'd figure out something quick—some combination of reducing scope and doing "things that don't scale"—then spend time refining the conceptual design and interfaces, and finally rewrite the initial piece based on that new design. This can absolutely work better than just trying to write something "good" the first time around, but it looks wasteful to somebody superficially tracking individual "tasks" you're working on.
qsort 2y ago
> I just question how useful it truly is as a heuristic I think the author is presenting them as analytical tools that might or might not be useful depending on the situation. Very often when faced with a difficult problem it's hard to know where to start attacking. Any idea, even if simplistic and wrong, can be useful to start gaining insight on what is going to work and why; even just refuting the original idea with a clear counterargument might suggest alternative avenues. OT: this is IMO part of the reason why people like LLMs so much. Maybe the answer is trash, but articulating why it's trash gets you unstuck.
MajimasEyepatch 2y ago
As the saying goes, there's nothing more permanent than a temporary solution. If you're going to do this, you either have to explicitly plan for the cost of the rewrite to do it the "right" way after doing it the "wrong" way, or you have to accept that you're probably not going to revisit the "temporary" solution for a long time.

neilv 2y ago

These are useful mental tools, to have in your mental toolbox, and apply them as they seem appropriate, but don't make a religion of any of them. A related old idea about writing/reworking software three times: "Do it. Do it right. Do it fast." Startups provide ample opportunities to get experience with what the article calls "gun to your head heuristic". You have to decide what and how to compromise. And, if you want your startup to be successful (not just hit your metrics/appearances, and then job hop), you can't just do it like school homework (where the only goal is to slip something past a grader, and forget about it), but you have to creatively come up with a holistically good compromise solution, given all the factors. If you do this well, it's creative magic that can't be taught, but can be learned, through experience and will.

n4r9 2y ago
> A related old idea about writing/reworking software three times: "Do it. Do it right. Do it fast." The version I've heard is "Make it correct. Make it readable. Make it performant."
- rokob 2y ago
  These are all variants of Kent Beck’s saying: “Make it work, make it right, make it fast.” https://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast https://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast
  - boguscoder 2y ago
    And this is not about writing anything thrice at all, it’s about picking right priorities/order

mattlondon 2y ago

Gun to the head solutions: no tests, no quality, no future planning, hacks on top of hacks, tech debt. As a manager, this "thought exercise" is dangerous. You think it is a fun and harmless exercise to your reports to really focus, your reports at best think you don't trust them, and at worst think you are threatening them with violence (hypothetical or otherwise) unless they tell you what they think you want them to say. Psychology safety will be at rock bottom pretty quickly. Nice job you have there, would be a reaaaaalll shame if anything hypothetical happened to it huh? Now estimate again, and this time don't make me angry <imitates pulling a trigger of an invisible gun at someone's head>. Absolutely terrible behaviour.

me-vs-cat 2y ago
He does need a better name. > The purpose of the thought experiment isn't to generate the real solution. It's meant to put a lower bound on the solution. Then you think of a real solution with that lower bound in eyesight, and you'll find it's often better than your original solution. He does not say to actually implement the quickest hack you can imagine, nor to skip the mundane steps that avoid tech debt. He says spend 10 minutes imagining a quick hack after laying out your initial solution, and incorporate anything you learned into your actual work. To me, it sounds very similar to a startup chipping away at their original idea to get a MVP. > The purpose here is to break their frame and their anchoring bias. If you've just said something will take a month, doing it in a day must require a radically different solution.

kvemkon 2y ago

Previous discussion: Algorithms we develop software by (18.08.2024) https://news.ycombinator.com/item?id=41284409 https://news.ycombinator.com/item?id=41284409

ww520 2y ago

For "write everything twice" I would say write some parts many times. You don't have to write everything twice. Most code are optimal or good enough already, but you should be willing to re-write some parts over and over again.

w10-1 2y ago

People learn to work better by reflecting on work. So any framework for self-observation is better than none. I suspect that algorithms as a framework demonstrates the structural aspects (e.g., how some searches are more extensive), but might hide the driving factors. Indeed, the article examples were almost all hacking personality, not technical or process solutions. E.g., most over-engineered solutions are driven by fear, often itself driven by critical or competitive environments. Conversely, much of the power of senior/staff engineers comes from the license to cut corners afforded their experience. Or people use the tools they know. You can't get to great by holding onto good. It's easy to go from bad to good, but takes some courage to toss good to start over for great. The lesson there is that we stand (hide?) behind our work, and we need to let go of it to improve it. A meta-lesson is that managers need to deeply understand personal space of each developer and the social dynamics of the team before they can do their job effectively, and a key part of that is likely checking in with developers in a way that enhances their courage and self-observation instead of making them fearful and paranoid.

trhway 2y ago
> much of the power of senior/staff engineers comes from the license to cut corners afforded their experience. Absolutely. Jira is equally slow for everyone except for the ones who are allowed to skip it. At the places where i managed to become star developer it was by hitting hard early and achieving great results, and after that you’d get a lot of slack cut for you which allows you to continue deliver at the star level with relatively light effort, and definitely much easier than say the mediocre grind i produce at the current place where “Jira” is truely slow with us.
- shiroiushi 2y ago
  So you were a "star developer" at some previous workplaces, but now you're not, and just produce at a "mediocre grind"? Why is that? And why work there now and not that the previous places? I suspect this is the common tale of poor compensation: despite being a star developer, employers won't pay for properly for this, just a mediocre annual raise, so you move on after a couple of years to another place, which offers you a huge raise (new starting salary compared to the previous job's salary). And the new place, while giving you a poor environment that hampers your productivity, still pays much better than the previous places where your productivity was much higher. And because of this common workplace dynamic, it's usually not worth it to put in much effort to be a star employee, unless you find the rare employer that actually rewards you for it. Is my guess correct?

dakiol 2y ago

I spent 90% of the time reading and trying to understand the business logic behind the code that lies in the place that I think I need to put my feature in. So far, no methodology helps much with this part of software engineering. The remaining 10% is rather straightforward.

vtodekl 2y ago

[dead]

rcgorton 2y ago

[dead]

declan_roberts 2y ago

> A piece of advice I've given junior engineers is to write everything twice. Solve the problem. Stash your code onto a branch. Then write all the code again. I discovered this method by accident after the laptop containing a few days of work died. Rewriting the solution only took 25% the time as the initial implementation, and the result was much better. This is true, and I've discovered it myself by losing a branch. However, who the hell has time to write everything twice? There's 1,000 things waiting to be written once.

spiffytech 2y ago
I think the mitigating factor is "slow is smooth, smooth is fast". If you raise the quality of your codebase, you can implement those 1,000 things faster, and you reduce the odds of they'll have to be reworked.
- animal_spirits 2y ago
  This only works if you are in charge of the timelines or have a manager who values quality over quantity
  - ajmurmann 2y ago
    And/or an organization that has the faith and politics that allow to wait till smooth starts paying back and becomes fast. Frequently you also have everyone benefiting from smoothness but not everyone contributing to it which results in the folks who pump out tickets as fast as possible looking like they are just strictly better. Easy to adapt to and game as an IC, but I find it frustrating as a manager.
    - netdevnet 2y ago
      > wait till smooth starts paying back and becomes fast By that time, you will have probably left the company and someone with less care about code quality will come and undo your work. Also, like security, it is hard to show to a manager data and graphs showing how much we are saving

OutOfHere 2y ago

It is the worst advice I have read. If the goal is to divide everything to fit in a day, it would be better to use a static analyzer to enforce certain rules.

ilidur 2y ago

Review: An anonymous "distinguished CEO and engineer" suggests if you can't complete a feature in a day, delete your progress (except for tests) and start again the next day. The author then recounts advice he gives to juniors, which is to stash the work and rewrite it, claiming that the next day the work will be rewritten in 25% of the time and 2x quality. This is unsubstantiated though. For juniors this suggests it will help them develop their capabilities to reason about implementations of problems without needing to face a a large amount of them. The author then gives another advice which is to ask for a solution to a problem then after the initial proposal, ask for a 24h solution. This is meant to generate "the real solution". He likens it the a path algorithm heuristic to reach your goal quicker. Overall the methods are not well discussed in terms of pros and cons, nor substantiated with experiments. Opinion: I think they may help some juniors who need to build up experience and may become stuck in development patterns. But they would rarely be useful to develop someone to be a senior, if all they do is chase fast implementations. In a way the post gives conflicting advice: write twice and write better, and think twice and think about the fastest way to achieve the goal, instead of engineering a problem. The author hasn't really convinced me of these approaches, and especially the last one smells of eXtreme Go Horse.

guappa 2y ago
Scientific approach would be to try this yourself.
- ilidur 2y ago
  I would say that's called an anecdote.
  - arzke 2y ago
    Exactly. The "it works for me so it works" type of thinking is what makes people mistakenly conclude that homoeopathy works any better than a placebo.
    - guappa 2y ago

vincnetas 2y ago

"Gun to your head" gives you quick working solutions. But then when you avoided the headshot you run away and leave that quick-fix-mess to someone else. So this should not be a long time strategy. Sure if your runway is approaching the end, do whatever is needed to stay alive.

phrenq 2y ago
Generously, I think the article is presenting it as a thought experiment to make sure you’ve thoroughly explored the solution space, while not literally recommending that you necessarily implement the “gun to your head” solution.

max_ 2y ago

Is the title a play on the "Algorithms to Live By" book. Sounds clever :)

arresin 2y ago

> Start working on the feature at the beginning of the day. If you don't finish by the end of the day, delete it all and start over the next day. How experienced is this “CEO and engineer”?

booleandilemma 2y ago
I know, I laughed out loud and stopped reading after that sentence.

marhee 2y ago

Side note: “write everything twice” (WET) is originally meant as a reaction to DRY (“don’t repeat yourself”). I think the author uses the credo here for something else (which is still good advice).

jasfi 2y ago

If you write a design doc first, you can save yourself a lot of time. It's very quick to write a new design, and designs are also much faster to revise than code is.

wiremine 2y ago

I agree 100% with this approach, and I'd love to see some research to back it up. I think a lot of software development is "way finding" - Experimentation to figure out an architecture, an implication, a performance improvement, etc. We often don't a) call them experiments, and b) we don't constrain them well. I.e., we use the scope of the feature to bound the experiment, instead of taking a step back to figure out the right approach, we dive into implementation. I'm curious if there's a more formal way to think about this all?

anonyfox 2y ago

A thing that took me several years to agree to is that almost everything can be coded within 24 hours if really needed - gun to the head situation. Will it be perfect/efficient/beautiful/... probably not. But it should roughly work like its supposed to. If something cannot be coded within that 24 hours, something else is odd, not the feature. Transitioning from SWE to DevOps and then Leadership roles, most of my day actually is spent with all the reasons/excuses why "it cannot be done", and try to eliminate them. Probably my developers hate me for it, but I always push hard for an immediate first solution instead of doing days of soul-searching first, but over time we encounter and solve enough roadblocks (technical, social, educational, ...) that it actually happens more often than not to have surprisingly fast (and good enough) solutions. That speed is a quality in itself, since it frees up time to come back to things and clean up messes without the shipping pressure mounting up over days/weeks - something working is already there on day two. The trick is of course to _not_ sell this 24 hour solution to upper management ever, or else it will become a hell of a mess fast once this becomes the outsider expectation.

whatnotests2 2y ago

Nice play on words from Lakoff's "Metaphors We Live By"

ayewo 2y ago
Surprised you were the only one to pick up on the pun on the title of George Lakoff’s seminal book from 40+ years ago :)

perrygeo 2y ago

The "write it twice" strategy should be more common. The alternative is "write it once and be stuck with it". You want tech debt, cause that's how you get tech debt. By definition, the first time you do something, you will learn a ton. So you've gained two things: 1) hard-won technical knowledge and 2) a bunch of sub-optimal code written before you obtained that knowledge. The way I see it, keeping that proof-of-concept code around forever is a terrible tradeoff - giving up #1 to save #2 at any cost. Code isn't that special, especially on the first pass.

albrewer 2y ago

> "gun to the head" heuristic Never underestimate the power of hiring a new employee and training them how to do what the software would do, thereby writing zero lines of code. That $250k in initial feature development costs + maintenance might only be $75k in personnel costs a year, which is a break-even of ~4 years. Depending on the problem, that might be the best option.