6 ms·

Two points I really enjoyed: > Not Fixing All the Edge Cases We’ve all seen bugs that occur so rarely, and fixing requires destroying some part of the origina

Two points I really enjoyed: > Not Fixing All the Edge Cases We’ve all seen bugs that occur so rarely, and fixing requires destroying some part of the original design architecture. The ability to acknowledge these types of bugs as not worth fixing is liberating. > Err on the side of building too little because you can always build more later. Build things to be easy to throw away and replace; I find developers tend to really dislike throw away code or temporary solutions knowing they might break in the future. If the quick hack is well documented, written in a very encapsulated and removable way, who cares about removing it later.

stronglikedan 7y ago
> I find developers tend to really dislike throw away code or temporary solutions knowing they might break in the future. IMHE, it's usually management that feels this way.
human20190310 7y ago
It's also great that the author gave concrete examples of times where it made sense to eschew purity for pragmatism. Very good article all-around.
BurningFrog 7y ago
> I find developers tend to really dislike throw away code or temporary solutions This is good way to level up: Learn to love throwing your code away!
- jackcosgrove 7y ago
  Maybe programmers need to listen to Marie Kondo more.
  - the_seraphim 7y ago
    does this for loop make me happy?
  - yboris 7y ago
    "Does this code bring me joy?" :P
marcosdumay 7y ago
Building things to be easy to replace often does not mean quick hacks. Quick hacks are most likely hard to trow away, not easy. Building things to throw away means componentizing your code, that is extra work overall.
- tomnipotent 7y ago
  > Building things to throw away means componentizing your code No it doesn't. You can really tell who has and hasn't worked at a start-up by the responses to OP.
  - kevinwang 7y ago
    What does it mean, then?
  - erikpukinskis 7y ago
    I’m not sure how you can have such a strong no reaction to a statement that can mean almost anything. The word “component” barely means anything at all. Lots of room for interpretation there.
  - eikenberry 7y ago
    He's right that it doesn't mean quick hacks, but it doesn't really mean "componentizing" either. It means keeping it simple. Don't over-engineer it (componentize it) but don't use some ugly hack or cut-n-paste off SO either.
- vinay_ys 7y ago
  You are right. You have to make architectural choices to build a soft layer that can absorb such hacky throwaway code that can be pruned easily later. Usually a hard platform layers sits underneath it and supports this. Following Conway's law, usually there are teams to build and enforce the platform constructs that are relatively debt free and there are teams that work on the soft application layer on top of those platforms where these throwaway hacks can be easily put. You have to design for this in your architecture. But if this strategy is right for your business domain, then once you make the initial investment, it will pay for itself multiple-folds. You will see this pattern in online gaming code bases.
