10 ms·

Throwaway Code

71 points by lordgilman 7y ago

angarg12 7y ago
A colleague told me an anecdote tangentially related. He was working on a service and managed to hack together some code that barely worked. His manager came around and a conversation like this unfolded. Manager: How is your project going? Engineer: Pretty well, I got something working. Manager: Excellent! We have a meeting with a VP tomorrow and we want you to do a demo. The lesson learned was to be careful and under optimistic about how you communicate to leadership.
- chooseaname 7y ago
  I've seen X-Language shops write PoCs in different languages only to end up with those PoCs in production and a kludge layer between the PoC code and the normal X-language layer. I've seen people nail down the complete UI first only to spend umpteen sprint demos afterwards explaining why a "fully functional" UI can't be put into production yet to angry management. No matter how hard you try, you can't explain an iceberg to a management staff that wants the project to start earning money already. > The lesson learned was to be careful and under optimistic about how you communicate to leadership. Yes. Some people have to learn this the hard way. I would add, don't try and be sneaky either (ie: using different languages, etc.).
  - hinkley 7y ago
    The worst part about demo code like that is you have to code review every single line to make sure that the entire UI is using real data now and not some placeholders embedded in a function or the UI. We had someone go way down that rabbit hole once and I had to tell the manager that we don’t and can’t know how long it will take to ship this, because the entire thing is a fiction.
z3t4 7y ago
If the code is any good, it will be rewritten. Or it's perfect. Bad code however, no one want to touch it.
Ididntdothis 7y ago
Having seen too many times how throwaway code and proof of concepts went into production I try to always write decent code. You don’t need all the bells and whistles but just give things decent names, put repeated stuff into functions, avoid memory leaks, define constants and so on. It also reduces cognitive overhead. A lot of people seem to spend a Lot of energy thinking about whether a project needs proper coding or not.
- hinkley 7y ago
  There was a time where this got so bad at one company, that I was getting neurotic. To put an order of magnitude on it, my mentor got fired for calling out his boss on some of the demo-ware shipping bullshit. Before this all came to a head, I started doing proof of concept work as command line only. This allowed me to give them estimates they had to listen to, instead of them just assuming that because they could see a UI that we could just pretty it up and ship it next month. Clearly, they reasoned (as if anything they did resembled reason) my two to three month estimate was sandbagging and it was okay to tell the customer we’re almost done.
  - hinkley 7y ago
    I fear I have given a false impression by saying 'he was fired'. John, let's call him, was summarily fired. GTFO. And in an early morning meeting, no less. I got to hear it from the coworker who was best at deadpan jokes, so I didn't believe him the first time when I asked, "Did I miss anything?"
- avetisk 7y ago
  I totally agree! Most of the time you just needed that little effort to keep things neatly and tightly together. No need to separate it: we just need to keep the minimal good habits all the time!
- heavenlyblue 7y ago
  That's one of the key reasons why I hate when people say they can "develop" in <insert your average text editor>. In an IDE I can quickly type out a full function body with 1-character variable names, then run it and see what happens. Immediately after I have seen it work I can go back and rename all of the variable names into something more descriptive. This is also easier now because you know exactly what the variables are used for. You can do the same immediately for constants (most of the IDEs will allow you to "extract the given expression as a constant on the module level" or alike). This can never work in a text editor because you need to know how that specific 1-letter tokens. There is no reason to write non-descriptive code unless you're trying to save maybe 5% of your time. At a job where timelines can easily go orders of magnitude higher than expected, you're trying to shave off a minor portion of your net time spend...
