13 ms·

Throw away your first draft of your code

288 points by herbertl 3y ago

dools 3y ago
See also “Plan to Throw One Away” from the Mythical Man Month: https://wiki.c2.com/?PlanToThrowOneAway# https://wiki.c2.com/?PlanToThrowOneAway#
mav88 3y ago
Plan to throw one away. You will anyway. - Fred Brooks, The Mythical Man Month.
say_it_as_it_is 3y ago
Ship your first draft. Never rewrite. Go work on the next task.
- Scoundreller 3y ago
  First draft? Final draft. http://m.quickmeme.com/meme/3629ez http://m.quickmeme.com/meme/3629ez
  - zer8k 3y ago
    The agile mafia does not appreciate your sarcasm.
foxbyte 3y ago
The idea of prototyping to uncover 'unknown unknowns' resonates with me, it's like a reconnaissance mission before the actual project. This could indeed save a lot of time and effort in the long run...
- Mountain_Skies 3y ago
  Just never let management see the prototype or they'll consider it done and tell you to move on to something else.
  - shortcake27 3y ago
    In my experience, this is what actually happens. A developer makes a low-quality, low-effort prototype under the assumption it won’t ship. Someone sees it. It gets shipped. Everyone loses.
    - jstarfish 3y ago
      Sabotage your prototypes then. Have it reset its state every 5 minutes or deliberately leak memory.
      - gjvc 3y ago
        Sneaky move.... but then, in the eyes of some people, you might well appear not competent to put together a working system, so make sure you know your audience.
      - sodapopcan 3y ago
        Ya, this basically. It helps if you have tests because when prototyping, you can write things in a way which break tests and ideally break other features. It works enough that you can validate the one idea. That way it will never pass CI.
      - hyperthesis 3y ago
        They are cunning. You cannot sabotage it enough to fool them.
- vishnugupta 3y ago
  Reconnaissance mission is a great analogy. I think of it as scouting from the Age of Empires. Besides discovering unknown-unknowns it also helps in conveying design/idea to rest of the team.
  - hot_gril 3y ago
    Another war analogy was the Byzantine defense. Their policy was to avoid decisive, large-scale battles where a lot can go wrong at once. If an enemy army is incurring, first try to weaken or deter it with lighter forces that also gather intel. If they can't stop the threat, form and advance a larger army with a better-planned supply chain to stop it deeper in the territory. Which actually doesn't work so well in AoE. The game doesn't have a concept of army supplies, so you usually just want a huge unstoppable army you can send anywhere.
- hyperthesis 3y ago
  "tracer bullet" that shoots through all key parts of the system (agile terminology, I think).
3cats-in-a-coat 3y ago
Or maybe keep it and tell GPT to refactor it. Soon.
snailtrail 3y ago
[dead]
GMoromisato 3y ago
I'd rather do the Ship of Theseus thing and just harden the prototype as required, and only when faced with real-world evidence. The problem with rewriting is that sometimes you face second-system syndrome[1] where you overengineer everything. Believe me--it happened to me at Groove Networks after Lotus Notes (ask your grandparents about that). [1] https://en.wikipedia.org/wiki/Second-system_effect https://en.wikipedia.org/wiki/Second-system_effect
- fritzo 3y ago
  Yet I find when rewriting from scratch there's a countering force of simplification where I find myself thinking "We spent way too much complexity on that part, and we can entirely do away with that other part, and we turned out never to use features X and Y."
  - GMoromisato 3y ago
    Yeah, that makes sense too. I think it just boils down to "keep writing systems and you'll get better at it." But there's no bait on that kind of link.
  - bell-cot 3y ago
    > "...and we turned out never to use features X and Y." THIS. Often, the best way to start the rewrite is to go straight to the database, and start asking "what allowed values for all these fields have never actually been used?". EDIT: Whether it's rewriting, or refactoring, or adding some "if( Deprecated_Feature_Allow !== true ) ... ErrorDie( Feature_Deprecated )" logic here and there, or updating training material, or whatever - knowing that Software_Feature got ~zero real-world use is d*mned useful.
    - GMoromisato 3y ago
      Agreed--every software engineer I know loves deleting useless code. But this is not incompatible with refactoring instead of rewriting.
sambull 3y ago
Someone said that to me once.. I just accidentally always end up with it in production.
Jeff_Brown 3y ago
Justify wasteful things you've done and suggest them to others. Less cheekily -- it's true that sometimes the best way to research a topic is by writing code that you might appropriately throw away later. And it is extremely important to be able to recognize when something is not worth keeping. But also, often, the most efficient strategy is to think about the problem off-screen enough that you don't subsequently waste time on-screen writing things you won't keep. It seems strange to usually expect to throw away your first draft. Not every problem is that hard, and even for hard problems, not every first attempt is wrong.
- mtkd 3y ago
  Often happens that you can't see the next hill until you get to the top of the current hill
kleiba 3y ago
The temptation to throw away all of your code - be it a prototype or a "grown" code base - arises often. Often it is a bad idea. I get it, though, there is an inherent attractiveness in the idea of starting fresh from a clean slate. Except, more likely than not, you'll soon find yourself in a similar situation to the one you started from. The fundamental problem is that it is easy to underestimate the edge cases. Sure, the main functionality is easily understood and straight-forward to conceptualize. But did you remember to think through all the smaller aspects of your software, too? Perhaps it's easier with a prototype implementation that in fact doesn't have a lot of features yet, but to completely replicate the functionality of a complex piece of software isn't an easy undertaking. Sure, getting 80% there is probably easy, but the last 20% is the part that's easy to overlook when considering a complete rewrite. Admittedly, there's nothing sexy about refactoring. And often it may seem like it's less work to just simply scrap everything and start over. However, that's fallacy a lot of times.
- deleted 3y ago
  [deleted]
- m463 3y ago
  It says to throw it away after a couple of DAYS, which seems to differ from other advice (like from joel-on-software) Maybe this is ok, given that time period? or will the rewrite have all these extra bells and whistles? or will the rewrite throw away the unneeded bells and whistles?
  - HenryBemis 3y ago
    Ok, perhaps don't throw it away. When I come up with an idea (for an app usually), I use "a few" A4-sheets (anything between 5 and 20), scribble and draw on them with a pencil, draw screens, buttons, data flows, activities, write notes (in various font sizes). Then I use my CamScanner and call this a v1. Then email me the PDF and store the papers in a box, and a couple of days later I start the v2 (same process), then v3. By v4 it's 'good'. I also use the same method on my 9-5. I take VERY seriously the Abraham Lincoln quote “Give me six hours to chop down a tree and I will spend the first four sharpening the axe” on almost everything. I consider the v1, v2, v3 as the "sharpening the axe" and the v4 on the actual cutting. In that spirit, the article has a similar approach, as the v1, v2, and v3 may take you down an (more than) imperfect path.
sergioisidoro 3y ago
I've felt this, and I agree. It really pays of to do some work on technical discovery, make all the mistakes, see where all the design issues will be, validate as much as possible, and then start again. And the best way to really scope out requirements and get to know the "unknowns" is really to get your hands dirty. Especially when in comes to business logic and domain modelling, some bad decisions at the begining can cost a LOT, to undo in an iterative matter. (To clarify I'm talking about the timeline the author proposes of "a couple of days" build the throw away prototype)
paulddraper 3y ago
Aka "Build one to throw away"
deleted 3y ago
[deleted]
lxe 3y ago
Throw away 1st, second, third, etc... Write your code in small replaceable/disposable POCs until at some point the architecture and coherence starts to take shape. That's the advantage of software over other work. You have 0 material sunk costs. Unlike building a bridge, which you can't just tear down and iterate, with software you can develop a workflow where you break things and iterate quickly.
- tracker1 3y ago
  There are of course software systems with a very large bit of complexity and entrenchment... least of which the complexity added in order to avoid said entrenchment in the first place.
thescaleofit 3y ago
Exactly what I thought after GPT3.5 was released. "Delete it all. Start from scratch. You'll learn so much. You'll do so much better. You'll actually live up to the scale of your creations' potential." But a decision like that would be superhuman by itself, a transcendent experience, giving the creators a perspective that seems impossible. Unlike what is happening instead, both publicly and behind closed doors... A great pity!
orthecreedence 3y ago
I've never had luck with this approach. For me, iteratively building and changing the codebase as new requirements come up lends itself to having to think of good ways to modularize and future proof. The idea of throwing out the code and starting over is definitely appealing, but often the iterative approach gives me something I'm super happy with. I think I do use the throwaway approach with simple prototyping of smaller portions of code that I will then port into an existing system, but the overall system remains stable.
- moonchrome 3y ago
  If you're discovering requirements along with developing code you often end up with Frankenstein's monster because things that were intended to do one thing got retrofitted to do 4 more things. It works but if you had all 4 things in mind when designing the first approach it would have been much cleaner. And going forward it keeps getting worse.
davidkunz 3y ago
I like to build my first version in one file with as few abstractions as possible. No helper functions, unless absolutely necessary, just straight-forward code. Building good abstractions later on is a lot easier than starting with wrong ones in the first place.
- avgDev 3y ago
  Very interesting approach. As someone who has overengineered last major project I worked on......maybe this is the way. I got so fixated on getting it "right" using current standards and abstractions that it became a bit of a mess. I despise working with that code base now.
- hot_gril 3y ago
  This is an underrated way of doing things that I've come to appreciate over time. Heck, I'll even go live with the all-in-one-file thing until there's a reason to split it up. It's all peanuts anyway compared to bigger decisions like what API, DBMS, DB schema, other deps, libs, etc you use.
  - majikandy 3y ago
    Definitely agree, if it works (tests prove it works) it can go live.
- superb_dev 3y ago
  I'm gonna second this. Just build it first and add the abstractions as they become obvious
- krembanan 3y ago
  I've always done it like this as well. Initially I did it for the most obvious reason: it gave me the working software that I needed the fastest. Then later on, I always found it to be the best way to find natural abstractions as you go.
