
Throwaway Code - lordgilman
https://blog.bencope.land/throwaway-code/
======
Ididntdothis
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.

~~~
harikb
Most people underestimate the value of refactoring existing code. Even a
prototype provides a good base to start the refactoring. Of course it will
help if the programming language helps with easy refactoring. In my projects,
I expect to refactor the code at least 3 or 4 times before it reaches a state
I am comfortable with.

IMHO, this is far better than _starting from scratch_. Both code and SQL are
meant to refactored. Don’t over-engineer from the beginning adding usecases we
know nothing about.

~~~
jniedrauer
Refactoring production code can be _very_ difficult. You often end up
constrained by the existing code's public APIs, cross-API data structures,
remote systems running the old code, etc. It's worth putting at least a little
bit of thought into maintainability, even in the prototype stage.

~~~
daxfohl
Especially if it's a project with multiple people working on it. Refactoring
will cause major merge problems for everyone doing anything else on those
files. And if your team does best practices with code reviews and testing,
then refactoring a chunk of code becomes a big project.

------
axegon_
> 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.

~~~
fralewsmi
Counter argument [https://www.joelonsoftware.com/2000/04/06/things-you-
should-...](https://www.joelonsoftware.com/2000/04/06/things-you-should-never-
do-part-i/)

~~~
robocat
“ Things You Should Never Do: They decided to rewrite the code from scratch.”
This is a great general rule.

The rule is situation dependant and some people can break it and succeed: the
parent comment was very clearly one of those situations.

The actual risk is that the majority of us think we can break the rule, when
it turns out we can’t. But a minority of people/situations can successfully do
a complete rewrite, success defined as where the gains abundantly outweigh the
pains.

~~~
dannypgh
My rule is be skeptical of anyone proposing a rewrite who doesn't fully
understand the existing system, to such depth that they would feel comfortable
refactoring it. Which means anytime someone says "we want to rewrite it
because refactoring it is too hard" I tend to not believe them.

There are times when rewrites are less total work, but they're hardly ever
"easier" when you account for the cognitive load of making sure the
requirements of the rewrite are being accurately captured. Maybe there's an
exception if you know the requirements have been drastically simplified, but I
doubt that's practically useful.

------
angarg12
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
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
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.

------
3fe9a03ccd14ca5
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.

------
lmilcin
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.

------
avetisk
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).

------
4ndrewl
All of your code will be thrown away.

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

------
rzimmerman
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
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.

------
arendtio
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.

------
dimtion
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.

------
daxfohl
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
Do you use any specific tooling to help with this?

~~~
daxfohl
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
Krita's become mature over the years.

------
hinkley
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.

------
TeMPOraL
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.

------
codr7
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.

------
ChrisMarshallNY
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).

------
bobm_kite9
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.

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