avetisk 7y ago
I think there are 2 cases in real world scenario: 1) either you have the habit, energy and time to systematically rewrite your code properly through iteration; 2) or you are so good that your average throwaway code is considered not that bad. Because mostly either we are going through well known paths which leads to case 2) or we’re exploring new things and being “skilled & experienced developers” we manage to have the right habits, energy and time to build things iteratively ending up in case 1). If in the end we still have trashy code, then we need to ask ourselves if we are lacking any of the following: skills, energy, time or good habits (or a proper context, but that’s a whole other universe of problems).
ChrisMarshallNY 7y ago
I write every line of code as if it were going out the door. But that's actually a fairly good idea (use a different language).
axegon_ 7y ago
> make sure the people using throwaway code understand that even though it kind of looks like it works, it cannot be maintained and must be rewritten I couldn't agree more with this. Not that long ago I inherited a project which on the surface looked shiny and nice. I was however aware that it was a mess underneath. Mind you, I was completely unprepared for the utter crap that awaited me. In all fairness it is the worst thing I have ever seen by light years. It took me two almost 2 weeks to find where a bug was coming from (it was written in a way which no debugger could trace it back, no logs, everything was surprised). After fixing it eventually, I decided to scrap it and build the whole thing from scratch. At the end it took me just over a month (Saturdays and Sundays included) and another 2 weeks from another developer to get a replacement project from an empty file. And here are the two painful truths about the whole endeavour: it took us collectively under two months to build, document, test, and run it in production. A grand total of around 20-30k lines of code. It took the people before us 3 and a half years to make their version which was anti patterns, top to bottom and in those 3 years the company invested around half a million Euros in salaries alone. If argue that this is the most painful thought. Not even the fact that this has been my first weekend this year in which I'm actually relaxing and not working. So my word of advice-if you end up in a similar situation, scrap everything, do it from scratch. Take a piece of paper, write down the business logic, draw a diagram of the structure of your application around it, pick the most appropriate stack and go for it. Avoid shiny new toys, profile everything and remember that sometimes it's better to let an application crash in order to find it's weaknesses.
- Swizec 7y ago
  It’s easier to build something once you know what you want than it is while you’re discovering what you want. We’re dealing with similar at work now. Over 5 years a system was built. It works and the code is crap. Now I’m pushing management to please just decide “Yes, this is what we wanted all along” so we can throw out 90% of the code
  - axegon_ 7y ago
    > It’s easier to build something once you know what you want than it is while you’re discovering what you want. Oh absolutely. Thing is, in my case, what was needed was clearly defined since the beginning. It's the "developers" who built it who were incompetent af.
dimtion 7y ago
That might work for video games, but in a web company I've seen so many throwaway bash, perl or python scripts wrapped in an `system(*command)` that are unmaintainable and sometimes cause RCE or injections bugs. I feel that this advice only fixes the symptoms and not the underlying root cause. This is a culture issue, not a technical issue.
codr7 7y ago
It's not a black/white thing, really. My code tends to be somewhat repetitive and terse while exploring new ideas. Once I know where I'm going I'll gradually refactor and spell things out to the level I'm aiming for, which is different depending on context. Polishing code that should never go anywhere is a waste of life, and once you've spent all that effort it's more difficult to keep an open mind about the design.
3fe9a03ccd14ca5 7y ago
I find throwaway code to be freeing and fun. I don’t have to worry so much about making the perfect abstraction, or some DRYness optimizations. I’ve also had my share of throwing making it into production. The secret is keeping it simple. Simple code can always be optimized later. It can always be optimized if it’s simple. Besides, the junior developers need something to bust their chops on anyway right? Often times when someone takes over the project I’ve already listed in the library and in comments what can and should be improved.
symplee 7y ago
Similar to the infamous: "temporary" workarounds...
4ndrewl 7y ago
All of your code will be thrown away.
rzimmerman 7y ago
If your “throwaway” code works fine in production for years without any active maintenance and the only down side is that it needs a rewrite five years later, was it really that bad? Or is it the exact thing tech debt refers to - borrowing future time to work on what’s important? If I had to make a point it would be that there’s no line between code that needs to be replaced right now and code that is perfect and lasts for decades - it’s a spectrum and circumstances influence your tolerance.
- hinkley 7y ago
  The flip side of this is people who get sunk cost fallacy around that throwaway code. Rewriting a piece of code that’s been in use for two, three years doesn’t invalidate its existence. It wasn’t necessarily a mistake for it to be written that way. It is a mistake to keep on using it, though. I think maybe it’s similar to the way we misuse the term “crutch”. If you have a broken leg use the damn crutches. When your leg heals and you sell the crutches, don’t castigate yourself or anyone else about how useless crutches are. You used them. Past tense. That’s done now, and you’re moving on.