Nursie 7y ago
I love throwing away code! We found a better way to do this - boom, you're gone! I do dislike coding solutions which I know to be temporary, sometimes it's necessary but it feels wrong if we already know something's not going to be adequate. That said it's also very bad to future proof (by which a lot of people mean abstract) the code to be able to do everything you can possibly think of that might be needed in future, or even (and I've seen this attempted) things we might possibly want that we don't even know about and can't think of!
- julianozen 7y ago
  My thoughts on this is that a code base is a living thing. Things go out. Things go it. We have a history of every change made (and often you can interpret the reasons why)
gmueckl 7y ago
Writing hacks and throw-away stopgap solutions is generally a bad idea in reality. The only time when it can actually be allowed is when it it concerns a feature that is a pure leaf in the system with nothing else built on top of it. If you violate this rule and build other features on top of shortcuts, two things will inevitably happen: you will have to replace the shortcut with a proper solution eventually (it is only a matter of time) and by the time this happens, the assumptions underlying the shortcut have implicitly been taken on by the code depending on it. This means that you will have to review and replace a lot of dependent code as well. I have gone through that dance often enough. It ends up being more time consuming than doing it right in the first place each and every time.
- stcredzero 7y ago
  Writing hacks and throw-away stopgap solutions is generally a bad idea in reality. The only time when it can actually be allowed is when it it concerns a feature that is a pure leaf in the system with nothing else built on top of it. I worked at a company where there was an API and an explicit place for such hack code, for consultants to customize the product. The way it was done, was to ensure such code was a pure leaf.
- erikpukinskis 7y ago
  I like that delineation between branches and leaves. If it’s a branch, solve the real problem. If it’s a leaf, consider just getting it done.
- jamie_ca 7y ago
  Yes, it's more time overall, but that's not the point. From the example in the article, if it would take them 2 months to build a robust email delivery system or 2 weeks to put a temporary hack in place, it could be worthwhile to the business to do the hack if it means they can start user-testing 6 weeks earlier. Also, if they're still in the product-fit stage of their business development, they might find that the product isn't as useful/worthwhile as they thought, and scrap it after 2 weeks testing. This would allow 6 weeks of overall developer effort to be spent on another initiative. Just because you know that developing throwaway code is waste, doesn't mean it's necessarily a bad business decision.
hoorayimhelping 7y ago
>If the quick hack is well documented, written in a very encapsulated and removable way, who cares about removing it later. I do. I care very deeply about removing it later. The problem is that encapsulation is often mistaken as a strong justification for existence, and code that is written tends to justify its existence just by existing. That's to say that once code is in production, it's scary to delete. It's much less scary to delete a couple of lines of inline code wrapped in a comment that says "this is a hacky solution," because code that isn't encapsulated probably probably isn't used elsewhere. Or if it is, it's copy-pasted. The scary thing about removing encapsulated / abstracted things, is that oftentimes, other things refer to them, unbeknownst to the original author or their intent. It's pretty common (especially on larger teams) - the first developer writes up a hacky solution, the second developer abstracts that hack into a module due to some sensibility (abstraction, aesthetics, organization, etc), so now the hack has legitimacy. A third (or often the first developer) sees that the hack is in a module, assumes that the person who put it in a module had more information than when the hack was written and that it's now a first class member of the system. And first class members of a system take thought and time to delete.
- tempestn 7y ago
  It sounds like a lot of those problems could be solved, or at least mitigated, by better communication between these developers.
  - s_tec 7y ago
    Right, except that communication between developers is the least scalable part of running a software team. For every new member you add, there are n existing developers to communicate with, so your communication costs go up as O(n^2). If the goal is to grow a piece of software over time (as in many startups), any architecture that relies on "better communication" is doomed to fail, simply because it limits the size of the team that can handle it (and thus growth).
    - tempestn 7y ago
      That's true, although I would expand communication to encompass code comments and other documentation, which can scale better.
stcredzero 7y ago
> Not Fixing All the Edge Cases This can also be a part of tackling very complex tasks. To prevent getting overwhelmed when implementing something huge, I sometimes do what I call, "Implementing something stupid." Want to build an MMO? Build something that manages to send sync information to a multiple clients, but ignores auth, security, being cheat-proof, robustness, etc... Then once there's something running, start addressing those issues. So instead of not fixing all the edge cases, it's not implementing all the edge cases all at once. If the quick hack is well documented, written in a very encapsulated and removable way, who cares about removing it later. When it starts causing "lava flow" then it's time to remove it. http://antipatterns.com/lavaflow.htm http://antipatterns.com/lavaflow.htm
twblalock 7y ago
> If the quick hack is well documented, written in a very encapsulated and removable way, who cares about removing it later. That's fine in a system with a small number of quick hacks. In reality, the number of quick hacks grows over time and you end up with a brittle system that has a lot of unanticipated behavior that only a few people understand how to work with. You will eventually have quick hacks that exist to fix bugs in the other quick hacks.

stronglikedan 7y ago

> I find developers tend to really dislike throw away code or temporary solutions knowing they might break in the future. IMHE, it's usually management that feels this way.

human20190310 7y ago

It's also great that the author gave concrete examples of times where it made sense to eschew purity for pragmatism. Very good article all-around.

BurningFrog 7y ago

> I find developers tend to really dislike throw away code or temporary solutions This is good way to level up: Learn to love throwing your code away!

jackcosgrove 7y ago
Maybe programmers need to listen to Marie Kondo more.
- the_seraphim 7y ago
  does this for loop make me happy?
- yboris 7y ago
  "Does this code bring me joy?" :P

marcosdumay 7y ago

Building things to be easy to replace often does not mean quick hacks. Quick hacks are most likely hard to trow away, not easy. Building things to throw away means componentizing your code, that is extra work overall.

tomnipotent 7y ago
> Building things to throw away means componentizing your code No it doesn't. You can really tell who has and hasn't worked at a start-up by the responses to OP.
- kevinwang 7y ago
  What does it mean, then?
- erikpukinskis 7y ago
  I’m not sure how you can have such a strong no reaction to a statement that can mean almost anything. The word “component” barely means anything at all. Lots of room for interpretation there.
- eikenberry 7y ago
  He's right that it doesn't mean quick hacks, but it doesn't really mean "componentizing" either. It means keeping it simple. Don't over-engineer it (componentize it) but don't use some ugly hack or cut-n-paste off SO either.
vinay_ys 7y ago
You are right. You have to make architectural choices to build a soft layer that can absorb such hacky throwaway code that can be pruned easily later. Usually a hard platform layers sits underneath it and supports this. Following Conway's law, usually there are teams to build and enforce the platform constructs that are relatively debt free and there are teams that work on the soft application layer on top of those platforms where these throwaway hacks can be easily put. You have to design for this in your architecture. But if this strategy is right for your business domain, then once you make the initial investment, it will pay for itself multiple-folds. You will see this pattern in online gaming code bases.

Nursie 7y ago

I love throwing away code! We found a better way to do this - boom, you're gone! I do dislike coding solutions which I know to be temporary, sometimes it's necessary but it feels wrong if we already know something's not going to be adequate. That said it's also very bad to future proof (by which a lot of people mean abstract) the code to be able to do everything you can possibly think of that might be needed in future, or even (and I've seen this attempted) things we might possibly want that we don't even know about and can't think of!

julianozen 7y ago
My thoughts on this is that a code base is a living thing. Things go out. Things go it. We have a history of every change made (and often you can interpret the reasons why)

gmueckl 7y ago

Writing hacks and throw-away stopgap solutions is generally a bad idea in reality. The only time when it can actually be allowed is when it it concerns a feature that is a pure leaf in the system with nothing else built on top of it. If you violate this rule and build other features on top of shortcuts, two things will inevitably happen: you will have to replace the shortcut with a proper solution eventually (it is only a matter of time) and by the time this happens, the assumptions underlying the shortcut have implicitly been taken on by the code depending on it. This means that you will have to review and replace a lot of dependent code as well. I have gone through that dance often enough. It ends up being more time consuming than doing it right in the first place each and every time.

stcredzero 7y ago
Writing hacks and throw-away stopgap solutions is generally a bad idea in reality. The only time when it can actually be allowed is when it it concerns a feature that is a pure leaf in the system with nothing else built on top of it. I worked at a company where there was an API and an explicit place for such hack code, for consultants to customize the product. The way it was done, was to ensure such code was a pure leaf.
erikpukinskis 7y ago
I like that delineation between branches and leaves. If it’s a branch, solve the real problem. If it’s a leaf, consider just getting it done.
jamie_ca 7y ago
Yes, it's more time overall, but that's not the point. From the example in the article, if it would take them 2 months to build a robust email delivery system or 2 weeks to put a temporary hack in place, it could be worthwhile to the business to do the hack if it means they can start user-testing 6 weeks earlier. Also, if they're still in the product-fit stage of their business development, they might find that the product isn't as useful/worthwhile as they thought, and scrap it after 2 weeks testing. This would allow 6 weeks of overall developer effort to be spent on another initiative. Just because you know that developing throwaway code is waste, doesn't mean it's necessarily a bad business decision.

hoorayimhelping 7y ago

>If the quick hack is well documented, written in a very encapsulated and removable way, who cares about removing it later. I do. I care very deeply about removing it later. The problem is that encapsulation is often mistaken as a strong justification for existence, and code that is written tends to justify its existence just by existing. That's to say that once code is in production, it's scary to delete. It's much less scary to delete a couple of lines of inline code wrapped in a comment that says "this is a hacky solution," because code that isn't encapsulated probably probably isn't used elsewhere. Or if it is, it's copy-pasted. The scary thing about removing encapsulated / abstracted things, is that oftentimes, other things refer to them, unbeknownst to the original author or their intent. It's pretty common (especially on larger teams) - the first developer writes up a hacky solution, the second developer abstracts that hack into a module due to some sensibility (abstraction, aesthetics, organization, etc), so now the hack has legitimacy. A third (or often the first developer) sees that the hack is in a module, assumes that the person who put it in a module had more information than when the hack was written and that it's now a first class member of the system. And first class members of a system take thought and time to delete.

tempestn 7y ago
It sounds like a lot of those problems could be solved, or at least mitigated, by better communication between these developers.
- s_tec 7y ago
  Right, except that communication between developers is the least scalable part of running a software team. For every new member you add, there are n existing developers to communicate with, so your communication costs go up as O(n^2). If the goal is to grow a piece of software over time (as in many startups), any architecture that relies on "better communication" is doomed to fail, simply because it limits the size of the team that can handle it (and thus growth).
  - tempestn 7y ago
    That's true, although I would expand communication to encompass code comments and other documentation, which can scale better.

stcredzero 7y ago

> Not Fixing All the Edge Cases This can also be a part of tackling very complex tasks. To prevent getting overwhelmed when implementing something huge, I sometimes do what I call, "Implementing something stupid." Want to build an MMO? Build something that manages to send sync information to a multiple clients, but ignores auth, security, being cheat-proof, robustness, etc... Then once there's something running, start addressing those issues. So instead of not fixing all the edge cases, it's not implementing all the edge cases all at once. If the quick hack is well documented, written in a very encapsulated and removable way, who cares about removing it later. When it starts causing "lava flow" then it's time to remove it. http://antipatterns.com/lavaflow.htm http://antipatterns.com/lavaflow.htm

twblalock 7y ago

> If the quick hack is well documented, written in a very encapsulated and removable way, who cares about removing it later. That's fine in a system with a small number of quick hacks. In reality, the number of quick hacks grows over time and you end up with a brittle system that has a lot of unanticipated behavior that only a few people understand how to work with. You will eventually have quick hacks that exist to fix bugs in the other quick hacks.