jchanimal 3y ago
I’m in the middle of this with my new database startup. The alpha was written to gather requirements, so I intentionally skimped on code quality as it could be a waste of time. Now that I know the domain inside and out, the beta rewrite is worth turning up the quality. And it’s so fast and easy to write, as the old code serves as api documentation for all the low level stuff it depends on. I recommend you do this too.
neverthe_less 3y ago
I've never respected this advice, even though I hear it often enough. The reasoning appears to come down to this: > If you know that you're possibly keeping the code, you do things in a "proper" way, which means moving slower combined with the idea that it's faster to redo work than it is to refactor. I don't buy either of these propositions as a universal rule. For the first, it seems that a mindset of avoiding premature optimization, which you should be cultivating anyway, is enough to ward it off. For the second, I see it as very context dependent, with my bias going towards refactoring instead of rewriting. I most often get things right enough the first time that it really only needs to be refactored going forward. Only when I end up with serious flaws do I decide to start over, often before I finish my implementation because the flaws are already apparent enough. Add to this that even very large changes can be refactored effectively and timely in my experience, and I feel like the bar for rewriting is really high to be cost-effective. Unfortunately this essay and many others seem to take objections like mine for granted, and I should just believe the author that rewriting is faster with zero supporting evidence.
- iraqmtpizza 3y ago
  looking for gaping security holes is premature optimization. if you run into security problems down the line, use a security profiler and find the hot spots i.e. radioactive code
  - programzeta 3y ago
    I think this depends greatly on the product area and ease of updating. Removing problems categorically from designs early has been valuable to me in the past to reduce surface area, avoid impossible refactoring, and eliminate systemic bug classes.
  - wizofaus 3y ago
    > looking for gaping security holes is premature optimization. I won't approve a PR if I notice such a thing (and if it really is "gaping" I'd expect an automated tool to flag it and fail the build anyway). I don't really see ensuring your code follows basic secure SDLC best practices as "optimisation" at all - in fact it often comes at a (hopefully small) cost of less than optimal performance. Of course there may be areas of software development (hobby projects etc.) where security is not a priority at all, but if it's code you're being paid to write that runs on the cloud or your customer's machines then security is absolutely worth getting right from the get-go.
darkmarmot 3y ago
I don't throw it away, I keep it as a reference. But for anything interesting, I might rewrite from "scratch" three times easily.
- fritzo 3y ago
  I've been following this flow where I write a few successive versions and perform refactoring steps to move one version "towards" another version, as if there is a conceptual force of attraction. It's often unclear which version will prevail, as if I'm acting out a genetic algorithm with a small population.
m463 3y ago
I can't load the page. https://web.archive.org/web/20230804183217/https://ntietz.com/blog/throw-away-your-first-draft/ https://web.archive.org/web/20230804183217/https://ntietz.co...
CollinEMac 3y ago
I've seen the theory that this is why changing to a new framework/language seems like magic so much of the time. That it's not so much the differences in the technologies as it is your knowledge of the problem. It's probably a little of both in reality but it's an interesting idea.
ChrisMarshallNY 3y ago
I have found that this kind of advice does not play well with managers (but it's actually not a bad thing to do). I'm fairly grateful that I've retired from the rodent rally, and am working at pretty much my own pace and structure. About six months ago, I tossed out the code for the frontend of a project that I'd been developing for over a year and a half (at that point). I distilled the business logic into an SDK, brought in a designer, and started over from scratch. The result is ten thousand times better than what we had (and were considering shipping), a few months ago.
Squarex 3y ago
I've found this great on my personal projects where I've had all the time I've wanted. The next iteration was always orders of magnitude better than the first. In the professional setting I find that the prototype is often enough and rewriting costs unjustified amounts of money.
avgDev 3y ago
I rewrote a mission critical application. The original app was something else. One function had 1500+ lines of code. It was the ugliest thing I have seen in my life. We wrote cleaner code in early college years. However, that code ran the business for 12 years with almost 0 modifications. People created work around for some stuff. Error handling was poor. But the goal was achieved and business continued to grow. I think devs in general sweat too much about code quality.
- refactor_master 3y ago
  > However, that code ran the business for 12 years with almost 0 modifications We have code like that, and it requires everything around it to twist and contort to comply with the beast of unmaintainable at the center of it all, simply because at this point it has so poor test coverage and is so incredibly mission critical now.
  - avgDev 3y ago
    Test coverage!? I don't think that word was in the vocabulary of the dev who wrote it :).
- wizofaus 3y ago
  > I think devs in general sweat too much about code quality I think if they sweated a little more then poor quality code wouldn't find itself into the codebase.
  - mplewis 3y ago
    Bad code doesn't usually come from lack of effort. It usually comes from business requirements that grow over time with deadlines attached.
    - wizofaus 3y ago
      It can still be a lack of effort put in trying to convince product managers etc that more time is needed! But almost all PRs I review have something in them that suggests the developer not putting as much thought/care into what they were doing as I'd like to see (and I'm just as capable of doing the same).
halfinvested 3y ago
Anecdote: I know a guy who works solo and throws every project away (usually games) at least five times, often more like ten. According to him, each iteration tends to go smoother and faster than the last. Edit: There’s probably some nuance to whether this approach is a good idea based on type of software, size of team, experience level, personal and/or team skill set, etc…
okamiueru 3y ago
This advice depends a lot on how your "first draft" was coded to begin with. The concept of "first draft" shouldn't exist as code. You design it properly, then you implement it properly. Now, if for some reason, and there are plenty of good ones, you cannot do the former, then sure, you pay that price by redoing some work. But, at that point, you do the same thing you should have done: you design it properly, then you implement your design. One could argue that implementing a first draft is a way of designing it. Which, I cannot imagine making sense unless you don't know what it is you want to end up with. Maybe if you're making computer games or other creative endeavors?
- hot_gril 3y ago
  > One could argue that implementing a first draft is a way of designing it. Which, I cannot imagine making sense unless you don't know what it is you want to end up with. Maybe if you're making computer games or other creative endeavors? It's when the problem itself has some ambiguity. Like, I design systems that other people and systems use within a large company. I try to figure out how they'll use them, but even they can't tell me exactly. New business requirements come in mid-design, etc. They might even cancel the whole project if something more important comes along. In that situation, it's best to get some MVP as quickly as possible then iterate on it. Later iterations might totally scrap and rewrite the internals, which is fine if the API sticks.
  - okamiueru 3y ago
    That makes sense. Like a prototype you hand out so that you can figure out what it is you/client actually want. I don't think of those as first drafts though. Maybe it's a language barrier thing for me.
    - hot_gril 3y ago
      First draft could mean a lot of things. If you mean something you write then rewrite before it's ever released, the same still kinda applies. You might be mid implementation when something changes and ruins whatever structure you had. Or maybe the abstractions aren't very obvious at first even if nothing is changing.
AtNightWeCode 3y ago
I think the author mixed up prototyping with proof of concept. A POC should be tossed out. I think most companies expect at least the senior devs to be able to write a feature on first try.
EdSharkey 3y ago
The psychology of knowing ahead of time you'll delete all the code is interesting. Devs would be in hack-hack-hack mode and not worry about design - the goal is just explore all the territory to find the hilly parts and landmines. Move as quickly as possible and report back. In general I think developers value their code too much and should be willing to scrap and rewrite, especially whenever requirements are changing. I chalk it up to everyone's desire to conserve mental energies due to not understanding what their energy peak/limits are.
hackan 3y ago
I really like this idea, I'm often prototyping, but since I do it on my own, it is not throwable, so I tend to keep longer as they explain.
nine_k 3y ago
«In most projects, the first system built is barely usable....Hence plan to throw one away; you will, anyhow.» Fred Brooks, The Mythical Man-Month 1975, fourty eight years ago, but worth repeating sometimes.
jpswade 3y ago
I like the idea of “Spike and Stabilise”. Which means, prototyping in this way, but at the point it is actually delivering value, stabilise. Of course, it’s never as simple as that, but there’s certainly a place for this technique.
varispeed 3y ago
I try to structure my code so that it can be easily tested and it is modular enough so that you can swap implementations with fair ease. This means I can iterate much quicker - I can have code that works and is good enough for now and I can later on improve it and also I can suitable test coverage that can confirm the new improved implementation works as expected. Code that is organised this way is also rather easy to understand and test perform a function of documentation - which means someone else can get familiar with it and work in a short period of time.
myth2018 3y ago
Currently I'm writing mostly C and C++ and I find it very useful to write prototypes, either in the target language or in Python, to experiment with ways to modularize the code and how the modules will communicate. I only disagree with throwing the code away. On the contrary, sometimes I even use the last prototype as a sort of "executable documentation". That strategy indeed saves me a bunch of time. However, at least in my experience, I didn't have success applying that to modern front-end dev: the complexity is frequently so high and the dead-ends are so numerous that I prefer to buckle-in for the rough ride and proceed to the code right away.
stormdennis 3y ago
Not on this scale but it has happened to me on a few occasions that I've lost several hours work for some reason (including no autosaves). After the initial despair I know from experience I need to quickly try and recreate what I've lost while it's fresh in my mind. It takes much much less time and I always feel that I've done a cleaner job second time around. At times like that has occurred that this is the way to do it but I've never been able to bring myself to adopt this as policy.
jes5199 3y ago
yeah but I often end up getting Second-system effect https://en.wikipedia.org/wiki/Second-system_effect https://en.wikipedia.org/wiki/Second-system_effect
Tade0 3y ago
I have a similar process, but I do it after hours because I treat it as exercise. The task isn't about what the resulting system does, but how - the aim is to figure out where certain patterns are applicable and where they break down. Ideas include: using a design pattern like Entity Component System, exploring whether a certain way of formatting code is actually more readable, producing a drop-in replacement for a small utility. I firmly believe this makes you an overall better programmer. That being said I think it would be wise to refrain from doing that at work.
- progmetaldev 3y ago
  This is the exact technique I used that made me a better developer. I would take on the task of rewriting code in my own time (small team where my rewrite didn't affect others). There were times where I misjudged how difficult the rewrite was, but I stuck with it and took it as a learning experience to make sure next time I thought things through further before moving ahead with a complete rewrite. Now that I'm more experienced, I tend to get more important (and difficult) projects, and no longer attempt the large scale rewrite. I do definitely throw away portions of code and rewrite, though. I think there's a balance to achieve.
karmakaze 3y ago
I've always called this the "green-path prototype", which is building what you thought you knew, without implementing edge cases. The edge cases will get discovered and noted along the way and they should be documented (with a comment or other method that doesn't get lost). Pretty much any time you only handle a subset and don't handle the 'else's. The real implementation should consider the green-path and edge case notes, decide the desired structure/decomposition and pick and choose from the green-path rather than try to start with it as v1 of a final form.
HankB99 3y ago
I didn't read the article, but can guess at the rationale. I often wish I had the luxury of taking everything I learned writing something and then applying it when starting over. But IAC... I would much rather throw away someone else' code. :D
sodapopcan 3y ago
The funny thing is is that this is part of TDD (and extreme programming) that most detractors of TDD don't understand. I'm talking about the old "but if I don't know what I'm writing, how do I write a test first?" crowd. Well, the answer is this article. Write a quick prototype to answer unknowns, figure out a general plan, then throw it away and start with a single test. I emphasize "single" because there was that other article that made the front page a couple of months ago where the author described their "new found way" of doing TDD that made them actually enjoy it and then went on to describe regular plain ol' TDD.
coolliquidcode 3y ago
I think sometimes it's a good idea to use a language the company doesn't use internally to prototype. Like we don't use python or node in production, but a lot of stuff can be POCed in those languages/frameworks without a learning curve. It forces you to throw out the old code and forces you to think the problem out in different ways. Also, in my experience the POC does enough that it turns into just use POC because of the illusion that it would be faster to use than to rewrite. Then it's a span of time fighting edge cases and added features thought of afterwords till it passes all testing. Then you have a battle tested piece of code you can't get rid of, difficult to understand, and ridged for changes.
jimnotgym 3y ago
I see. A new generation discovers Extreme Programming!
nraf 3y ago
We do this occasionally as a tech spike - if there’s a lot of uncertainty or if we need to evaluate between a couple different approaches, we’ll dedicate 2-3 days to hacking away with the aim of lifting the “fog of war”.
sideproject 3y ago
Well, maybe not throw away everything, but I understand the principle. There are also other areas where this could help - and one of them is "naming". Sometimes when you start a project, you don't really know what the best names are for things. Project name, repo name, service name etc. So you choose something that you think it's ok and you go ahead. As the project progresses, you realise you've named things wrong, but renaming is so annoying and tedious. Often we ignore the bad names because it doesn't seem significant. But names are how people burden their cognitive load (an example, we named our repo after planets rather than describing what the repo does - "acme-customer-module-frontend" but we named it "pluto" - now everyone has to remember what pluto is and make sure pluto is not neptune).
bandyaboot 3y ago
I don’t really see the need to commit to throwing my first iteration out. I do refactor pretty aggressively at the outset of a major project or code change though. It often takes me quite a bit of time before things really get off the ground because of this. The result is probably the same—that I’m paying a lot of attention to making sure I’m going down a good path.
treprinum 3y ago
You throw your first draft away, you go straight to the second-system effect: https://en.wikipedia.org/wiki/Second-system_effect https://en.wikipedia.org/wiki/Second-system_effect
microflash 3y ago
After seeing multiple "first drafts" going into production over years, I've internalised that they shouldn't be even presented as ready to be shipped until and unless a draft passes multiple refractors. If something is unknown, it is better to explore possibilities and prototype in a prior sprint before picking the actual implementation. Take your time to figure out unknowns before writing the code you intend to ship.
- pishpash 3y ago
  Management doesn't care about your perfect code. You won't get rewarded either.