hinkley 7y ago
There was an interview posted here last week about tech debt, and the speaker mentioned that if you compartmentalize throwaway code properly it can be kind of liberating. I don’t know that I’ve seen that in the wild, but it sounded plausible. Instead, he claimed, the only important part of that code - at all - were the interfaces. So save your design that part well and for the rest, save your energy. I have seen flavors of the latter work out, especially when you combine the idea of riskiest thing first (also last week) with reversible decisions and only decide today on things that have to be decided now. For things that are easy to change, make an arbitrary selection and keep moving. For everything else, play for time and hope that new information will improve those decisions.
lmilcin 7y ago
I use a different framework for throwaway code. For example, my current prod application I work on uses Apache Storm and Kafka Streams, my throwaway code is written with Eclipse Vert.x. I tend to use bottom up approach when I start by writing small bits and pieces of utility functions, tools, etc. and I build a larger proof of concept based on that. Typically, the top level of the application is pretty dirty and changes constantly while I spend time to get the bottom of it correct right from the start. I use the top level of the application as a kind of test framework for the bottom parts. Then when the time is right, I throw away the top of the application and build the new one using some of the tools I have already developed. I would love to do my throwaway code in Clojure but writing it in the same language as my production application lets me gain more knowledge, faster, and already have some stuff ready when I get to write the main part.
daxfohl 7y ago
I haven't written a prototype in forever. I don't find them effective. And they typically take way longer than you expect at the outset. Do some wire charts or graphics and present those. It's far more boring to do than writing a prototype, and learning design tools is cumbersome, but they allow you to demo things better to executives, redraw stuff on the fly in meetings, copy and paste to a document or slideshow, share with external parties, and people don't get hung up on minutae that come with presenting a prototype. Stakeholders far prefer seeing a well thought out document or slideshow than a dinky fake app. Once you get signoff on the design and flow, then jump straight into the real code, skip the whole prototype step. I'd rather be coding, but sometimes it's just not the most efficient use of my time.
- mstibbard 7y ago
  Do you use any specific tooling to help with this?
  - daxfohl 7y ago
    My primary tools are actually Photoshop and PowerPoint. Lame I know, but they have served me well over the years. Actually, hadn't thought much about it before, but being proficient at these two tools might be just as valuable to me as coding skills.
    - loopz 7y ago
      Krita's become mature over the years.
arendtio 7y ago
I like to have a folder called playground within my projects, where I build related prototypes and try out new ideas. Whenever something seems to work well, I do some sort of cherry-picking to keep the things I got right within the prototype and rewrite everything else. This helps me to validate ideas while keeping the main project in good shape. It is not as extreme as choosing a different language for the prototypes, but for me, it worked well so far.
TeMPOraL 7y ago
A related idea: use not just a different language, but a completely different toolset. At my last job, I prototyped half of the serious overhaul of a mid-sized product (backend and UI) in a bunch of ObservableHQ notebooks. It was all a pile of hacky JS, hastly-written over the course of a week, but it let me explore and showcase all the new product ideas and serve as a reference for my co-workers (and something to demo to the management), and at the same time there was no way it would ever end up in production. After all, it was all just a bunch of private notebooks on a third-party SaaS, and the presentation was explicitly following the notebook/document model instead of an application model. And, of course, our real backend wasn't written in JavaScript.
bobm_kite9 7y ago
I have the opposite problem - a lot of the code I think carefully about, factor correctly and ensure is thoroughly unit-tested spends about six months circling the plug-hole of tech demos and PoC before being sent to the bit-sewer and forgotten.

