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.<p>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.
> 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<p>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.
A colleague told me an anecdote tangentially related.<p>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.<p>Manager: How is your project going?<p>Engineer: Pretty well, I got something working.<p>Manager: Excellent! We have a meeting with a VP tomorrow and we want you to do a demo.<p>The lesson learned was to be careful and under optimistic about how you communicate to leadership.
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.<p>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?<p>Often times when someone takes over the project I’ve already listed in the library and in comments what can and should be improved.
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.<p>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.<p>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.<p>I use the top level of the application as a kind of test framework for the bottom parts.<p>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.<p>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.
I think there are 2 cases in real world scenario:<p>1) either you have the habit, energy and time to systematically rewrite your code properly through iteration;<p>2) or you are so good that your average throwaway code is considered not that bad.<p>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).<p>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).
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.
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.<p>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.
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.<p>I feel that this advice only fixes the symptoms and not the underlying root cause. This is a culture issue, not a technical issue.
I haven't written a prototype in forever. I don't find them effective. And they typically take <i>way</i> longer than you expect at the outset.<p>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.<p>Once you get signoff on the design and flow, then jump straight into the real code, skip the whole prototype step.<p>I'd rather be coding, but sometimes it's just not the most efficient use of my time.
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.<p>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.
A related idea: use not just a different language, but a completely different toolset.<p>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.
It's not a black/white thing, really. My code tends to be somewhat repetitive and terse while exploring new ideas.<p>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.<p>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.
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.