danielovichdk 3y ago
Funny how Fred Brooks keeps repeating history. I am just watching as the young and optimistic learn the hard truth. Build one to throw away - mythical man month.
mattbis 3y ago
I have the observation:- first version is never the best it will work with bugs, then you iterate and improve structure and arch. The third is the best. No time to waste doing that.
toss1 3y ago
Go further. One test is worth ten thousand opinions. What are a thousand tests worth? Plan to build and deliver an expedient first version, then have a technical debt jubilee before building the second. Build v1 in the most reasonable expedient (including not-scaled-up) way to deliver a reasonably full first feature set. See how it runs, what the users like/dislike/need/want, where are the rough edges both externally & internally, what the load cases look like, on various components, etc. You'll find 80%-90% of your surprises with this. Now, use your quickly-won knowledge of your actual system to plan and build the durable and scalable version. Despite my intrinsic approach having always been about planning, generalizing, etc. (premature optimization?), I was fortunate enough to be in a situation in one startup where I decided to do this, and it worked out amazingly well. V1 got out fast, without worries about tech debt. Building the 2nd version based on actual knowledge and and the v1 tech debt jettisoned, allowed a 'real' version to get out faster and better. There may be some problems with mgt politics, and it interfered in the above product also, but it does have much to recommend it.
einpoklum 3y ago
Yeah, well, good luck convincing most manager I know to plan for a phase whose outputs get tossed away. They would really much rather the prototype code gets merged, and then just work. Not to mention the fact they never let you "do things more properly", if they can help it, because you are again wasting precious time which could be used to do other work from the ever-growing backlog. As for my own projects - if I both "write things more properly" and divide them into small parts, it's easier to just keep the code I wrote for doing whatever it is I had it do; and maybe at some point collect enough of that to make a library, or at least a reusable header.
Havoc 3y ago
Not sure that level of absolute is the way to go. If you build a prototype and happen to nail it then why not iterate? Or perhaps you wrote a prototype and specific components/module feel sound? Authors suggestion feels sound as a question you should ask yourself & seriously consider, more than a strict principle.
extr 3y ago
As an ML-focused python dev I have never been able to break the habit of REPL-driven development, but I find it works really well for "building code that works" rather than coming up with a tower of abstractions immediately. A typical python development workflow for me is: * Start with a blank `main` file and proceed linearly down the page, executing as I go. * Gradually pull out visually awkward chunks of code and put them into functions with no arguments at the top of the file. * If I need to parameterize them, add those parameters as needed - don't guess at what I might want to change later. * Embrace duplication - don't unnecessary add loops or abstractions. * Once the file is ~500 LOC or becomes too dense, start to refactor a bit. Perhaps introduce some loops or some global variables. * At all times, ensure the script is idempotent - just highlighting the entire page and spamming run should "do what I want" without causing trouble. * Once the script is started to take shape, it can be time to bring some OO into it - perhaps there is an object or set of objects I want to pass around, I can make a class for that. Perhaps I can start to think about how to make the functionality more "generalized" and accessible to others via a package. This is literally the only way I've ever found to be productive with green field development. If my first LOC has the word "class" or "def" in it - I am absolutely going to ripping my hair out 12 hours later, guaranteed.
- slim 3y ago
  by REPL here you mean jupyter notebook?
  - bogeholm 3y ago
    REPL = Read-Eval-Print Loop. So could be iPython or just plain `python` in general, can’t say what OP is using of course
    - paxcoder 3y ago
      [dead]
  - hughesjj 3y ago
    Not OP but I often code in the REPL for python as well. Sometimes I'll stub out my code and just drop into an interactive debugger where I'm writing the next section. In the python debugger, if you type `interact`, it'll give you the normal python repl. This combined with the `help` and `dirs` are super useful for learning new frameworks/libraries and coding with your actual data.
linsomniac 3y ago
Decades ago I spent a whole day adding a serious new feature to my software. Had the first version all polished up and ready, and through a misunderstanding with my version control software (probably RCS, maybe CVS, probably not SCCS), I lost that work. Like maybe I did a checkout instead of checkin, something like that. I went to bed quite annoyed. The next day I got up and started from scratch. The new implementation took me half a day, and was decidedly a better implementation. Fred Brooks turned out to be right.
trevortheblack 3y ago
Oh FFS. Writing code is like writing natural language. It's editing that counts. Not the first draft. Whether or not you should throw out your first draft is in proportion to its value at getting you to the final draft. Not some axiom you thought of for a specific use-case and specific code base
waffletower 3y ago
Another untenable programming ethic used as a clickbait title.
waffletower 3y ago
The article describes a potentially useful exercise that might be explored by an organization that has allotted development time for a hack-a-thon or some such. Depending on the size and scale of the projects that a software team typically develops, a more realistic approach might be to spend smaller and more manageable chunks of time as a team evaluating recently developed features/services/apps and directly applying improvements gleaned into the planning of subsequent projects.
erksa 3y ago
Similarly why hackathons are so surprisingly successful in creating projects that would be otherwise doomed if estimated and planned out before hand.
andirk 3y ago
> Organize hackdays! We do these at work, and they're a source of a lot of the ideas for and prototypes of major features that get into our product. When a feature comes out of one of these, it's already vetted and prototyped. As someone who wins most of the hackdays, I agree that the original hackday code needs to be rewritten. I have seen too many spaghetti Frankensteins to allow quickly written code into a codebase.
marmot777 3y ago
A lot of writers do the exact same thing.
freehorse 3y ago
It feels as if a lot of this discussion happens between people who have a completely different context in mind where throwing all the prototyping code away may make more or less sense. For me, it is hard to think of a scenario of writing prototyping code for more a few days and not reusing at very least 10% of that code (with some modifications). I would be fine throwing away the 90% of it or sth, but the frustration having to rewrite parts that I had just written and threw away would be too much to bear. Even merely for reference, would make no sense for me to throw away.
simo7 3y ago
I have a different approach: I'm ok to throw away significant chunks of code as long as I have important new ideas that allow me to do more with less. Often the problem with refactors is that don't come with enough of these new ideas , there's no real progress, it's mostly moving things around.
amelius 3y ago
My boss doesn't allow me.
- majikandy 3y ago
  Only if you told them you were done, when you weren’t (if following an approach described in the article). I suspect the author also meant, it won’t take longer with this approach. Possibly even faster that without it is completely viable.
allenrb 3y ago
This would sound like questionable advice except that the best code I wrote in college resulted from an accident… I’d sat down all night and written some C for a graphics class. Everything was great, yay, victory. Proceeded to tar it up per class guidelines and did something like this: tar cvf assignment.c assignment.h data.txt readme whatever.cuz And as many of you no doubt recognize, I’d forgotten to supply a destination name before listing the source files. So the code was gone. My brain was gone, too, so I explained what happened and sent what I had, including a working executable, to the TA. He gave me an extra day to finish. So the next day I sat down and wrote it all again and as mentioned above, it was some of the best code I’d written. Doing it again from the top saved all sorts of dead ends and mistaken approaches.
- majikandy 3y ago
  This is exactly the type of story I tell when people are anti pair programming. I ask them if they’ve ever lost a days code (usually asking if they ever used source safe) and that when they finally knuckled down to write it again, it took about 20 minutes. As the writing the code wasn’t really the hard part or the bottleneck, solving the problem was the hard part. Hence pair programming having two heads on one problem to solve it better/faster, find the edge cases etc. Out of curiosity, was it really fast for you to do it in that extra day or did it take all day?
  - allenrb 3y ago
    Much faster the second time. Like you said, all of the problems came pre-solved. :-)
majikandy 3y ago
The famous comedian John Cleese speaks about this where he loses a script and has to rewrite it from memory before a deadline. Then he finds the old one and finds out his new one is much better despite thinking it was the same. So he started using it as a technique for better script writing. It is referenced here but I can’t find the video https://www.ideaconnection.com/right-brain-workouts/00186-john-cleese-on-creativity.html https://www.ideaconnection.com/right-brain-workouts/00186-jo...
- hyperthesis 3y ago
  I don't know why, but calling him a comedian sounds like an insulting put-down. He is a Python! (Maybe because, in this context, python excels at rapid prototyping?)