71 points by lordgilman 7y ago

A colleague told me an anecdote tangentially related. He was working on a service and managed to hack together some code that barely worked. His manager came around and a conversation like this unfolded. Manager: How is your project going? Engineer: Pretty well, I got something working. Manager: Excellent! We have a meeting with a VP tomorrow and we want you to do a demo. The lesson learned was to be careful and under optimistic about how you communicate to leadership.

chooseaname 7y ago
I've seen X-Language shops write PoCs in different languages only to end up with those PoCs in production and a kludge layer between the PoC code and the normal X-language layer. I've seen people nail down the complete UI first only to spend umpteen sprint demos afterwards explaining why a "fully functional" UI can't be put into production yet to angry management. No matter how hard you try, you can't explain an iceberg to a management staff that wants the project to start earning money already. > The lesson learned was to be careful and under optimistic about how you communicate to leadership. Yes. Some people have to learn this the hard way. I would add, don't try and be sneaky either (ie: using different languages, etc.).
- hinkley 7y ago
  The worst part about demo code like that is you have to code review every single line to make sure that the entire UI is using real data now and not some placeholders embedded in a function or the UI. We had someone go way down that rabbit hole once and I had to tell the manager that we don’t and can’t know how long it will take to ship this, because the entire thing is a fiction.

z3t4 7y ago

If the code is any good, it will be rewritten. Or it's perfect. Bad code however, no one want to touch it.

Ididntdothis 7y ago

Having seen too many times how throwaway code and proof of concepts went into production I try to always write decent code. You don’t need all the bells and whistles but just give things decent names, put repeated stuff into functions, avoid memory leaks, define constants and so on. It also reduces cognitive overhead. A lot of people seem to spend a Lot of energy thinking about whether a project needs proper coding or not.

hinkley 7y ago
There was a time where this got so bad at one company, that I was getting neurotic. To put an order of magnitude on it, my mentor got fired for calling out his boss on some of the demo-ware shipping bullshit. Before this all came to a head, I started doing proof of concept work as command line only. This allowed me to give them estimates they had to listen to, instead of them just assuming that because they could see a UI that we could just pretty it up and ship it next month. Clearly, they reasoned (as if anything they did resembled reason) my two to three month estimate was sandbagging and it was okay to tell the customer we’re almost done.
- hinkley 7y ago
  I fear I have given a false impression by saying 'he was fired'. John, let's call him, was summarily fired. GTFO. And in an early morning meeting, no less. I got to hear it from the coworker who was best at deadpan jokes, so I didn't believe him the first time when I asked, "Did I miss anything?"
avetisk 7y ago
I totally agree! Most of the time you just needed that little effort to keep things neatly and tightly together. No need to separate it: we just need to keep the minimal good habits all the time!
heavenlyblue 7y ago
That's one of the key reasons why I hate when people say they can "develop" in <insert your average text editor>. In an IDE I can quickly type out a full function body with 1-character variable names, then run it and see what happens. Immediately after I have seen it work I can go back and rename all of the variable names into something more descriptive. This is also easier now because you know exactly what the variables are used for. You can do the same immediately for constants (most of the IDEs will allow you to "extract the given expression as a constant on the module level" or alike). This can never work in a text editor because you need to know how that specific 1-letter tokens. There is no reason to write non-descriptive code unless you're trying to save maybe 5% of your time. At a job where timelines can easily go orders of magnitude higher than expected, you're trying to shave off a minor portion of your net time spend...

avetisk 7y ago

I think there are 2 cases in real world scenario: 1) either you have the habit, energy and time to systematically rewrite your code properly through iteration; 2) or you are so good that your average throwaway code is considered not that bad. Because mostly either we are going through well known paths which leads to case 2) or we’re exploring new things and being “skilled & experienced developers” we manage to have the right habits, energy and time to build things iteratively ending up in case 1). If in the end we still have trashy code, then we need to ask ourselves if we are lacking any of the following: skills, energy, time or good habits (or a proper context, but that’s a whole other universe of problems).

