Do Developers Tend To Scrap Or Ship Their First Drafts? (ntietz.com) 100
Long-time Slashdot reader theodp writes: The necessity of multiple drafts may be an idea that's drilled into children's minds by teachers and parents, but in 2023 there's still a need to remind software engineers to Throw Away Your First Draft of Your Code. "The next time you start on a major project," advises Nicole Tietz-Sokolskaya, "I want you to write code for a couple of days and then delete it all. Just throw it away. I'm serious. And you should probably have some of your best engineers doing this throwaway work. It's going to save you time in the long run."
While Tietz-Sokolskaya's advice echoes that of Ernest Hemingway ("the first draft of anything is shit"), do developers tend to scrap or ship their first drafts in the real world?
While Tietz-Sokolskaya's advice echoes that of Ernest Hemingway ("the first draft of anything is shit"), do developers tend to scrap or ship their first drafts in the real world?
It depends (Score:3)
So much "It depends" in some many ways. Like the size of the project, the type of development, the level of unknowns involved, the methodologies in use, etc. I can't imagine post a useful comment about this without spending hours writing it.
Re: (Score:2)
In theory, the first thing you write, is just to "see if it works", that's the one you throw away.
In practice, that first thing you write should not be your magnum opus. It is "shit" but it's better to have 20 pieces that you can develop independently and throw away as needed (eg they communicate over UDP or pipes with each other) because sometimes those first versions will also be the only versions. One of my production pipelines is still using the "Terminal" front end I originally wrote and it has only ch
Re: (Score:3)
In theory, the first thing you write, is just to "see if it works", that's the one you throw away.
The next one is to abstract and reuse, so that it is optimally elegant and concise, while also being optimally impossible for anyone to understand, including yourself one year later.
Re:It depends sometimes there is no 'draft' i.e. (Score:3, Interesting)
It's been over 20 years since I worked as a programmer, so things may be different now. But here's an example from the real world (or at least the real world of the 20th century) where the 'throw away the first draft' simply does not apply.
Sometimes I was given a project where I really had to wing it. No mentor, no guidelines, just a sort of spec on what the result was supposed to be.
What I would do is figure out some part of the project, some task within the overall project that I was sure was going to b
Re: (Score:2)
Seems like the whole thing is a "draft", at least until you finally present it to the customer (or whomever the end-user is supposed to be) to see if they will actually accept it, or not.
If they accept it, then great, you're done. Most of the time, however, they will at least want some revisions/improvements, and sometimes you'll end up with a "this isn't what we wanted at all" response, at which point you'll be tossing out a lot of your design and reimplementing it (or, alternatively, trying to convince t
Re: (Score:3, Interesting)
Again, there are many scenarios. The times when I had to wing it I was working for a very small company and the product would get sold and then I'd be given a deadline to deliver. The only review was the customer took it and we waited to see if there would be bug reports.
One time I went on site to a place in France. Presumably I was installing and testing the product on the customers equipment but really I was still getting it to work. It had to parse Ada programs (It wasn't written in Ada but it had to
Re: (Score:2)
The risk of that last scenario is why I always try to get the program in front of the user sooner rather than later, even if it's primitive, so I can find out if I'm wasting my time, and reconsider my approach before I've wasted too much of it.
More programmers should take this approach. It's amazing (but understandable) the disconnect between users and developers. Answers to questions that seem so obvious to both sides have completely different answers that can change the entire project.
My latest project I was doing UAT, no one defined what counted as a scheduled appointment. Both sides thought the answer was very obvious and not worth spelling out. To the end users using the software, the moment an exam was scheduled counted as "scheduled", to o
Re: (Score:2)
When I am coding I have quite a few definitive criteria to measure success against like whether it passes defined tests, whether the performance is inline with expe
Re: (Score:2)
I once wrote hundreds of lines of code. While writing, I realized why it was not a good way to do it, so I deleted all code and started again. This repeated again and at the 3rd try I got it right. But usually I do it just once.
I think it mostly depends on how much the part is used by other code. If you have dozens of users all using differently, it takes more attempts as only when running the tests I realize some use cases I did not know about that change everything. Sometimes the customer also changes spe
It depends (Score:5, Insightful)
Re: (Score:2)
Sometimes that first draft of code is the most succinct and beautiful solution to the issue at hand.
Human Resource Machine (HRM). https://store.steampowered.com/app/375820/Human_Resource_Machine/ [steampowered.com]
Even if you're not into programming, this is more a puzzle game and also illustrates the issue.
In each of the puzzles, you need to come up with two solutions. One solution needs to be the least lines of code possible. The other solution needs to be the least number of steps possible.
The amusing and some times frustrating aspect of the game is, you can fail to do either and still solve the puzzle. Some times yo
Re: (Score:3)
I don't think it's worth scrapping everything and starting over most of the time, just don't be afraid to do extensive re-factoring.
Experience (Score:5, Informative)
If I do something completely different, far from my comfort zone, then I'm much more likely to discard (or seriously refactor) my initial attempt.
Re: (Score:2)
I have decades of experience now...
Not needed these days! Nowadays, even devs at their first project consider the first draft production grade and deploy it to prod right away without any further review or testing and announce it with all the bells and whistles as a new revolutionary piece of software! /s
Re: Experience (Score:2)
Re: (Score:2)
Re: Experience (Score:3)
Re: (Score:2)
This is why I have a MSCS. Plus, I was working at the university's research park, thus technically university staff. Which meant I could take courses without matriculation fees, and some nominal fee like for 1 credit hour take 6 credit hours of courses.
Re: (Score:2)
In what sense is it amazing if it doesn't work? Software is a machine, not an art project. There's certainly room for artistry when done well, but if it doesn't do what it's supposed to it's just overpriced pretty trash.
Re: (Score:2)
Re:Experience (Score:4, Insightful)
Software is an evolving thing. There's always something more to add for which this will be the first attempt. How do you decide when you've learned enough that it's worth rewriting it?
And then before you know it, the software encodes so much forgotten business-essential logic that it's just not safe to rewrite it from scratch.
Re: (Score:2)
Easy - when maintenance starts becoming a nightmare and a lot of the maintenance is busywork.
Someone hands me a set of requirements, and perhaps it's new enough I'm not entirely familiar with everything I need to know. So I research it, then I code up something that I believe does the task. That is coded up using the usual decomposition methods you would do to break the one big task into smaller tasks in ways that seem to make sense b
Re: (Score:2)
To use an analogy: People wouldn't expect a plumber to plan out a sink waste trap, throw the plan away, create a revised and then i
Re: Experience (Score:2)
When I find myself in this situation, I like to try to generalize things more, which leads to more interesting work.
A contrived example might be: I've written lots of little command line utilities so I can whip them out without hassle. When I continue to get more work building command line utilities, I will start looking into related problems. Maybe I was just using strings for my help text. But now I am working on integrating the help text with the online documentation. Then I might try to get it to work a
Re: (Score:3)
Volition clearly didn't either in code or story (Score:2)
That's the only way to explain just how poor Saint's Row 2022 was. Except for poly count and the ability to leave footprints in the sand, Saint's Row 3 was superior mechanically in every way. And the less said about the story the better.
Wasted work... (Score:2)
Re: (Score:3)
That is not how you do it. What you do is you build a prototype and you make it clear that it will be thrown away and not be that basis of the final system. Any customer that does not agree does not want quality work anyways.
Re: Wasted work... (Score:2)
Nah. Instead you should build it just to the teetering edge of passability. Then when new features or concerns come in, that's more money. Eventually every new feature is some slog of finding a way to make a change without the whole thing falling to pieces, which means even more money. Finally, you do a rewrite, which means even more money.
Re: (Score:2)
Excluding the rewrite, that seems to be the MS model of creating software. And that of many others. No surprise the whole IT landscape is getting more and more of a mess.
Re: (Score:1)
Prototype? Proof of Concept? Yea right, boss' and customers don't want to hear that crap. They will not want to pay for the second draft. If you have to rewrite your code, you better do it before they see it.
With that said, SaFE (agile) helps with this, you purposely start small and get customer (could be boss, upper management, customer) buy in on the outcome as well as what the next steps will be. You can bury a lot of rewriting in those subsequent steps.
Uh, "Mythical Man-Month" anyone? (Score:5, Informative)
Or doesn't anyone read that book any more? It wouldn't surprise me. We seem to continually reinvent wheels and claim it's "the new big thing."
Re: Uh, "Mythical Man-Month" anyone? (Score:2)
I am genuinely curious to know if this blog article was written by someone who had read Fred Brooks.
Re: (Score:2)
I came here to bring that up. For those who don't know the book, one of the experience-based ideas was "build one to throw away". The idea is that you'll have to in any event so might as well plan for it.
Re: (Score:3)
Refactoring counts I think (Score:5, Insightful)
Re: (Score:2)
Yup, along with going thru and confirming names, etc. all match your local coding standards, removing un needed log outputs, making sure anything that needs a comment is commented, etc.
Re: (Score:3)
I tend to use the "try the dumbest thing that could possibly work first" method, then after the concept is proven, I refactor it into good (or varying levels of better) code over the course of a few iterations, until the point where the original does not really exist any more, but it still solves the problem, and has decent tests, logging, and the other things that typically need to be thought about.
Agreed.
The rare occasion where I thought "oh, that was junk, I'll just rewrite from scratch", I've found myself constantly digging around in the old code, figuring out how I solved some problem, and then trying to figure out how to get it into the new code base.
When something is sufficiently junky I may refactor to the extent that I need a week or so before it runs/compiles again.
Re: (Score:1)
As some have already pointed out, if you are doing a project where there are good examples and experience the firs
Re: Refactoring counts I think (Score:2)
When you recognize that the core tenet of agile is to adapt, you will find agile is much more useful. Team doesn't like user stories? Don't use them. That's still agile.
Re: (Score:2)
What no one seems to understand about Agile is that Agile was created as a better way to add features to an existing web site.
Period. That is it. If what you are working on can be thought of as a "web site" then fine. Many things cannot, and so should not be developed using Agile.
Re: (Score:2)
I don't think that's quite correct. I was peripherally involved in one of the very first Scrum projects. It was not a Web site. It was a Windows front end to a brokerage management system mostly written in COBOL. It was very successful, although for reasons that turned out to be difficult to replicate.
In my experience (including this as well as many subsequent projects that were supposedly going to be "agile"), Agile principles work well when you have good communication within the team and the team inc
Re: Refactoring counts I think (Score:2)
I distinguish refactoring from throwaway drafts. A refactor in my mind is something focused, like rework a class, or change the naming scheme, or move things between modules. When the scope of the changes extends beyond this and becomes countless interdependent refactors, that's a throwaway.
Re: (Score:1)
I read "PoC" as "POS" the first time. Then I re-read it. Then I realized either way works.
Re: (Score:2)
This is dumb! Why would they do that? (Score:2)
Re: This is dumb! Why would they do that? (Score:2)
Many of us are paid for our critical thinking. The ones writing the acceptance criteria are often not able to fully specify the problem. Even when they are, their solution might be based on limited understanding. Our role is to work out how the problem and proposed solution fit into the project. This is why things like "agile" exist.
Re: (Score:2)
Re: This is dumb! Why would they do that? (Score:2)
I would characterize it as Just-in-time design. So you avoid designing things that you don't need.
How much did I learn from this? (Score:2)
Maintainability (Score:1)
The one thing I see too often, is developers building stuff without thinking about maintainability. In some place, especially when building stuff for larger companies, your code may be in place for one or two decades, or more. It needs to be written cleanly and effective, so that people ten years from now who may need to change things for future requirements can understand what you did, and if possible, why. First drafts are never like that.
version control (Score:1)
I look at code writing as a journey (Score:2)
I start off on a path I believe will be good
If I encounter increasing difficulties, I suspect that I'm on the wrong path. If the difficulties multiply, I sometimes abandon the path and start over
If I get unexpected good surprises, and things I expected to be hard turn out to be easy, I know I'm on the right path
It's nearly impossible at the beginning to know for sure what path to take
Incremental deelopment (Score:1)
If you follow agile principles, you start by building a skeleton / framework that does almost nothing, then start adding features. You never really "throw away" the "first" draft, you just keep refining it.
It's kind of like a high-rise office building. You build the skeleton, then fill in the details when the tenants lease space. When a tenant leaves and another one takes their place, you might have to wipe out that floor and renovate, or you might be able to lease the space as is. But you'll never "throw a
Re: (Score:2)
If you follow agile principles, you start by building a skeleton / framework that does almost nothing, then start adding features. You never really "throw away" the "first" draft, you just keep refining it.
Perplexing people would prescribe approaches when nothing is know about the problem to be solved.
Re: (Score:2)
I never said you know *nothing* of the problem to be solved.
In the office tower analogy, you know a number of things. You know how many elevators are needed, and that restrooms are required for each floor. You know that windows will be needed, and emergency stairs, and so on.
What you don't know, is the specific layout of each floor. Each tenant gets to decide that. And that works because you've structured the building to handle any reasonable tenant layout requests.
In software, if you know that you are buil
Re: (Score:2)
I never said you know *nothing* of the problem to be solved.
In the office tower analogy, you know a number of things. You know how many elevators are needed, and that restrooms are required for each floor. You know that windows will be needed, and emergency stairs, and so on.
Now you are generating an example of your approach as if office tower were an example of a problem when clearly from the text of your remarks it was merely an example of an approach to an unspecified problem.
In software, if you know that you are building a data migration pipeline, you can build the structure--the pipes--that will handle the data flow. You might, for example, choose RabbitMQ as your queueing mechanism, and build structure around that. But you don't have to know about the specifics of the data mapping or the specific data flows, until you get that request from the business.
Can you name a circumstance where you believe the following should NOT apply to a nontri
Re: (Score:2)
Now you are generating an example of your approach as if office tower were an example of a problem when clearly from the text of your remarks it was merely an example of an approach to an unspecified problem.
No, the problem isn't unspecified. The "office tower" example specifies that the purpose of the building is to house offices, and not retail, or housing, for example. On the software side, the example is a data integration pipeline, and not a DNA matching system, or a retail platform, or crypto mining. So you know the outline of the problem enough to build the infrastructure, you just don't necessarily know the details of what the infrastructure will hold, until you get the requirements, which will be produ
Re: (Score:2)
No, the problem isn't unspecified. The "office tower" example specifies that the purpose of the building is to house offices
No problem was ever actually specified so I'm not sure how you think you can:
A. Claim otherwise.
B. Think anyone would be willing to accept such obviously false claims.
Office tower was an analogy not an example as you yourself explicitly admitted. "In the office tower analogy" ... yet here you are trying to sell something that is obviously false on its face.
So you know the outline of the problem enough to build the infrastructure, you just don't necessarily know the details of what the infrastructure will hold, until you get the requirements, which will be produced over time.
The issue isn't whether an individual or team has knowledge of requirements and a domain prior to starting a project.
It's YOU specifically suggesting an
Re: (Score:2)
I confess, I don't follow your argument at all, it literally makes no sense to me.
Following an incremental approach is not the same as knowing nothing about the problem to be solved. The incremental approach starts with a high-level outline and understanding of the problem to be solved, and using that to build a foundation (and structure) that can be used to solve that class of problems. The details come later. Yes, this approach is applicable to any domain, from building cars (as Toyota has so successfully
Re: (Score:2)
I never said you know *nothing* of the problem to be solved.
Neither TFA nor you describe any problem nor even class of problems to be solved yet you nonetheless spoke of how to solve it.
In the office tower analogy, you know a number of things. You know how many elevators are needed, and that restrooms are required for each floor. You know that windows will be needed, and emergency stairs, and so on.
Now you are generating an example of your approach as if office tower were an example of a problem when clearly from the text of your remarks it was merely an example of an approach to an unspecified problem.
In software, if you know that you are building a data migration pipeline, you can build the structure--the pipes--that will handle the data flow. You might, for example, choose RabbitMQ as your queueing mechanism, and build structure around that. But you don't have to know about the specifics of the data mapping or the specific data flows, until you get that request from the business.
Can you name a circumstance where you believe the following should NOT apply to a nontrivial implementation of anything?
"If you follow agile principles, you start by building a s
Yes. (Score:1)
No (Score:2)
Re: No (Score:2)
And use version control right from the very start, so you aren't scared to make major changes and to break things in the name of progress.
Re: (Score:3)
One of the problems I see with junior level staff engineers is that they are afraid to use version control to help them, as if they've told VC is for storing the finished code. "I don't want to push this code in case something's wrong it." and "I don't want all my intermediate steps to be in the history" headbutts "This was working yesterday before I made these changes but now I can't seem to get back to where it was."
I have to sit down with them and patiently explain things like branches, or local staging
Delete? No (Score:2)
Start over with the first draft as reference? Yes.
Re: (Score:2)
I do this all the time. My first attempt usually goes off the rails fairly quickly but does "somewhat" work. Using this first attempt as a guide my second and third attempts are much more fluid. I rarely get a great working piece of code during the second attempt. It's usually the third where things start to gel nicely. At first I thought these rewrites meant that I was a mediocre programmer but was pleasantly surprised to find out that most coders do the very same thing. I've only met one programmer in my
Start with an idea (Score:2)
Re: (Score:2)
If you don't at least consider all the requirements, your solution may end up being invalid. You don't try to solve all of the requirements in the first draft, but you don't want to make a decision that precludes compliance.
Just last week I was being the grey-beard for a new team's stand-up. They had been reviewing different toolkits for some unusual GUI elements the system will have. Conversation went something like
"Um...we've used *that* one before for similar purposes, but don't you have a customer requi
It depends on physical or electronic distribution (Score:2)
depends (Score:2)
Three Times (Score:2)
When I'm doing something new or interesting, I often end up building it three times:
1. Build the critical functionality as throwaway code just to see if I can make it work
2. Build out the full system to get a feel for how all the pieces fit together
3. Rebuild the full system now that I understand it well enough to properly architect it
Of course depending on the circumstances, I may wind up combining two these iterations with refactoring, or not doing all of them on every project.
Yes, usually (Score:1)
But sometimes I just set them aside, neither scrapping nor shipping them.
I delete about 10 lines... (Score:2)
Re: I delete about 10 lines... (Score:2)
The best coding is negative lines of code. So often I come into a project and end up deleting vast quantities of code that is unnecessary.
Notably, this is often because some previous developer wrote working code in a single giant pass, without performing any second drafts; typically fueled by late nights and Adderall.
Code is uninteresting and unimportant (Score:2)
I have done the design something you really like and start over thing but always in terms of design. Never actually writing code and discarding it. That just seems pointless and wasteful. You can always improve code later at your leisure.
Re: Code is uninteresting and unimportant (Score:2)
Often, my design is intended to make a particular type of coding easier/clearer/faster/stabler. Writing throwaway code is how you verify and stress test the design. Doesn't seem any more wasteful than QA.
Bruh they ship. Big Rigs proves it. (Score:1)
Clue's in the name. (Score:2)
One word: (Score:2)
Bethesda
in between (Score:2)
I start writing, with stubs, fill them in, realize I did things wrong and replace/refactor over and over. It's frequent to have duplicate routines using different algorithms that I'll time then choose the winner. But almost always a few lines from the first draft do survive intact in the final project. Especially member variables.
First draft (Score:3)
My first draft of any code always ends with "What the fuck was I thinking. This is a total piece of shit. If my boss ever finds out what a fraud I am I'll never get paid. Maybe I can re-write this and not have it totally suck."
Re: (Score:2)
I feel that way a lot.
I've been in this field long enough to know what good, clean, solid, maintainable code looks like. And, RARELY, to have had the opportunity to write and/or work with such code.
But I've never learned to convince the higher-ups that if they insist on building software as quickly and cheaply as possible, with no regard for quality nor for total lifecycle cost, then the resulting product will suck, do its job barely at best, cost an INSANE amount of money to maintain that it wouldn't have
The advice is pure rubbish (Score:3, Informative)
It made sense for Hemingway, since his first draft was on paper and there's so little space to modify that draft that was on paper. You could make sidenotes, cut words, but how much editing can you do on paper? Not much. So after you did the work on the first draft you'd start rewriting - mind you, not rewriting something else entirely, but the thing you worked on.
But now we have infinitely-refreshable paper. No need to throw away your drafts. But perhaps this piece of advice deserves to be thrown away.
Mythical Man Month (Score:2)
Throwing away your first solution (aka prototyping) was already proposed by Fred Brooks in 1975.
I am glad to see some of these basic principles being rehashed, as they do bear worth repeating.
Maybe it's only me... (Score:2)
But I usually have a strong feeling telling me if the first draft of the code I wrote is OK, or on the contrary it sucks. And this feeling has proven to be fairly accurate over time! So I would not always throw away the first version of the code I write, but it would be nice being able to tell the manager my code this time sucks and I need time to rewrite it.
Prototype = end-result (Score:2)
Usually, my prototype = end result. But then that requires ability to know what your requirements are.
It's when other people add new requirements that you need updates or "revisions".
up to my boss (Score:1)
Me: [runs program]
Boss: That's great! It does everything I asked. What's your next move?
Me: I'm going to throw it away and start over.
Boss: Haahaahahaha good one! You're a funny guy!
Solving the problem comes first (Score:2)
Once you have a working solution, optimize it from there. The caveat is don't optimize it unless it doesn't meet performance/maintainability/footprint expectations. I've seen Devs waste countless hours optimizing a piece of code for negligible gains only to miss out on things that were low-hanging fruit and made a significant difference to the performance, maintainability, and footprint of the solution.
"Hey Look I've written a fast Julian Date class that allows us to do date math 10x faster."
Well, except for Faceplant... (Score:2)
where their first draft gets rolled into production by them with no warning.
A bit of both (Score:2)
I try very hard to write reusable, generalized code. I often toss out the larger structure of a first draft, but pull out the generalized functions. It's an exercise in decomposition. A useful class, function, or set of related functions from the original draft might end up as its own library.
Mostly, this comes from my personal habits of never finishing any personal projects. Once I've worked on the interesting bits, I get bored and abandon the project. But by decomposing out the reusable (and often more in
Ruthless refactoring (Score:2)
Maybe not "Write it then throw it away". But I do write it, and then refactor, reimplement as needed mercilessly and without fear.
According to Fred Brooks... (Score:2)
If you are encountering a truly new programming problem,
Why assume first tried idea is not good enough? (Score:2)
Simple (Score:2)
I donate all my first drafts to Microsoft.