comment_ran 3y ago
I'm not going to delete my .emacs file even though it is ugly, it just works.
wkjagt 3y ago
I just lost a first version of some assembly code I wrote on my Apple II through my own mistake: my code wrote to the part of memory where the assembler kept the source code. When it seemed to work (I hadn't noticed I'd lost my code yet) I saved this (corrupted) version of the code to my floppy, corrupting even the floppy. I had to write the same thing from scratch again, but this time with the full understanding of the problem in my head, and I think the rewritten version is better because of that.
sedatk 3y ago
I also discuss this in my book Street Coder in the section titled “Write it from scratch”.
LAC-Tech 3y ago
I feel like this a symptom of trying to design while you code instead of putting down the text editor and just designing your solution instead.
wruza 3y ago
If you know that you're possibly keeping the code, you do things in a "proper" way, which means moving slower. Put in all the exception handlers, all the log statements. Structure the code nicely, refactor things while you're in there, modularize them properly. After all, it's going to be reused. This is where it all comes from. You don’t have to throw away code if it doesn’t need refactoring, modularization and so on to satisfy that “reuse” mantra from the beginning. Healthy reuse comes in two flavors: - a copy of the code - a separate well-maintained, versioned and documented library Anything reuse-focused in between is mostly snakeoil not worth drinking and is often the reason why your code has so many intricacies in it that you have to perform “recon missions” before actual coding or estimating. You’ve built a dozen of poorly-documented ad hoc libraries into your project. There’s no surprise it may require a proper source code expedition to detect and recrystallize parts that a new requirement shattered this time.
- toasted-subs 3y ago
  Eh, don't get me started on how many people take a well known abstraction then build another abstraction on top of it. You already had the abstraction!