ChrisMarshallNY 7y ago

I write every line of code as if it were going out the door. But that's actually a fairly good idea (use a different language).

axegon_ 7y ago

> make sure the people using throwaway code understand that even though it kind of looks like it works, it cannot be maintained and must be rewritten I couldn't agree more with this. Not that long ago I inherited a project which on the surface looked shiny and nice. I was however aware that it was a mess underneath. Mind you, I was completely unprepared for the utter crap that awaited me. In all fairness it is the worst thing I have ever seen by light years. It took me two almost 2 weeks to find where a bug was coming from (it was written in a way which no debugger could trace it back, no logs, everything was surprised). After fixing it eventually, I decided to scrap it and build the whole thing from scratch. At the end it took me just over a month (Saturdays and Sundays included) and another 2 weeks from another developer to get a replacement project from an empty file. And here are the two painful truths about the whole endeavour: it took us collectively under two months to build, document, test, and run it in production. A grand total of around 20-30k lines of code. It took the people before us 3 and a half years to make their version which was anti patterns, top to bottom and in those 3 years the company invested around half a million Euros in salaries alone. If argue that this is the most painful thought. Not even the fact that this has been my first weekend this year in which I'm actually relaxing and not working. So my word of advice-if you end up in a similar situation, scrap everything, do it from scratch. Take a piece of paper, write down the business logic, draw a diagram of the structure of your application around it, pick the most appropriate stack and go for it. Avoid shiny new toys, profile everything and remember that sometimes it's better to let an application crash in order to find it's weaknesses.

Swizec 7y ago
It’s easier to build something once you know what you want than it is while you’re discovering what you want. We’re dealing with similar at work now. Over 5 years a system was built. It works and the code is crap. Now I’m pushing management to please just decide “Yes, this is what we wanted all along” so we can throw out 90% of the code
- axegon_ 7y ago
  > It’s easier to build something once you know what you want than it is while you’re discovering what you want. Oh absolutely. Thing is, in my case, what was needed was clearly defined since the beginning. It's the "developers" who built it who were incompetent af.

dimtion 7y ago

That might work for video games, but in a web company I've seen so many throwaway bash, perl or python scripts wrapped in an `system(*command)` that are unmaintainable and sometimes cause RCE or injections bugs. I feel that this advice only fixes the symptoms and not the underlying root cause. This is a culture issue, not a technical issue.

codr7 7y ago

It's not a black/white thing, really. My code tends to be somewhat repetitive and terse while exploring new ideas. Once I know where I'm going I'll gradually refactor and spell things out to the level I'm aiming for, which is different depending on context. Polishing code that should never go anywhere is a waste of life, and once you've spent all that effort it's more difficult to keep an open mind about the design.

3fe9a03ccd14ca5 7y ago

I find throwaway code to be freeing and fun. I don’t have to worry so much about making the perfect abstraction, or some DRYness optimizations. I’ve also had my share of throwing making it into production. The secret is keeping it simple. Simple code can always be optimized later. It can always be optimized if it’s simple. Besides, the junior developers need something to bust their chops on anyway right? Often times when someone takes over the project I’ve already listed in the library and in comments what can and should be improved.

symplee 7y ago

Similar to the infamous: "temporary" workarounds...

4ndrewl 7y ago

All of your code will be thrown away.

rzimmerman 7y ago

If your “throwaway” code works fine in production for years without any active maintenance and the only down side is that it needs a rewrite five years later, was it really that bad? Or is it the exact thing tech debt refers to - borrowing future time to work on what’s important? If I had to make a point it would be that there’s no line between code that needs to be replaced right now and code that is perfect and lasts for decades - it’s a spectrum and circumstances influence your tolerance.