danielvaughn 3y ago
I take this to the extreme. Over the past 6 years I've thrown away...somewhere around 12-15 versions of my side project. Part of it is that my own requirements and opinions changed with each version, but another part of it is that I'm pathologically unhappy with my own work. So yeah, maybe throw away the first draft, but don't do what I did.
gregfjohnson 3y ago
Jon Bentley's classic column "Bumper sticker Computer Science" includes the following bumper stickers: [Brook's Law of Prototypes] Plan to throw one away, you will anyhow. Fred Brooks, University of North Carolina If you plan to throw one away, you will throw away two. Craig Zerouni, Computer FX Ltd., London, England Prototyping cuts the work to produce a system by 40 percent. Larry Bernstein, Bell Communications Research [Thompson's rule for first-time telescope makers] It is faster to make a four-inch mirror and then a six-inch mirror than to make a six-inch mirror. Bill McKeeman, Wang Institute
cratermoon 3y ago
I worked one place that missed a golden opportunity to build one to throw away. The short version is that the team formed and started working on the designated product, but very shortly after a VP-level exec got directly involved and started asking about where "his" product was. This was before I joined, so I'm not sure if the original direction was supposed to include this or if there was some management nonsense behind it, but the team had to quickly pivot and deliver something for this needy VP that was kind of sort of related to their stated goal. In any case, the programmers got their marching orders and rushed out something to satisfy the VP, then went back to focusing on their original goals. The real work overlapped, in technology and business function, with the rush goal. After they were done, they could have stepped back, taken a look at what they did to get it done, identify the shortcomings, missteps, and undesirable consequences of the decisions made for that work. They could have proceeded with the main work using all the lessons from the 'emergency' work, and avoided a lot of the problems they'd created in rush to production. Instead, they decided to build, or perhaps more accurately defaulted to building, the real product on top of the work they done for the rush job. After another six or eight months, the project was in serious enough trouble that programmers were leaving, and they ended up with an almost 100% turnover in engineers. The manager's response was to start micromanaging everything and set the team up for a death march to a predefined release date.
perilunar 3y ago
I'm a big fan of Gall's Law: "A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system." [0] I don't throw my first version away, I just start really simple and evolve it iteratively, making sure it works at each stage, and by the time it's done very little of the original code remains. 0. https://en.wikipedia.org/wiki/John_Gall_(author)#Gall.27s_law https://en.wikipedia.org/wiki/John_Gall_(author)#Gall.27s_la...
Benjammer 3y ago
What this post says: "throw away the first draft of your code" What every HN commenter is replying to: "throw away your code" -- I've written software professionally for 14 years and just last week I wrote code for ~3 days and then decided I was on the wrong track, and checked out main and made a totally new branch, spent ~1.5 days re-writing my feature in a totally different way. I had come to realize the new way would be easier to write, MUCH easier to test, and a bit more maintainable long-term. Nothing wrong with throwing away un-merged code if you decide that merging isn't the right decision, and feel you have learned valuable lessons to inform the re-write.
deterministic 3y ago
I have never done that in my (successful) 30+ year career. I usually start with a simple end-to-end skeleton implementation that works, and then step-by-step refine it to production quality. It’s simple. It works.
keepamovin 3y ago
Can I just pass my first draft through chat GPT because I wanna save my fingers.
SnoozingBoa 3y ago
As a designer (UX focused, but technical as well), I have put a lot of effort to study prototyping in sw context. I think prototype itself is fairly well understood as a noun, but how to approach the activity is not that well understood. I think it starts with what to prototype (scope/intent) and what to do with the outcome. This is where different viewpoints start to have their impact. It is very common mindset not discard anything that has been done. Some cognitive biases are likely in effect here. It is also common to attach additional intentions retroactively. E.g. it is totally ok to build UI prototype and to deviate drastically from the current state of things. Depends on the intention. Now, it is not hard to imagine a follow-up discussion that takes unfortunate turn at some point because the expectations for the activity does not match. The focus shifts from the main idea to defining what was not the idea. The value of the activity diminishes steadily. At worst, inexperienced prototypers might end up with a loundry list of changes to be done to meet the current state, confused about what just happened. I think the main point of the article is valuable: be ready to stop and throwaway your prototype. Use it smartly. Find things you want to validate or just see, then be immediately ready to throw it away. Do not project additional things on to it. Use that energy towards the ”real thing”. In the world of Figma/other prototypes there seems to float this idea that prototype has some fixed and standardized meaning. As an activity it has been bolted into different methodologies and tools, which is fine of course, but they are also taught, discussed and treates together with specs, requirements and other artifacts that serves different purpose. They communicate different things. That’s it. In the end it is about communication. I think the great power of prototyping makes it also hard to use to it effectively. Personally, I think the best part of building a prototype is to throw it away. It is a milestone, the end. Almost always a success.
aappleby 3y ago
No, don't do it. Practice continuous refactoring.
rvdginste 3y ago
Personally, I would never or rarely use the approach where some code is created and then thrown away. I think it is always better to first think and then do. With software development, I make the distinction between a functional analysis and a technical analysis. Functional is clarifying the actual business requirements. Technical is clarifying how to implement the new functionality into the system. During the technical analysis, you are supposed to check and update existing class diagrams, existing api specifications, and so on. Depending on the experience of the team you need to describe this in more or less detail. The technical analysis must be done by someone who has knowledge of the project. That someone should be aware of the quality of the data in the database, or (in case it is relevant) should explore this while doing the technical analysis. It would also be normal to check the source code while doing a technical analysis to see how things are currently working/built and where the new functionality can fit in. The reason for investing time in a technical analysis, is to start the implementation with much higher confidence and get a decent implementation from the first attempt. You must find a balance between the time you spend on technical analysis (without writing any code) and the time you spend on the implementation itself. Spending more time on the technical analysis should save more time on the implementation, but I am aware (and convinced) that some problems will only be found by creating the actual implementation. However, I am also convinced that these problems rarely require a fundamental change in the implementation that a rewrite is needed. In short, when thinking before implementing, the quality of the first implementation is high enough. Also, what is not clear to me from the article. The author mentions to have 1-2 highly skilled engineers create a first implementation. And the author likes to be one of those engineers. These engineers create a prototype and then throw it away. The engineer who created the prototype now has an idea how the code must be implemented. How is that information communicated to the (lesser skilled?) engineer who must then implement the new feature?
tpoacher 3y ago
IIRC, Michael Feathers calls this "Scratch Refactoring" in his "Working effectively with Legacy Code" book from 2005. Excellent read even today.
mikhailfranco 3y ago
If waterfall is: specify-design-code-test Then agile TDD with prototype and discard/refactoring is: specify-test-code-design-recode A POC is different from a prototype. A POC helps to define the problem space, but it may also suggest a better initial design (identify useful abstractions): poc-specify-test-design-code
Arch-TK 3y ago
Honestly for smaller projects I just keep throwing it away until I can write it again in a day and it's as simple as it can possibly be. Although I don't always remember to do this.
hyperthesis 3y ago
...you will anyway (Brooks) IMHO Write it once for the problem; again for the solution. TFA stresses: finding out what you're building; finding the "unknown unknowns" (the things you don't even know you don't know, encountering those problems) TFA doesn't say it this way, but I think the fun of throwaway-prototyping is your thoughts can focus uninterrupted on the problem, undistracted by secondary issues. You can hack-around tedious parts, now knowing they are there; and you can get absorbed in the genuinely tricky parts, unobscured (even if you don't succeed, you also know they are there). You're not expected to get it all right. It's turning an unexperienced developer (on this problem) into an experienced one. PS Somewhat disturbingly, Brooks went back on this according to this interview https://www.computerworld.com/article/2550685/the-grill--fred-brooks.html https://www.computerworld.com/article/2550685/the-grill--fre... "you should plan to throw one away. You will anyway." That was the first edition of The Mythical Man-Month. In the second edition, I say that was misguided! You ought to plan to continually iterate on it, not just build it, throw it away and start over. Some of the things I said in 1975 were wrong, and in the second edition, I correct them.
atleastoptimal 3y ago
This maxim could apply to any skill based project. The skills needed to do something properly require first doing it from start to finish improperly. That's why a safe staging environment for skill development is essential to improving at anything.
jasfi 3y ago
I'd have to be very new to something to throw away the first draft of my code. My goal is to have to change the code I write as little as possible.
dave_sid 3y ago
Or refactor it
tacker2000 3y ago
What a load of nonsense. Iterative code refactoring is the only right approach. Why spend time writing code and then throw it away?? That makes no sense at all. Best approach would be to spend some time thinking and conceptualizing BEFORE writing the first line of code.
- lioeters 3y ago
  For me, writing code is a way of thinking, and often the best way of thinking about a problem or question, or to start conceptualizing an entire project, is to write some running code as a sketch, a rough draft, a prototype. If it has any merit, the running code informs the planning and decision-making process, stimulates thought and discussion. Parts of the draft, or even the whole thing, can be transformed, rewritten or refined, and become the basis of the solution and product. Of course it depends on the goal and nature of the question. Sometimes it's better to talk and think things through in human language, deeply and thoroughly, before writing any code. It could be that the best solution is no code at all, to use an off-the-shelf product or service. About "throwing away" code.. Imagine a musician with thousands of hours of playing, practice, informal or private performances and recordings - including piles of sketches and rough drafts that will never see the light of day. Only the best selection will be curated for the public, to make it into the final product. But the 99% that are "thrown away" was not a waste of time, they were a necessary part of the creative process to achieve the good stuff.
ryukoposting 3y ago
This is an idea I've preached for a while now. Software requirements, goals, deadlines- all that stuff can be planned. Even the architecture can be sketched out. But, for any sophisticated piece of software, you'll never get the actual code right the first time. If you think it's right, dig deeper. Find everything that's wrong with it, and do it again with those problems fixed. Great software and great art have one thing in common: the best version is never the first.
mock-possum 3y ago
First do it - then do it right - then do it better.

288 points by herbertl 3y ago

See also “Plan to Throw One Away” from the Mythical Man Month: https://wiki.c2.com/?PlanToThrowOneAway# https://wiki.c2.com/?PlanToThrowOneAway#

mav88 3y ago

Plan to throw one away. You will anyway. - Fred Brooks, The Mythical Man Month.

say_it_as_it_is 3y ago

Ship your first draft. Never rewrite. Go work on the next task.

Scoundreller 3y ago
First draft? Final draft. http://m.quickmeme.com/meme/3629ez http://m.quickmeme.com/meme/3629ez
- zer8k 3y ago
  The agile mafia does not appreciate your sarcasm.

foxbyte 3y ago

The idea of prototyping to uncover 'unknown unknowns' resonates with me, it's like a reconnaissance mission before the actual project. This could indeed save a lot of time and effort in the long run...

Mountain_Skies 3y ago
Just never let management see the prototype or they'll consider it done and tell you to move on to something else.
- shortcake27 3y ago
  In my experience, this is what actually happens. A developer makes a low-quality, low-effort prototype under the assumption it won’t ship. Someone sees it. It gets shipped. Everyone loses.
  - jstarfish 3y ago
    Sabotage your prototypes then. Have it reset its state every 5 minutes or deliberately leak memory.
    - gjvc 3y ago
      Sneaky move.... but then, in the eyes of some people, you might well appear not competent to put together a working system, so make sure you know your audience.
    - sodapopcan 3y ago
      Ya, this basically. It helps if you have tests because when prototyping, you can write things in a way which break tests and ideally break other features. It works enough that you can validate the one idea. That way it will never pass CI.
    - hyperthesis 3y ago
      They are cunning. You cannot sabotage it enough to fool them.
vishnugupta 3y ago
Reconnaissance mission is a great analogy. I think of it as scouting from the Age of Empires. Besides discovering unknown-unknowns it also helps in conveying design/idea to rest of the team.
- hot_gril 3y ago
  Another war analogy was the Byzantine defense. Their policy was to avoid decisive, large-scale battles where a lot can go wrong at once. If an enemy army is incurring, first try to weaken or deter it with lighter forces that also gather intel. If they can't stop the threat, form and advance a larger army with a better-planned supply chain to stop it deeper in the territory. Which actually doesn't work so well in AoE. The game doesn't have a concept of army supplies, so you usually just want a huge unstoppable army you can send anywhere.
hyperthesis 3y ago
"tracer bullet" that shoots through all key parts of the system (agile terminology, I think).

3cats-in-a-coat 3y ago

Or maybe keep it and tell GPT to refactor it. Soon.

snailtrail 3y ago

[dead]

GMoromisato 3y ago

I'd rather do the Ship of Theseus thing and just harden the prototype as required, and only when faced with real-world evidence. The problem with rewriting is that sometimes you face second-system syndrome[1] where you overengineer everything. Believe me--it happened to me at Groove Networks after Lotus Notes (ask your grandparents about that). [1] https://en.wikipedia.org/wiki/Second-system_effect https://en.wikipedia.org/wiki/Second-system_effect

fritzo 3y ago
Yet I find when rewriting from scratch there's a countering force of simplification where I find myself thinking "We spent way too much complexity on that part, and we can entirely do away with that other part, and we turned out never to use features X and Y."
- GMoromisato 3y ago
  Yeah, that makes sense too. I think it just boils down to "keep writing systems and you'll get better at it." But there's no bait on that kind of link.
- bell-cot 3y ago
  > "...and we turned out never to use features X and Y." THIS. Often, the best way to start the rewrite is to go straight to the database, and start asking "what allowed values for all these fields have never actually been used?". EDIT: Whether it's rewriting, or refactoring, or adding some "if( Deprecated_Feature_Allow !== true ) ... ErrorDie( Feature_Deprecated )" logic here and there, or updating training material, or whatever - knowing that Software_Feature got ~zero real-world use is d*mned useful.
  - GMoromisato 3y ago
    Agreed--every software engineer I know loves deleting useless code. But this is not incompatible with refactoring instead of rewriting.

sambull 3y ago

Someone said that to me once.. I just accidentally always end up with it in production.

Jeff_Brown 3y ago

Justify wasteful things you've done and suggest them to others. Less cheekily -- it's true that sometimes the best way to research a topic is by writing code that you might appropriately throw away later. And it is extremely important to be able to recognize when something is not worth keeping. But also, often, the most efficient strategy is to think about the problem off-screen enough that you don't subsequently waste time on-screen writing things you won't keep. It seems strange to usually expect to throw away your first draft. Not every problem is that hard, and even for hard problems, not every first attempt is wrong.

mtkd 3y ago
Often happens that you can't see the next hill until you get to the top of the current hill

kleiba 3y ago

The temptation to throw away all of your code - be it a prototype or a "grown" code base - arises often. Often it is a bad idea. I get it, though, there is an inherent attractiveness in the idea of starting fresh from a clean slate. Except, more likely than not, you'll soon find yourself in a similar situation to the one you started from. The fundamental problem is that it is easy to underestimate the edge cases. Sure, the main functionality is easily understood and straight-forward to conceptualize. But did you remember to think through all the smaller aspects of your software, too? Perhaps it's easier with a prototype implementation that in fact doesn't have a lot of features yet, but to completely replicate the functionality of a complex piece of software isn't an easy undertaking. Sure, getting 80% there is probably easy, but the last 20% is the part that's easy to overlook when considering a complete rewrite. Admittedly, there's nothing sexy about refactoring. And often it may seem like it's less work to just simply scrap everything and start over. However, that's fallacy a lot of times.

deleted 3y ago
[deleted]
m463 3y ago
It says to throw it away after a couple of DAYS, which seems to differ from other advice (like from joel-on-software) Maybe this is ok, given that time period? or will the rewrite have all these extra bells and whistles? or will the rewrite throw away the unneeded bells and whistles?
- HenryBemis 3y ago
  Ok, perhaps don't throw it away. When I come up with an idea (for an app usually), I use "a few" A4-sheets (anything between 5 and 20), scribble and draw on them with a pencil, draw screens, buttons, data flows, activities, write notes (in various font sizes). Then I use my CamScanner and call this a v1. Then email me the PDF and store the papers in a box, and a couple of days later I start the v2 (same process), then v3. By v4 it's 'good'. I also use the same method on my 9-5. I take VERY seriously the Abraham Lincoln quote “Give me six hours to chop down a tree and I will spend the first four sharpening the axe” on almost everything. I consider the v1, v2, v3 as the "sharpening the axe" and the v4 on the actual cutting. In that spirit, the article has a similar approach, as the v1, v2, and v3 may take you down an (more than) imperfect path.

sergioisidoro 3y ago

I've felt this, and I agree. It really pays of to do some work on technical discovery, make all the mistakes, see where all the design issues will be, validate as much as possible, and then start again. And the best way to really scope out requirements and get to know the "unknowns" is really to get your hands dirty. Especially when in comes to business logic and domain modelling, some bad decisions at the begining can cost a LOT, to undo in an iterative matter. (To clarify I'm talking about the timeline the author proposes of "a couple of days" build the throw away prototype)

paulddraper 3y ago

Aka "Build one to throw away"

deleted 3y ago

[deleted]

lxe 3y ago

Throw away 1st, second, third, etc... Write your code in small replaceable/disposable POCs until at some point the architecture and coherence starts to take shape. That's the advantage of software over other work. You have 0 material sunk costs. Unlike building a bridge, which you can't just tear down and iterate, with software you can develop a workflow where you break things and iterate quickly.

tracker1 3y ago
There are of course software systems with a very large bit of complexity and entrenchment... least of which the complexity added in order to avoid said entrenchment in the first place.

thescaleofit 3y ago

Exactly what I thought after GPT3.5 was released. "Delete it all. Start from scratch. You'll learn so much. You'll do so much better. You'll actually live up to the scale of your creations' potential." But a decision like that would be superhuman by itself, a transcendent experience, giving the creators a perspective that seems impossible. Unlike what is happening instead, both publicly and behind closed doors... A great pity!

orthecreedence 3y ago

I've never had luck with this approach. For me, iteratively building and changing the codebase as new requirements come up lends itself to having to think of good ways to modularize and future proof. The idea of throwing out the code and starting over is definitely appealing, but often the iterative approach gives me something I'm super happy with. I think I do use the throwaway approach with simple prototyping of smaller portions of code that I will then port into an existing system, but the overall system remains stable.

moonchrome 3y ago
If you're discovering requirements along with developing code you often end up with Frankenstein's monster because things that were intended to do one thing got retrofitted to do 4 more things. It works but if you had all 4 things in mind when designing the first approach it would have been much cleaner. And going forward it keeps getting worse.

davidkunz 3y ago

I like to build my first version in one file with as few abstractions as possible. No helper functions, unless absolutely necessary, just straight-forward code. Building good abstractions later on is a lot easier than starting with wrong ones in the first place.

avgDev 3y ago
Very interesting approach. As someone who has overengineered last major project I worked on......maybe this is the way. I got so fixated on getting it "right" using current standards and abstractions that it became a bit of a mess. I despise working with that code base now.
hot_gril 3y ago
This is an underrated way of doing things that I've come to appreciate over time. Heck, I'll even go live with the all-in-one-file thing until there's a reason to split it up. It's all peanuts anyway compared to bigger decisions like what API, DBMS, DB schema, other deps, libs, etc you use.
- majikandy 3y ago
  Definitely agree, if it works (tests prove it works) it can go live.
superb_dev 3y ago
I'm gonna second this. Just build it first and add the abstractions as they become obvious
krembanan 3y ago
I've always done it like this as well. Initially I did it for the most obvious reason: it gave me the working software that I needed the fastest. Then later on, I always found it to be the best way to find natural abstractions as you go.

jchanimal 3y ago

I’m in the middle of this with my new database startup. The alpha was written to gather requirements, so I intentionally skimped on code quality as it could be a waste of time. Now that I know the domain inside and out, the beta rewrite is worth turning up the quality. And it’s so fast and easy to write, as the old code serves as api documentation for all the low level stuff it depends on. I recommend you do this too.

neverthe_less 3y ago

I've never respected this advice, even though I hear it often enough. The reasoning appears to come down to this: > If you know that you're possibly keeping the code, you do things in a "proper" way, which means moving slower combined with the idea that it's faster to redo work than it is to refactor. I don't buy either of these propositions as a universal rule. For the first, it seems that a mindset of avoiding premature optimization, which you should be cultivating anyway, is enough to ward it off. For the second, I see it as very context dependent, with my bias going towards refactoring instead of rewriting. I most often get things right enough the first time that it really only needs to be refactored going forward. Only when I end up with serious flaws do I decide to start over, often before I finish my implementation because the flaws are already apparent enough. Add to this that even very large changes can be refactored effectively and timely in my experience, and I feel like the bar for rewriting is really high to be cost-effective. Unfortunately this essay and many others seem to take objections like mine for granted, and I should just believe the author that rewriting is faster with zero supporting evidence.

iraqmtpizza 3y ago
looking for gaping security holes is premature optimization. if you run into security problems down the line, use a security profiler and find the hot spots i.e. radioactive code
- programzeta 3y ago
  I think this depends greatly on the product area and ease of updating. Removing problems categorically from designs early has been valuable to me in the past to reduce surface area, avoid impossible refactoring, and eliminate systemic bug classes.
- wizofaus 3y ago
  > looking for gaping security holes is premature optimization. I won't approve a PR if I notice such a thing (and if it really is "gaping" I'd expect an automated tool to flag it and fail the build anyway). I don't really see ensuring your code follows basic secure SDLC best practices as "optimisation" at all - in fact it often comes at a (hopefully small) cost of less than optimal performance. Of course there may be areas of software development (hobby projects etc.) where security is not a priority at all, but if it's code you're being paid to write that runs on the cloud or your customer's machines then security is absolutely worth getting right from the get-go.