hinkley 7y ago
The flip side of this is people who get sunk cost fallacy around that throwaway code. Rewriting a piece of code that’s been in use for two, three years doesn’t invalidate its existence. It wasn’t necessarily a mistake for it to be written that way. It is a mistake to keep on using it, though. I think maybe it’s similar to the way we misuse the term “crutch”. If you have a broken leg use the damn crutches. When your leg heals and you sell the crutches, don’t castigate yourself or anyone else about how useless crutches are. You used them. Past tense. That’s done now, and you’re moving on.

hinkley 7y ago

There was an interview posted here last week about tech debt, and the speaker mentioned that if you compartmentalize throwaway code properly it can be kind of liberating. I don’t know that I’ve seen that in the wild, but it sounded plausible. Instead, he claimed, the only important part of that code - at all - were the interfaces. So save your design that part well and for the rest, save your energy. I have seen flavors of the latter work out, especially when you combine the idea of riskiest thing first (also last week) with reversible decisions and only decide today on things that have to be decided now. For things that are easy to change, make an arbitrary selection and keep moving. For everything else, play for time and hope that new information will improve those decisions.

lmilcin 7y ago

I use a different framework for throwaway code. For example, my current prod application I work on uses Apache Storm and Kafka Streams, my throwaway code is written with Eclipse Vert.x. I tend to use bottom up approach when I start by writing small bits and pieces of utility functions, tools, etc. and I build a larger proof of concept based on that. Typically, the top level of the application is pretty dirty and changes constantly while I spend time to get the bottom of it correct right from the start. I use the top level of the application as a kind of test framework for the bottom parts. Then when the time is right, I throw away the top of the application and build the new one using some of the tools I have already developed. I would love to do my throwaway code in Clojure but writing it in the same language as my production application lets me gain more knowledge, faster, and already have some stuff ready when I get to write the main part.

daxfohl 7y ago

I haven't written a prototype in forever. I don't find them effective. And they typically take way longer than you expect at the outset. Do some wire charts or graphics and present those. It's far more boring to do than writing a prototype, and learning design tools is cumbersome, but they allow you to demo things better to executives, redraw stuff on the fly in meetings, copy and paste to a document or slideshow, share with external parties, and people don't get hung up on minutae that come with presenting a prototype. Stakeholders far prefer seeing a well thought out document or slideshow than a dinky fake app. Once you get signoff on the design and flow, then jump straight into the real code, skip the whole prototype step. I'd rather be coding, but sometimes it's just not the most efficient use of my time.

mstibbard 7y ago
Do you use any specific tooling to help with this?
- daxfohl 7y ago
  My primary tools are actually Photoshop and PowerPoint. Lame I know, but they have served me well over the years. Actually, hadn't thought much about it before, but being proficient at these two tools might be just as valuable to me as coding skills.
  - loopz 7y ago
    Krita's become mature over the years.

arendtio 7y ago

I like to have a folder called playground within my projects, where I build related prototypes and try out new ideas. Whenever something seems to work well, I do some sort of cherry-picking to keep the things I got right within the prototype and rewrite everything else. This helps me to validate ideas while keeping the main project in good shape. It is not as extreme as choosing a different language for the prototypes, but for me, it worked well so far.

TeMPOraL 7y ago

A related idea: use not just a different language, but a completely different toolset. At my last job, I prototyped half of the serious overhaul of a mid-sized product (backend and UI) in a bunch of ObservableHQ notebooks. It was all a pile of hacky JS, hastly-written over the course of a week, but it let me explore and showcase all the new product ideas and serve as a reference for my co-workers (and something to demo to the management), and at the same time there was no way it would ever end up in production. After all, it was all just a bunch of private notebooks on a third-party SaaS, and the presentation was explicitly following the notebook/document model instead of an application model. And, of course, our real backend wasn't written in JavaScript.

bobm_kite9 7y ago

I have the opposite problem - a lot of the code I think carefully about, factor correctly and ensure is thoroughly unit-tested spends about six months circling the plug-hole of tech demos and PoC before being sent to the bit-sewer and forgotten.