darkmarmot 3y ago

I don't throw it away, I keep it as a reference. But for anything interesting, I might rewrite from "scratch" three times easily.

fritzo 3y ago
I've been following this flow where I write a few successive versions and perform refactoring steps to move one version "towards" another version, as if there is a conceptual force of attraction. It's often unclear which version will prevail, as if I'm acting out a genetic algorithm with a small population.

m463 3y ago

I can't load the page. https://web.archive.org/web/20230804183217/https://ntietz.com/blog/throw-away-your-first-draft/ https://web.archive.org/web/20230804183217/https://ntietz.co...

CollinEMac 3y ago

I've seen the theory that this is why changing to a new framework/language seems like magic so much of the time. That it's not so much the differences in the technologies as it is your knowledge of the problem. It's probably a little of both in reality but it's an interesting idea.

ChrisMarshallNY 3y ago

I have found that this kind of advice does not play well with managers (but it's actually not a bad thing to do). I'm fairly grateful that I've retired from the rodent rally, and am working at pretty much my own pace and structure. About six months ago, I tossed out the code for the frontend of a project that I'd been developing for over a year and a half (at that point). I distilled the business logic into an SDK, brought in a designer, and started over from scratch. The result is ten thousand times better than what we had (and were considering shipping), a few months ago.

Squarex 3y ago

I've found this great on my personal projects where I've had all the time I've wanted. The next iteration was always orders of magnitude better than the first. In the professional setting I find that the prototype is often enough and rewriting costs unjustified amounts of money.

avgDev 3y ago

I rewrote a mission critical application. The original app was something else. One function had 1500+ lines of code. It was the ugliest thing I have seen in my life. We wrote cleaner code in early college years. However, that code ran the business for 12 years with almost 0 modifications. People created work around for some stuff. Error handling was poor. But the goal was achieved and business continued to grow. I think devs in general sweat too much about code quality.

refactor_master 3y ago
> However, that code ran the business for 12 years with almost 0 modifications We have code like that, and it requires everything around it to twist and contort to comply with the beast of unmaintainable at the center of it all, simply because at this point it has so poor test coverage and is so incredibly mission critical now.
- avgDev 3y ago
  Test coverage!? I don't think that word was in the vocabulary of the dev who wrote it :).
wizofaus 3y ago
> I think devs in general sweat too much about code quality I think if they sweated a little more then poor quality code wouldn't find itself into the codebase.
- mplewis 3y ago
  Bad code doesn't usually come from lack of effort. It usually comes from business requirements that grow over time with deadlines attached.
  - wizofaus 3y ago
    It can still be a lack of effort put in trying to convince product managers etc that more time is needed! But almost all PRs I review have something in them that suggests the developer not putting as much thought/care into what they were doing as I'd like to see (and I'm just as capable of doing the same).

halfinvested 3y ago

Anecdote: I know a guy who works solo and throws every project away (usually games) at least five times, often more like ten. According to him, each iteration tends to go smoother and faster than the last. Edit: There’s probably some nuance to whether this approach is a good idea based on type of software, size of team, experience level, personal and/or team skill set, etc…

okamiueru 3y ago

This advice depends a lot on how your "first draft" was coded to begin with. The concept of "first draft" shouldn't exist as code. You design it properly, then you implement it properly. Now, if for some reason, and there are plenty of good ones, you cannot do the former, then sure, you pay that price by redoing some work. But, at that point, you do the same thing you should have done: you design it properly, then you implement your design. One could argue that implementing a first draft is a way of designing it. Which, I cannot imagine making sense unless you don't know what it is you want to end up with. Maybe if you're making computer games or other creative endeavors?

hot_gril 3y ago
> One could argue that implementing a first draft is a way of designing it. Which, I cannot imagine making sense unless you don't know what it is you want to end up with. Maybe if you're making computer games or other creative endeavors? It's when the problem itself has some ambiguity. Like, I design systems that other people and systems use within a large company. I try to figure out how they'll use them, but even they can't tell me exactly. New business requirements come in mid-design, etc. They might even cancel the whole project if something more important comes along. In that situation, it's best to get some MVP as quickly as possible then iterate on it. Later iterations might totally scrap and rewrite the internals, which is fine if the API sticks.
- okamiueru 3y ago
  That makes sense. Like a prototype you hand out so that you can figure out what it is you/client actually want. I don't think of those as first drafts though. Maybe it's a language barrier thing for me.
  - hot_gril 3y ago
    First draft could mean a lot of things. If you mean something you write then rewrite before it's ever released, the same still kinda applies. You might be mid implementation when something changes and ruins whatever structure you had. Or maybe the abstractions aren't very obvious at first even if nothing is changing.

AtNightWeCode 3y ago

I think the author mixed up prototyping with proof of concept. A POC should be tossed out. I think most companies expect at least the senior devs to be able to write a feature on first try.

EdSharkey 3y ago

The psychology of knowing ahead of time you'll delete all the code is interesting. Devs would be in hack-hack-hack mode and not worry about design - the goal is just explore all the territory to find the hilly parts and landmines. Move as quickly as possible and report back. In general I think developers value their code too much and should be willing to scrap and rewrite, especially whenever requirements are changing. I chalk it up to everyone's desire to conserve mental energies due to not understanding what their energy peak/limits are.

hackan 3y ago

I really like this idea, I'm often prototyping, but since I do it on my own, it is not throwable, so I tend to keep longer as they explain.

nine_k 3y ago

«In most projects, the first system built is barely usable....Hence plan to throw one away; you will, anyhow.» Fred Brooks, The Mythical Man-Month 1975, fourty eight years ago, but worth repeating sometimes.

jpswade 3y ago

I like the idea of “Spike and Stabilise”. Which means, prototyping in this way, but at the point it is actually delivering value, stabilise. Of course, it’s never as simple as that, but there’s certainly a place for this technique.

varispeed 3y ago

I try to structure my code so that it can be easily tested and it is modular enough so that you can swap implementations with fair ease. This means I can iterate much quicker - I can have code that works and is good enough for now and I can later on improve it and also I can suitable test coverage that can confirm the new improved implementation works as expected. Code that is organised this way is also rather easy to understand and test perform a function of documentation - which means someone else can get familiar with it and work in a short period of time.

myth2018 3y ago

Currently I'm writing mostly C and C++ and I find it very useful to write prototypes, either in the target language or in Python, to experiment with ways to modularize the code and how the modules will communicate. I only disagree with throwing the code away. On the contrary, sometimes I even use the last prototype as a sort of "executable documentation". That strategy indeed saves me a bunch of time. However, at least in my experience, I didn't have success applying that to modern front-end dev: the complexity is frequently so high and the dead-ends are so numerous that I prefer to buckle-in for the rough ride and proceed to the code right away.

stormdennis 3y ago

Not on this scale but it has happened to me on a few occasions that I've lost several hours work for some reason (including no autosaves). After the initial despair I know from experience I need to quickly try and recreate what I've lost while it's fresh in my mind. It takes much much less time and I always feel that I've done a cleaner job second time around. At times like that has occurred that this is the way to do it but I've never been able to bring myself to adopt this as policy.

jes5199 3y ago

yeah but I often end up getting Second-system effect https://en.wikipedia.org/wiki/Second-system_effect https://en.wikipedia.org/wiki/Second-system_effect

Tade0 3y ago

I have a similar process, but I do it after hours because I treat it as exercise. The task isn't about what the resulting system does, but how - the aim is to figure out where certain patterns are applicable and where they break down. Ideas include: using a design pattern like Entity Component System, exploring whether a certain way of formatting code is actually more readable, producing a drop-in replacement for a small utility. I firmly believe this makes you an overall better programmer. That being said I think it would be wise to refrain from doing that at work.

progmetaldev 3y ago
This is the exact technique I used that made me a better developer. I would take on the task of rewriting code in my own time (small team where my rewrite didn't affect others). There were times where I misjudged how difficult the rewrite was, but I stuck with it and took it as a learning experience to make sure next time I thought things through further before moving ahead with a complete rewrite. Now that I'm more experienced, I tend to get more important (and difficult) projects, and no longer attempt the large scale rewrite. I do definitely throw away portions of code and rewrite, though. I think there's a balance to achieve.

karmakaze 3y ago

I've always called this the "green-path prototype", which is building what you thought you knew, without implementing edge cases. The edge cases will get discovered and noted along the way and they should be documented (with a comment or other method that doesn't get lost). Pretty much any time you only handle a subset and don't handle the 'else's. The real implementation should consider the green-path and edge case notes, decide the desired structure/decomposition and pick and choose from the green-path rather than try to start with it as v1 of a final form.

HankB99 3y ago

I didn't read the article, but can guess at the rationale. I often wish I had the luxury of taking everything I learned writing something and then applying it when starting over. But IAC... I would much rather throw away someone else' code. :D

sodapopcan 3y ago

The funny thing is is that this is part of TDD (and extreme programming) that most detractors of TDD don't understand. I'm talking about the old "but if I don't know what I'm writing, how do I write a test first?" crowd. Well, the answer is this article. Write a quick prototype to answer unknowns, figure out a general plan, then throw it away and start with a single test. I emphasize "single" because there was that other article that made the front page a couple of months ago where the author described their "new found way" of doing TDD that made them actually enjoy it and then went on to describe regular plain ol' TDD.

coolliquidcode 3y ago

I think sometimes it's a good idea to use a language the company doesn't use internally to prototype. Like we don't use python or node in production, but a lot of stuff can be POCed in those languages/frameworks without a learning curve. It forces you to throw out the old code and forces you to think the problem out in different ways. Also, in my experience the POC does enough that it turns into just use POC because of the illusion that it would be faster to use than to rewrite. Then it's a span of time fighting edge cases and added features thought of afterwords till it passes all testing. Then you have a battle tested piece of code you can't get rid of, difficult to understand, and ridged for changes.

jimnotgym 3y ago

I see. A new generation discovers Extreme Programming!

nraf 3y ago

We do this occasionally as a tech spike - if there’s a lot of uncertainty or if we need to evaluate between a couple different approaches, we’ll dedicate 2-3 days to hacking away with the aim of lifting the “fog of war”.

sideproject 3y ago

Well, maybe not throw away everything, but I understand the principle. There are also other areas where this could help - and one of them is "naming". Sometimes when you start a project, you don't really know what the best names are for things. Project name, repo name, service name etc. So you choose something that you think it's ok and you go ahead. As the project progresses, you realise you've named things wrong, but renaming is so annoying and tedious. Often we ignore the bad names because it doesn't seem significant. But names are how people burden their cognitive load (an example, we named our repo after planets rather than describing what the repo does - "acme-customer-module-frontend" but we named it "pluto" - now everyone has to remember what pluto is and make sure pluto is not neptune).

bandyaboot 3y ago

I don’t really see the need to commit to throwing my first iteration out. I do refactor pretty aggressively at the outset of a major project or code change though. It often takes me quite a bit of time before things really get off the ground because of this. The result is probably the same—that I’m paying a lot of attention to making sure I’m going down a good path.

treprinum 3y ago

You throw your first draft away, you go straight to the second-system effect: https://en.wikipedia.org/wiki/Second-system_effect https://en.wikipedia.org/wiki/Second-system_effect

microflash 3y ago

After seeing multiple "first drafts" going into production over years, I've internalised that they shouldn't be even presented as ready to be shipped until and unless a draft passes multiple refractors. If something is unknown, it is better to explore possibilities and prototype in a prior sprint before picking the actual implementation. Take your time to figure out unknowns before writing the code you intend to ship.

pishpash 3y ago
Management doesn't care about your perfect code. You won't get rewarded either.

danielovichdk 3y ago

Funny how Fred Brooks keeps repeating history. I am just watching as the young and optimistic learn the hard truth. Build one to throw away - mythical man month.

mattbis 3y ago

I have the observation:- first version is never the best it will work with bugs, then you iterate and improve structure and arch. The third is the best. No time to waste doing that.

toss1 3y ago

Go further. One test is worth ten thousand opinions. What are a thousand tests worth? Plan to build and deliver an expedient first version, then have a technical debt jubilee before building the second. Build v1 in the most reasonable expedient (including not-scaled-up) way to deliver a reasonably full first feature set. See how it runs, what the users like/dislike/need/want, where are the rough edges both externally & internally, what the load cases look like, on various components, etc. You'll find 80%-90% of your surprises with this. Now, use your quickly-won knowledge of your actual system to plan and build the durable and scalable version. Despite my intrinsic approach having always been about planning, generalizing, etc. (premature optimization?), I was fortunate enough to be in a situation in one startup where I decided to do this, and it worked out amazingly well. V1 got out fast, without worries about tech debt. Building the 2nd version based on actual knowledge and and the v1 tech debt jettisoned, allowed a 'real' version to get out faster and better. There may be some problems with mgt politics, and it interfered in the above product also, but it does have much to recommend it.

einpoklum 3y ago

Yeah, well, good luck convincing most manager I know to plan for a phase whose outputs get tossed away. They would really much rather the prototype code gets merged, and then just work. Not to mention the fact they never let you "do things more properly", if they can help it, because you are again wasting precious time which could be used to do other work from the ever-growing backlog. As for my own projects - if I both "write things more properly" and divide them into small parts, it's easier to just keep the code I wrote for doing whatever it is I had it do; and maybe at some point collect enough of that to make a library, or at least a reusable header.

Havoc 3y ago

Not sure that level of absolute is the way to go. If you build a prototype and happen to nail it then why not iterate? Or perhaps you wrote a prototype and specific components/module feel sound? Authors suggestion feels sound as a question you should ask yourself & seriously consider, more than a strict principle.

extr 3y ago

As an ML-focused python dev I have never been able to break the habit of REPL-driven development, but I find it works really well for "building code that works" rather than coming up with a tower of abstractions immediately. A typical python development workflow for me is: * Start with a blank `main` file and proceed linearly down the page, executing as I go. * Gradually pull out visually awkward chunks of code and put them into functions with no arguments at the top of the file. * If I need to parameterize them, add those parameters as needed - don't guess at what I might want to change later. * Embrace duplication - don't unnecessary add loops or abstractions. * Once the file is ~500 LOC or becomes too dense, start to refactor a bit. Perhaps introduce some loops or some global variables. * At all times, ensure the script is idempotent - just highlighting the entire page and spamming run should "do what I want" without causing trouble. * Once the script is started to take shape, it can be time to bring some OO into it - perhaps there is an object or set of objects I want to pass around, I can make a class for that. Perhaps I can start to think about how to make the functionality more "generalized" and accessible to others via a package. This is literally the only way I've ever found to be productive with green field development. If my first LOC has the word "class" or "def" in it - I am absolutely going to ripping my hair out 12 hours later, guaranteed.

slim 3y ago
by REPL here you mean jupyter notebook?
- bogeholm 3y ago
  REPL = Read-Eval-Print Loop. So could be iPython or just plain `python` in general, can’t say what OP is using of course
  - paxcoder 3y ago
    [dead]
- hughesjj 3y ago
  Not OP but I often code in the REPL for python as well. Sometimes I'll stub out my code and just drop into an interactive debugger where I'm writing the next section. In the python debugger, if you type `interact`, it'll give you the normal python repl. This combined with the `help` and `dirs` are super useful for learning new frameworks/libraries and coding with your actual data.

linsomniac 3y ago

Decades ago I spent a whole day adding a serious new feature to my software. Had the first version all polished up and ready, and through a misunderstanding with my version control software (probably RCS, maybe CVS, probably not SCCS), I lost that work. Like maybe I did a checkout instead of checkin, something like that. I went to bed quite annoyed. The next day I got up and started from scratch. The new implementation took me half a day, and was decidedly a better implementation. Fred Brooks turned out to be right.

trevortheblack 3y ago

Oh FFS. Writing code is like writing natural language. It's editing that counts. Not the first draft. Whether or not you should throw out your first draft is in proportion to its value at getting you to the final draft. Not some axiom you thought of for a specific use-case and specific code base

waffletower 3y ago

Another untenable programming ethic used as a clickbait title.

waffletower 3y ago

The article describes a potentially useful exercise that might be explored by an organization that has allotted development time for a hack-a-thon or some such. Depending on the size and scale of the projects that a software team typically develops, a more realistic approach might be to spend smaller and more manageable chunks of time as a team evaluating recently developed features/services/apps and directly applying improvements gleaned into the planning of subsequent projects.

erksa 3y ago

Similarly why hackathons are so surprisingly successful in creating projects that would be otherwise doomed if estimated and planned out before hand.

andirk 3y ago

> Organize hackdays! We do these at work, and they're a source of a lot of the ideas for and prototypes of major features that get into our product. When a feature comes out of one of these, it's already vetted and prototyped. As someone who wins most of the hackdays, I agree that the original hackday code needs to be rewritten. I have seen too many spaghetti Frankensteins to allow quickly written code into a codebase.

marmot777 3y ago

A lot of writers do the exact same thing.

freehorse 3y ago

It feels as if a lot of this discussion happens between people who have a completely different context in mind where throwing all the prototyping code away may make more or less sense. For me, it is hard to think of a scenario of writing prototyping code for more a few days and not reusing at very least 10% of that code (with some modifications). I would be fine throwing away the 90% of it or sth, but the frustration having to rewrite parts that I had just written and threw away would be too much to bear. Even merely for reference, would make no sense for me to throw away.

simo7 3y ago

I have a different approach: I'm ok to throw away significant chunks of code as long as I have important new ideas that allow me to do more with less. Often the problem with refactors is that don't come with enough of these new ideas , there's no real progress, it's mostly moving things around.

amelius 3y ago

My boss doesn't allow me.

majikandy 3y ago
Only if you told them you were done, when you weren’t (if following an approach described in the article). I suspect the author also meant, it won’t take longer with this approach. Possibly even faster that without it is completely viable.

allenrb 3y ago

This would sound like questionable advice except that the best code I wrote in college resulted from an accident… I’d sat down all night and written some C for a graphics class. Everything was great, yay, victory. Proceeded to tar it up per class guidelines and did something like this: tar cvf assignment.c assignment.h data.txt readme whatever.cuz And as many of you no doubt recognize, I’d forgotten to supply a destination name before listing the source files. So the code was gone. My brain was gone, too, so I explained what happened and sent what I had, including a working executable, to the TA. He gave me an extra day to finish. So the next day I sat down and wrote it all again and as mentioned above, it was some of the best code I’d written. Doing it again from the top saved all sorts of dead ends and mistaken approaches.

majikandy 3y ago
This is exactly the type of story I tell when people are anti pair programming. I ask them if they’ve ever lost a days code (usually asking if they ever used source safe) and that when they finally knuckled down to write it again, it took about 20 minutes. As the writing the code wasn’t really the hard part or the bottleneck, solving the problem was the hard part. Hence pair programming having two heads on one problem to solve it better/faster, find the edge cases etc. Out of curiosity, was it really fast for you to do it in that extra day or did it take all day?
- allenrb 3y ago
  Much faster the second time. Like you said, all of the problems came pre-solved. :-)

majikandy 3y ago

The famous comedian John Cleese speaks about this where he loses a script and has to rewrite it from memory before a deadline. Then he finds the old one and finds out his new one is much better despite thinking it was the same. So he started using it as a technique for better script writing. It is referenced here but I can’t find the video https://www.ideaconnection.com/right-brain-workouts/00186-john-cleese-on-creativity.html https://www.ideaconnection.com/right-brain-workouts/00186-jo...

hyperthesis 3y ago
I don't know why, but calling him a comedian sounds like an insulting put-down. He is a Python! (Maybe because, in this context, python excels at rapid prototyping?)

comment_ran 3y ago

I'm not going to delete my .emacs file even though it is ugly, it just works.

wkjagt 3y ago

I just lost a first version of some assembly code I wrote on my Apple II through my own mistake: my code wrote to the part of memory where the assembler kept the source code. When it seemed to work (I hadn't noticed I'd lost my code yet) I saved this (corrupted) version of the code to my floppy, corrupting even the floppy. I had to write the same thing from scratch again, but this time with the full understanding of the problem in my head, and I think the rewritten version is better because of that.

sedatk 3y ago

I also discuss this in my book Street Coder in the section titled “Write it from scratch”.

LAC-Tech 3y ago

I feel like this a symptom of trying to design while you code instead of putting down the text editor and just designing your solution instead.

wruza 3y ago

If you know that you're possibly keeping the code, you do things in a "proper" way, which means moving slower. Put in all the exception handlers, all the log statements. Structure the code nicely, refactor things while you're in there, modularize them properly. After all, it's going to be reused. This is where it all comes from. You don’t have to throw away code if it doesn’t need refactoring, modularization and so on to satisfy that “reuse” mantra from the beginning. Healthy reuse comes in two flavors: - a copy of the code - a separate well-maintained, versioned and documented library Anything reuse-focused in between is mostly snakeoil not worth drinking and is often the reason why your code has so many intricacies in it that you have to perform “recon missions” before actual coding or estimating. You’ve built a dozen of poorly-documented ad hoc libraries into your project. There’s no surprise it may require a proper source code expedition to detect and recrystallize parts that a new requirement shattered this time.

toasted-subs 3y ago
Eh, don't get me started on how many people take a well known abstraction then build another abstraction on top of it. You already had the abstraction!

danielvaughn 3y ago

I take this to the extreme. Over the past 6 years I've thrown away...somewhere around 12-15 versions of my side project. Part of it is that my own requirements and opinions changed with each version, but another part of it is that I'm pathologically unhappy with my own work. So yeah, maybe throw away the first draft, but don't do what I did.

gregfjohnson 3y ago

Jon Bentley's classic column "Bumper sticker Computer Science" includes the following bumper stickers: [Brook's Law of Prototypes] Plan to throw one away, you will anyhow. Fred Brooks, University of North Carolina If you plan to throw one away, you will throw away two. Craig Zerouni, Computer FX Ltd., London, England Prototyping cuts the work to produce a system by 40 percent. Larry Bernstein, Bell Communications Research [Thompson's rule for first-time telescope makers] It is faster to make a four-inch mirror and then a six-inch mirror than to make a six-inch mirror. Bill McKeeman, Wang Institute

cratermoon 3y ago

I worked one place that missed a golden opportunity to build one to throw away. The short version is that the team formed and started working on the designated product, but very shortly after a VP-level exec got directly involved and started asking about where "his" product was. This was before I joined, so I'm not sure if the original direction was supposed to include this or if there was some management nonsense behind it, but the team had to quickly pivot and deliver something for this needy VP that was kind of sort of related to their stated goal. In any case, the programmers got their marching orders and rushed out something to satisfy the VP, then went back to focusing on their original goals. The real work overlapped, in technology and business function, with the rush goal. After they were done, they could have stepped back, taken a look at what they did to get it done, identify the shortcomings, missteps, and undesirable consequences of the decisions made for that work. They could have proceeded with the main work using all the lessons from the 'emergency' work, and avoided a lot of the problems they'd created in rush to production. Instead, they decided to build, or perhaps more accurately defaulted to building, the real product on top of the work they done for the rush job. After another six or eight months, the project was in serious enough trouble that programmers were leaving, and they ended up with an almost 100% turnover in engineers. The manager's response was to start micromanaging everything and set the team up for a death march to a predefined release date.

perilunar 3y ago

I'm a big fan of Gall's Law: "A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system." [0] I don't throw my first version away, I just start really simple and evolve it iteratively, making sure it works at each stage, and by the time it's done very little of the original code remains. 0. https://en.wikipedia.org/wiki/John_Gall_(author)#Gall.27s_law https://en.wikipedia.org/wiki/John_Gall_(author)#Gall.27s_la...

Benjammer 3y ago

What this post says: "throw away the first draft of your code" What every HN commenter is replying to: "throw away your code" -- I've written software professionally for 14 years and just last week I wrote code for ~3 days and then decided I was on the wrong track, and checked out main and made a totally new branch, spent ~1.5 days re-writing my feature in a totally different way. I had come to realize the new way would be easier to write, MUCH easier to test, and a bit more maintainable long-term. Nothing wrong with throwing away un-merged code if you decide that merging isn't the right decision, and feel you have learned valuable lessons to inform the re-write.

deterministic 3y ago

I have never done that in my (successful) 30+ year career. I usually start with a simple end-to-end skeleton implementation that works, and then step-by-step refine it to production quality. It’s simple. It works.

keepamovin 3y ago

Can I just pass my first draft through chat GPT because I wanna save my fingers.

SnoozingBoa 3y ago

As a designer (UX focused, but technical as well), I have put a lot of effort to study prototyping in sw context. I think prototype itself is fairly well understood as a noun, but how to approach the activity is not that well understood. I think it starts with what to prototype (scope/intent) and what to do with the outcome. This is where different viewpoints start to have their impact. It is very common mindset not discard anything that has been done. Some cognitive biases are likely in effect here. It is also common to attach additional intentions retroactively. E.g. it is totally ok to build UI prototype and to deviate drastically from the current state of things. Depends on the intention. Now, it is not hard to imagine a follow-up discussion that takes unfortunate turn at some point because the expectations for the activity does not match. The focus shifts from the main idea to defining what was not the idea. The value of the activity diminishes steadily. At worst, inexperienced prototypers might end up with a loundry list of changes to be done to meet the current state, confused about what just happened. I think the main point of the article is valuable: be ready to stop and throwaway your prototype. Use it smartly. Find things you want to validate or just see, then be immediately ready to throw it away. Do not project additional things on to it. Use that energy towards the ”real thing”. In the world of Figma/other prototypes there seems to float this idea that prototype has some fixed and standardized meaning. As an activity it has been bolted into different methodologies and tools, which is fine of course, but they are also taught, discussed and treates together with specs, requirements and other artifacts that serves different purpose. They communicate different things. That’s it. In the end it is about communication. I think the great power of prototyping makes it also hard to use to it effectively. Personally, I think the best part of building a prototype is to throw it away. It is a milestone, the end. Almost always a success.

aappleby 3y ago

No, don't do it. Practice continuous refactoring.

rvdginste 3y ago

Personally, I would never or rarely use the approach where some code is created and then thrown away. I think it is always better to first think and then do. With software development, I make the distinction between a functional analysis and a technical analysis. Functional is clarifying the actual business requirements. Technical is clarifying how to implement the new functionality into the system. During the technical analysis, you are supposed to check and update existing class diagrams, existing api specifications, and so on. Depending on the experience of the team you need to describe this in more or less detail. The technical analysis must be done by someone who has knowledge of the project. That someone should be aware of the quality of the data in the database, or (in case it is relevant) should explore this while doing the technical analysis. It would also be normal to check the source code while doing a technical analysis to see how things are currently working/built and where the new functionality can fit in. The reason for investing time in a technical analysis, is to start the implementation with much higher confidence and get a decent implementation from the first attempt. You must find a balance between the time you spend on technical analysis (without writing any code) and the time you spend on the implementation itself. Spending more time on the technical analysis should save more time on the implementation, but I am aware (and convinced) that some problems will only be found by creating the actual implementation. However, I am also convinced that these problems rarely require a fundamental change in the implementation that a rewrite is needed. In short, when thinking before implementing, the quality of the first implementation is high enough. Also, what is not clear to me from the article. The author mentions to have 1-2 highly skilled engineers create a first implementation. And the author likes to be one of those engineers. These engineers create a prototype and then throw it away. The engineer who created the prototype now has an idea how the code must be implemented. How is that information communicated to the (lesser skilled?) engineer who must then implement the new feature?

tpoacher 3y ago

IIRC, Michael Feathers calls this "Scratch Refactoring" in his "Working effectively with Legacy Code" book from 2005. Excellent read even today.

mikhailfranco 3y ago

If waterfall is: specify-design-code-test Then agile TDD with prototype and discard/refactoring is: specify-test-code-design-recode A POC is different from a prototype. A POC helps to define the problem space, but it may also suggest a better initial design (identify useful abstractions): poc-specify-test-design-code

Arch-TK 3y ago

Honestly for smaller projects I just keep throwing it away until I can write it again in a day and it's as simple as it can possibly be. Although I don't always remember to do this.

hyperthesis 3y ago

...you will anyway (Brooks) IMHO Write it once for the problem; again for the solution. TFA stresses: finding out what you're building; finding the "unknown unknowns" (the things you don't even know you don't know, encountering those problems) TFA doesn't say it this way, but I think the fun of throwaway-prototyping is your thoughts can focus uninterrupted on the problem, undistracted by secondary issues. You can hack-around tedious parts, now knowing they are there; and you can get absorbed in the genuinely tricky parts, unobscured (even if you don't succeed, you also know they are there). You're not expected to get it all right. It's turning an unexperienced developer (on this problem) into an experienced one. PS Somewhat disturbingly, Brooks went back on this according to this interview https://www.computerworld.com/article/2550685/the-grill--fred-brooks.html https://www.computerworld.com/article/2550685/the-grill--fre... "you should plan to throw one away. You will anyway." That was the first edition of The Mythical Man-Month. In the second edition, I say that was misguided! You ought to plan to continually iterate on it, not just build it, throw it away and start over. Some of the things I said in 1975 were wrong, and in the second edition, I correct them.

atleastoptimal 3y ago

This maxim could apply to any skill based project. The skills needed to do something properly require first doing it from start to finish improperly. That's why a safe staging environment for skill development is essential to improving at anything.

jasfi 3y ago

I'd have to be very new to something to throw away the first draft of my code. My goal is to have to change the code I write as little as possible.

dave_sid 3y ago

Or refactor it

tacker2000 3y ago

What a load of nonsense. Iterative code refactoring is the only right approach. Why spend time writing code and then throw it away?? That makes no sense at all. Best approach would be to spend some time thinking and conceptualizing BEFORE writing the first line of code.

lioeters 3y ago
For me, writing code is a way of thinking, and often the best way of thinking about a problem or question, or to start conceptualizing an entire project, is to write some running code as a sketch, a rough draft, a prototype. If it has any merit, the running code informs the planning and decision-making process, stimulates thought and discussion. Parts of the draft, or even the whole thing, can be transformed, rewritten or refined, and become the basis of the solution and product. Of course it depends on the goal and nature of the question. Sometimes it's better to talk and think things through in human language, deeply and thoroughly, before writing any code. It could be that the best solution is no code at all, to use an off-the-shelf product or service. About "throwing away" code.. Imagine a musician with thousands of hours of playing, practice, informal or private performances and recordings - including piles of sketches and rough drafts that will never see the light of day. Only the best selection will be curated for the public, to make it into the final product. But the 99% that are "thrown away" was not a waste of time, they were a necessary part of the creative process to achieve the good stuff.

ryukoposting 3y ago

This is an idea I've preached for a while now. Software requirements, goals, deadlines- all that stuff can be planned. Even the architecture can be sketched out. But, for any sophisticated piece of software, you'll never get the actual code right the first time. If you think it's right, dig deeper. Find everything that's wrong with it, and do it again with those problems fixed. Great software and great art have one thing in common: the best version is never the first.

mock-possum 3y ago

First do it - then do it right - then do it better.