8 ms·

"throw the first one away" When I'm prototyping or hacking something together, I don't write tests, I don't comment/document much, I use lots of shitty variabl

"throw the first one away" When I'm prototyping or hacking something together, I don't write tests, I don't comment/document much, I use lots of shitty variable/type names, lots of commented out code, debugging printfs, not much organization of files (often one large file). The prototype software is write-once, read-maybe. Maybe I'll want to see what I did down the road, but more likely I'll be shortly rewriting what I did somewhere else, using the fresh state still in my head. That next thing? If it's meaningful in any way and I want other humans (or future me) to expose their sight-orbs to it, then it'll be "clean code" to the best of my ability. While users won't care what your code looks like, they DO care about bugs, new feature turnaround, and downtime, all of which are exasperated by shitty code. You don't want to be staying up late on the weekend unfucking something you fucked up three years ago. Don't write shitty code for other people. That includes future-you.

bartimus 6y ago
Then also the core parts (with many dependents) deserve more elegance and readability compared to some less critical side module that can easily be thrown away and replaced.
StavrosK 6y ago
When I'm prototyping or hacking something together, it eventually becomes production. I cannot relate to people who make prototypes to throw away, I've never done it, and I don't know why I'd do it. Due to that, I write my first line of code as if it's going to be on production forever, because it will.
- deepGem 6y ago
  I have done quite a lot of prototypes and while the initial ones were throw away code, I quickly realized that I can re-use a lot of code in future prototypes. Especially code that involves building user management and database access. Also realized it is frustrating to write repeating code. So I quickly started making code slightly more readable and reusable. It's not the holy grail of software development but it ain't shitty code either. Also I tend to use only one web framework - FastAPI, one database - mostly Redis or MySQL and one front end React. Saves a ton of time as I can reuse a most parts of the code. I do think there is a lot of merit in using something like GAE. Saves a boat load of time but comes at a cost and I am willing to bear the cost to save time.
- deleted 6y ago
  [deleted]
- gfodor 6y ago
  I rarely prototype but the scenarios where I do are in the game engine context where I’m trying to hack together a real time graphics algorithm, meshing algorithm, etc. The difference between a one second and 15 second iteration time is meaningful.
  - StavrosK 6y ago
    Do you throw that code away and start over when you're done prototyping?
    - mixmastamyk 6y ago
      Semantics, but yes in a partial sense. When dissatisfied with an approach I'll often copy a class/function or three into new versions. I'll append the names of the old with 0. Then I start writing new ones with the new approach. In effect throwing the old ones away, even if sometimes it is a gradual process. This happens frequently in a new project, less frequently in a maturing project, to never in a maintenance project. However, it has a lot in common with (a severe) refactoring. Generally you're keeping the "overhead" docs, code, and even files, so it is not a complete rebirth, perhaps ~30% of the core code.
    - jacobolus 6y ago
      I would recommend you try writing hacky code and then throwing it away and starting from scratch a couple times on the same project idea, just to see how it goes. It might teach you something. The people I know who regularly take this approach end up with a really fantastic code architecture in the end, and avoid a lot of pitfalls from their first naïve attempts.
      - deleted 6y ago
        [deleted]
- pansa2 6y ago
  > I cannot relate to people who make prototypes to throw away, I've never done it, and I don't know why I'd do it. When I'm at the prototyping stage, I don't yet know how to solve the problem. That means I need to iterate quickly, which affects my choice of language (Python) and the amount of time I'm willing to spend keeping code clean (very little, because I could hit a dead-end at any point). But once I have a working prototype of a solution, my users need it in the form of a fast, standalone binary, and my colleagues need code that can be easily understood. This requires using a different language (C++) and more disciplined coding practices. The only way to get this is to rewrite for production, and then "throw away" the prototype.
  - confounded 6y ago
    Is this stealth promotion for Go?
    - nine_k 6y ago
      Go does not have a REPL with interactive introspection and fiddling capabilities. Such a thing is key for prototyping.
      - loopz 6y ago
        go run main.go works just fine and is blazing fast compared to many compiled langs. There's also scripted go, which may solve some of what you need. Print debugging works for 99% of introspection needs. Most times go does just as advertised, though learn of common pitfalls to avoid. Haskell has REPL and dynamic introspection, but everything takes 4-20 longer times. Maybe it's faster/better with massive practice. Honestly, most codebases just sucks, including my own, unless you redo alot and put deliberate efforts over time. Which is irrelevant to sales (point in link). Alot of value in battle-tested code turns invisible too, locking knowledge away in obscurity. Go at least is pretty readable and mostly explicit.
        orwin 6y ago
        REPL with hot-loading is better than print debugging, especially if you work with graphics, but also if you do weird stuff in the memory space than make strings unreadable for human beings. That said, gdb is probably in the same space as git is: hard to fully use, but the best in its own space.
- geofft 6y ago
  Then write your code as if someone's going to throw production away - which generally means writing documentation (design docs, good commit messages, comments on the tricky parts of the code, API contracts between components, etc.), so that if someone thinks they want to to reimplement production, that decision can stand on its own merits. All of the worst production systems I've worked with are systems where people are running code from many many years ago because they don't know what it does and are scared to touch it. Write one to throw away, even - perhaps especially - if it goes into production. Write production to throw away.
  - ghoward 6y ago
    If you have a blog, make a production version of your comment and post it because what you said is something every developer should at least consider.
- AussieWog93 6y ago
  >I cannot relate to people who make prototypes to throw away, I've never done it, and I don't know why I'd do it. I did it a lot through university. If you have no experience tackling a certain type of problem, your perception of it tends to change significantly as you build the solution and become familiar with the problem space. It makes sense to throw away what you've written, because most of it was based on assumptions that were wrong.
- Mandatum 6y ago
  Depends on the company environment. If your company does MVP's regularly to trial out stuff or features to get projects funded, they're more than likely will fund a short sprint to prove the concept or idea works and gauge if it's worth fully funding. These orgs move fast, have lots of tech talent and budget. They're usually ahead of other companies in terms of features or offerings. Other companies take ideas, consider them long and hard - and usually follow other orgs doing something similar who have already proven something works. They do a lot of planning and tend to put much more funding in up-front. Both approaches suit different businesses. The former being startups and SME's, the latter where market share is already won and now they just acquire other businesses that develop the former way. If we're considering what people develop at home however.. 99.9% of the stuff I write is never publicly visible, and it's terrible because I'm not a great developer. But I'm not a regular open-source contributor. I issue the occasional patch for shit that's broken for me.
  - zikzak 6y ago
    I did exactly this recently at work. I had a feature set I've been wanting to add to the customer service portal but very little time approved so we built a part of it using very little dev time. The feature was very popular and well used. Everyone wanted it expanded to do more (basically a task system which saves people from ad hoc management of various tasks). Before too long, the full version was approved and was built in very short order because of lessons learned with the mvp.
- MattGaiser 6y ago
  Currently on a project initially written with throwaway code. It became a production project. The code survives to this day and we don't dare poke it too much.
  - rapind 6y ago
    This. However for the last while I’ve been using a language on the front end that let’s me prototype ideas with a slightly higher up front cost and then when it ends up in production it’s close to bulletproof and easier to refactor (not that I always get the chance, but I still feel safer knowing it probably won’t break). Then if the code / project / product refuses to die (success!), I can come back some day and refactor without being scared to dig in again. So even though my original code is a bit messy, I’m not scared to change it a couple years later.
- wvenable 6y ago
  When I was working on this https://codaris.github.io/UnderDeskBike/ https://codaris.github.io/UnderDeskBike/ I honestly didn't know if what I wanted to do was even possible at many layers. I didn't know how to do Bluetooth. I knew nothing. It's not worth doing things "the right way" right off the bat because you might not know what that is. My first version was literally a linear file of statements and console output. Once I got something working and understood the problem space then I could back and fix it up. The final code looks like nothing like the original prototype although at no point did I actually throw it away -- I just transformed it heavily -- but the theory is the same. It started as a console app even though the final product was not one.
  - loopz 6y ago
    This is really how all new code is birthed. You start build something from no prior knowledge and few assumptions. It gives maximum agility and freedom to pursue multiple paths initially.
    - wvenable 6y ago
      Well the other way to approach the problem is to basically craft out a whole framework: create classes/interfaces/tests and slowly fill them in. Occasionally I will code that way when I'm fairly certain of what I'm doing but you have to be very careful that you're not painting yourself into a corner. In my experience, new programmers tend to build a lot of structure for their code that it's not clear they even need yet or will ever need and then often end up solving a problem with much more code than was necessary. It's usually my advice to get something (anything) working end-to-end first and then expand on that rather than the more linear approach.
- spondyl 6y ago
  > I've never done it, and I don't know why I'd do it. The original waterfall paper[1] advocated for doing an initial version, by which point you'll have understood the problem domain (in miniature) enough to make a better attempt by throwing it all away and reassessing what tradeoffs make sense. > Without this simulation the project manager is at the mercy of human judgment. With the simulation he can at least perform experimental tests of some key hypotheses and scope down what remains for human judgment, which in the area of computer program design (as in the estimation of takeoff gross weight, costs to complete, or the daily double) is invariably and seriously optimistic. [2] The myth goes that someone in the Department of Defense looked at the first diagram (which the author claims right underneath is flawed), copied it in a rush for a diagram and that became enshrined in history as "How best to develop software" until agile and what not [1]: http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970... [2]: Page 7 of the above PDF
- comboy 6y ago
  I can relate to both of you. It just depends on size and complexity of the project.
- edgyquant 6y ago
  I use to write a prototype and rewrite, before I worked in startups. Now days I write once and it’s in prod within a couple of days. It has taken some adjustments, to be sure, my first ~6 months was full of submitting little mistakes that I normally would have caught in the rewrites.
- nine_k 6y ago
  > I cannot relate to people who make prototypes to throw away, I've never done it Have you ever had that moment when you say: "Oh damn, now I got it! I should do it entirely differently!" — and then you code up a different approach, the approach that works well enough. If you had this moment, it was the moment of throwing away the prototype.
  - arvinsim 6y ago
    This occurs frequently. Convincing management to refactor your code is another thing entirely.
  - the_af 6y ago
    Yes, but this often occurs a few months or years into production, way too late to throw it away. I've never written a prototype, nor seen one written, in actual businesses. I've never had an employer with the patience to let me play with a prototype either.
    - nine_k 6y ago
      If it happens years into production, especially after the load has increased or requirements have changed, it is a legitimate version 2 :)
      - loopz 6y ago
        I've seen rewrites introducing massive bughunts and upsetting customers without improving too much. I've also seen customers expecting and even relying on old bugs for comfort. Rewrite is always a business decision and need legitimate reasons. You rarely have those reasons, knowledge and time between projects.
        nine_k 6y ago
        I like to remember how eBay have rewritten their backend three times. Not because the previous version was wrong, but because it became inadequate as business grew and requirements changed.
- asiachick 6y ago
  So I just hacked together an animated LED strip lamp on an Arduino. I didn't write any tests or setup production. What would you have done? To me, "I write my first line of code as if it's going to be on production forever" means setting up a testing infrastructure, a reproducible build that can be automated, a CI that runs my tests. An auto-commit system where I can create a PR and submit it to the CI and if it passes it will automatically get merged to main, etc... Instead of my lamp project taking 1-3 hrs it would have been a week of setting all this up before I was ready to write my first line of actual code. Are you saying you'd actually take that week? Would you therefore never write something on shadertoy because it's missing all that infrastructure and you can't write code as if it's going to be in production forever?
- Impossible 6y ago
  You do it to understand the problem you're working on before you start writing production code. If you understand the problem you're working on, there's no need for prototyping, which is probably true for most code an average programmer writes. I tend to write prototype code to learn how something new works before writing production code, or when I have multiple ideas how a system should work and need to iterate on them and pick what I should actually ship. If you know you need to build a specific feature and how it should work you don't have to prototype it.
- Ygg2 6y ago
  Yeah, as the proverb goes "Temporary solution last the longest".
- mbrodersen 6y ago
  Same here. As I learn more and find better ways to do things, I simply spend a few minutes refactoring the code to improve it. I also program to interfaces so that subsystems can be completely rewritten/refactored with only local impact.
- deleted 6y ago
  [deleted]
herval 6y ago
Honest question - does that really make you finish up prototyping faster than having SOME level of organization? Unless I’m coding something so quick that I’ll be done in the same couple of hours, I feel like at least having some sensible names for things, some comments here and there (in particular TODOs), etc helps think (and prototype) much faster.
learningwebdev 6y ago
I'm still teaching myself full-stack web development but I've worked on a couple of projects with a friend who has a great amount of skill and experience. I was slightly horrified to see the kinds of haphazard and occasionally mildly crude comments he was putting in code and git commits, especially since I am very much a perfectionist, but... he gets the job done, and he gets it done well. I think a good team or a good partnership comes from finding one or more other people whose strengths offset your weaknesses and vice versa.
mberning 6y ago
I do understand the sentiment. However I do think there is something to be said for maintaining good habits all or most of the time. It’s kind of like saying I eat trash all time, but when I need to get in shape, I can stick to a diet. Easy to say, hard to do.
worik 6y ago
Not a good idea. That is not a good idea of you let anybody in a management role see your prototype. It will be the product. They will start selling it straight away. If there are any problems, you, my dear young and foolish friend, will be the one at fault. It is your wonderful self that will staying up all hours desperately trying to fix the problems. Otherwise peachy!
- atomicity 6y ago
  I do not understand how you cannot easily "spin" a prototype that the company wants to sell into a good thing. When you write that awesome prototype, your management will be thinking about rewarding you, not blaming you. They will listen to your concerns. So, you can say that it's not ready. You can mention that you alone are not enough to fix the bugs that come up in greenfield code right away. You can even ask for people to help on your project. Why would management say no if they want to sell it? Then when a manageable amount of bugs come down the road and everybody is happy, you are now in a far better position to negotiate a higher salary. You have far more responsibility. You have a great track record. Nobody wants you to leave. The cost of developing a prototype when you handle every error you see along the way, set up all of those dev tools (tests, logs, CI, formatting, etc.), and test every branch like a madman is too high. You'll probably end up taking weeks to develop something that you could "code in a weekend". Then, since you never verified, it may turn out that nobody wants to use the prototype for obvious reasons
  - worik 6y ago
    Spin? My leaky, fragile, missing important parts, flaky prototype has been sold for a lot of money and is now supporting business decisions.... Spin? Like tail spin.... When the prototype explodes in exactly the way I expect it to management are not going to reward me... I said it is not ready. Several times. To the point where management stopped taking my calls..... Manageable amount of bugs? There is a problem of definition here. The cost of developing a prototype that demonstrates the interesting and cool parts of the project - whilst leaving the tricky bits for implementation is my job. So I gota ask: that cost is too high for whom? It has been fun....
- 6y ago
kstenerud 6y ago
I do the opposite: - I paper prototype until we have something that makes sense, fills the space our crew sees an opportunity in, and seems to do the job without needing too much work to implement. Takes about half a day to a day of "what if we did this" and "how about that" scribbling to do this if everyone's available and focused, and then we discuss what we have and whether it works for us and whether we actually have a business or not. - Next, I spend a day or two thinking: What architecture makes the most sense? What language makes the most sense (in terms of what it can do for us and how many people know it)? What technologies will cut away the most work without requiring a lot of shoe-horning? etc. - Next, I write the minimum within that framework to get a visual prototype that allows us to go through the various sections and see it in action. - Next, we look at this prototype and decide how closely it matches our vision, and whether our vision needs changing. From there, the most common changes to the actual code are tweaks to systems rather than the whole architecture, but the architecture itself makes this easy since it's designed to be modular for our particular use case. I actually can't think of a single prototype that I've thrown away to rewrite in the last 20 years, including a complex 6-minigame educational product I brought from zero to live-and-generating-revenue in the app store in 3 months as the only developer. Clean code isn't for your clients; it's for YOU and your team. Clean architecture, code and discipline make your work go easier and faster IF you actually do it. If you're starting with code prototypes rather than paper prototypes, you're doing it wrong and it will take you longer as a result (and you'll probably also need a rewrite).
- scrubs 6y ago
  Wanna know what? Amen to that approach. Nothing like throw away papers and throw away prototypes. Nothing like getting the team on the same page --- more grounded in reality than chit chat or PPTs or bubbles and arrows --- while not under pressure to cross Ts and dot Is.
m463 6y ago
> The prototype software is write-once, read-maybe. "aaaand, I'm going to need to pull you off of this xyzzy, and put you on this high-priority-showstopper-stop the presses project ..." and then 10 years later you're writing this blog article where you explain where someone else shipped unfinished code and ...

bartimus 6y ago

Then also the core parts (with many dependents) deserve more elegance and readability compared to some less critical side module that can easily be thrown away and replaced.

StavrosK 6y ago

When I'm prototyping or hacking something together, it eventually becomes production. I cannot relate to people who make prototypes to throw away, I've never done it, and I don't know why I'd do it. Due to that, I write my first line of code as if it's going to be on production forever, because it will.

deepGem 6y ago
I have done quite a lot of prototypes and while the initial ones were throw away code, I quickly realized that I can re-use a lot of code in future prototypes. Especially code that involves building user management and database access. Also realized it is frustrating to write repeating code. So I quickly started making code slightly more readable and reusable. It's not the holy grail of software development but it ain't shitty code either. Also I tend to use only one web framework - FastAPI, one database - mostly Redis or MySQL and one front end React. Saves a ton of time as I can reuse a most parts of the code. I do think there is a lot of merit in using something like GAE. Saves a boat load of time but comes at a cost and I am willing to bear the cost to save time.
deleted 6y ago
[deleted]
gfodor 6y ago
I rarely prototype but the scenarios where I do are in the game engine context where I’m trying to hack together a real time graphics algorithm, meshing algorithm, etc. The difference between a one second and 15 second iteration time is meaningful.
- StavrosK 6y ago
  Do you throw that code away and start over when you're done prototyping?
  - mixmastamyk 6y ago
    Semantics, but yes in a partial sense. When dissatisfied with an approach I'll often copy a class/function or three into new versions. I'll append the names of the old with 0. Then I start writing new ones with the new approach. In effect throwing the old ones away, even if sometimes it is a gradual process. This happens frequently in a new project, less frequently in a maturing project, to never in a maintenance project. However, it has a lot in common with (a severe) refactoring. Generally you're keeping the "overhead" docs, code, and even files, so it is not a complete rebirth, perhaps ~30% of the core code.
  - jacobolus 6y ago
    I would recommend you try writing hacky code and then throwing it away and starting from scratch a couple times on the same project idea, just to see how it goes. It might teach you something. The people I know who regularly take this approach end up with a really fantastic code architecture in the end, and avoid a lot of pitfalls from their first naïve attempts.
    - deleted 6y ago
      [deleted]
pansa2 6y ago
> I cannot relate to people who make prototypes to throw away, I've never done it, and I don't know why I'd do it. When I'm at the prototyping stage, I don't yet know how to solve the problem. That means I need to iterate quickly, which affects my choice of language (Python) and the amount of time I'm willing to spend keeping code clean (very little, because I could hit a dead-end at any point). But once I have a working prototype of a solution, my users need it in the form of a fast, standalone binary, and my colleagues need code that can be easily understood. This requires using a different language (C++) and more disciplined coding practices. The only way to get this is to rewrite for production, and then "throw away" the prototype.
- confounded 6y ago
  Is this stealth promotion for Go?
  - nine_k 6y ago
    Go does not have a REPL with interactive introspection and fiddling capabilities. Such a thing is key for prototyping.
    - loopz 6y ago
      go run main.go works just fine and is blazing fast compared to many compiled langs. There's also scripted go, which may solve some of what you need. Print debugging works for 99% of introspection needs. Most times go does just as advertised, though learn of common pitfalls to avoid. Haskell has REPL and dynamic introspection, but everything takes 4-20 longer times. Maybe it's faster/better with massive practice. Honestly, most codebases just sucks, including my own, unless you redo alot and put deliberate efforts over time. Which is irrelevant to sales (point in link). Alot of value in battle-tested code turns invisible too, locking knowledge away in obscurity. Go at least is pretty readable and mostly explicit.
      - orwin 6y ago
        REPL with hot-loading is better than print debugging, especially if you work with graphics, but also if you do weird stuff in the memory space than make strings unreadable for human beings. That said, gdb is probably in the same space as git is: hard to fully use, but the best in its own space.
geofft 6y ago
Then write your code as if someone's going to throw production away - which generally means writing documentation (design docs, good commit messages, comments on the tricky parts of the code, API contracts between components, etc.), so that if someone thinks they want to to reimplement production, that decision can stand on its own merits. All of the worst production systems I've worked with are systems where people are running code from many many years ago because they don't know what it does and are scared to touch it. Write one to throw away, even - perhaps especially - if it goes into production. Write production to throw away.
- ghoward 6y ago
  If you have a blog, make a production version of your comment and post it because what you said is something every developer should at least consider.
AussieWog93 6y ago
>I cannot relate to people who make prototypes to throw away, I've never done it, and I don't know why I'd do it. I did it a lot through university. If you have no experience tackling a certain type of problem, your perception of it tends to change significantly as you build the solution and become familiar with the problem space. It makes sense to throw away what you've written, because most of it was based on assumptions that were wrong.
Mandatum 6y ago
Depends on the company environment. If your company does MVP's regularly to trial out stuff or features to get projects funded, they're more than likely will fund a short sprint to prove the concept or idea works and gauge if it's worth fully funding. These orgs move fast, have lots of tech talent and budget. They're usually ahead of other companies in terms of features or offerings. Other companies take ideas, consider them long and hard - and usually follow other orgs doing something similar who have already proven something works. They do a lot of planning and tend to put much more funding in up-front. Both approaches suit different businesses. The former being startups and SME's, the latter where market share is already won and now they just acquire other businesses that develop the former way. If we're considering what people develop at home however.. 99.9% of the stuff I write is never publicly visible, and it's terrible because I'm not a great developer. But I'm not a regular open-source contributor. I issue the occasional patch for shit that's broken for me.
- zikzak 6y ago
  I did exactly this recently at work. I had a feature set I've been wanting to add to the customer service portal but very little time approved so we built a part of it using very little dev time. The feature was very popular and well used. Everyone wanted it expanded to do more (basically a task system which saves people from ad hoc management of various tasks). Before too long, the full version was approved and was built in very short order because of lessons learned with the mvp.
MattGaiser 6y ago
Currently on a project initially written with throwaway code. It became a production project. The code survives to this day and we don't dare poke it too much.
- rapind 6y ago
  This. However for the last while I’ve been using a language on the front end that let’s me prototype ideas with a slightly higher up front cost and then when it ends up in production it’s close to bulletproof and easier to refactor (not that I always get the chance, but I still feel safer knowing it probably won’t break). Then if the code / project / product refuses to die (success!), I can come back some day and refactor without being scared to dig in again. So even though my original code is a bit messy, I’m not scared to change it a couple years later.
wvenable 6y ago
When I was working on this https://codaris.github.io/UnderDeskBike/ https://codaris.github.io/UnderDeskBike/ I honestly didn't know if what I wanted to do was even possible at many layers. I didn't know how to do Bluetooth. I knew nothing. It's not worth doing things "the right way" right off the bat because you might not know what that is. My first version was literally a linear file of statements and console output. Once I got something working and understood the problem space then I could back and fix it up. The final code looks like nothing like the original prototype although at no point did I actually throw it away -- I just transformed it heavily -- but the theory is the same. It started as a console app even though the final product was not one.
- loopz 6y ago
  This is really how all new code is birthed. You start build something from no prior knowledge and few assumptions. It gives maximum agility and freedom to pursue multiple paths initially.
  - wvenable 6y ago
    Well the other way to approach the problem is to basically craft out a whole framework: create classes/interfaces/tests and slowly fill them in. Occasionally I will code that way when I'm fairly certain of what I'm doing but you have to be very careful that you're not painting yourself into a corner. In my experience, new programmers tend to build a lot of structure for their code that it's not clear they even need yet or will ever need and then often end up solving a problem with much more code than was necessary. It's usually my advice to get something (anything) working end-to-end first and then expand on that rather than the more linear approach.
spondyl 6y ago
> I've never done it, and I don't know why I'd do it. The original waterfall paper[1] advocated for doing an initial version, by which point you'll have understood the problem domain (in miniature) enough to make a better attempt by throwing it all away and reassessing what tradeoffs make sense. > Without this simulation the project manager is at the mercy of human judgment. With the simulation he can at least perform experimental tests of some key hypotheses and scope down what remains for human judgment, which in the area of computer program design (as in the estimation of takeoff gross weight, costs to complete, or the daily double) is invariably and seriously optimistic. [2] The myth goes that someone in the Department of Defense looked at the first diagram (which the author claims right underneath is flawed), copied it in a rush for a diagram and that became enshrined in history as "How best to develop software" until agile and what not [1]: http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970... [2]: Page 7 of the above PDF
comboy 6y ago
I can relate to both of you. It just depends on size and complexity of the project.
edgyquant 6y ago
I use to write a prototype and rewrite, before I worked in startups. Now days I write once and it’s in prod within a couple of days. It has taken some adjustments, to be sure, my first ~6 months was full of submitting little mistakes that I normally would have caught in the rewrites.
nine_k 6y ago
> I cannot relate to people who make prototypes to throw away, I've never done it Have you ever had that moment when you say: "Oh damn, now I got it! I should do it entirely differently!" — and then you code up a different approach, the approach that works well enough. If you had this moment, it was the moment of throwing away the prototype.
- arvinsim 6y ago
  This occurs frequently. Convincing management to refactor your code is another thing entirely.
- the_af 6y ago
  Yes, but this often occurs a few months or years into production, way too late to throw it away. I've never written a prototype, nor seen one written, in actual businesses. I've never had an employer with the patience to let me play with a prototype either.
  - nine_k 6y ago
    If it happens years into production, especially after the load has increased or requirements have changed, it is a legitimate version 2 :)
    - loopz 6y ago
      I've seen rewrites introducing massive bughunts and upsetting customers without improving too much. I've also seen customers expecting and even relying on old bugs for comfort. Rewrite is always a business decision and need legitimate reasons. You rarely have those reasons, knowledge and time between projects.
      - nine_k 6y ago
        I like to remember how eBay have rewritten their backend three times. Not because the previous version was wrong, but because it became inadequate as business grew and requirements changed.
asiachick 6y ago
So I just hacked together an animated LED strip lamp on an Arduino. I didn't write any tests or setup production. What would you have done? To me, "I write my first line of code as if it's going to be on production forever" means setting up a testing infrastructure, a reproducible build that can be automated, a CI that runs my tests. An auto-commit system where I can create a PR and submit it to the CI and if it passes it will automatically get merged to main, etc... Instead of my lamp project taking 1-3 hrs it would have been a week of setting all this up before I was ready to write my first line of actual code. Are you saying you'd actually take that week? Would you therefore never write something on shadertoy because it's missing all that infrastructure and you can't write code as if it's going to be in production forever?
Impossible 6y ago
You do it to understand the problem you're working on before you start writing production code. If you understand the problem you're working on, there's no need for prototyping, which is probably true for most code an average programmer writes. I tend to write prototype code to learn how something new works before writing production code, or when I have multiple ideas how a system should work and need to iterate on them and pick what I should actually ship. If you know you need to build a specific feature and how it should work you don't have to prototype it.
Ygg2 6y ago
Yeah, as the proverb goes "Temporary solution last the longest".
mbrodersen 6y ago
Same here. As I learn more and find better ways to do things, I simply spend a few minutes refactoring the code to improve it. I also program to interfaces so that subsystems can be completely rewritten/refactored with only local impact.
deleted 6y ago
[deleted]

herval 6y ago

Honest question - does that really make you finish up prototyping faster than having SOME level of organization? Unless I’m coding something so quick that I’ll be done in the same couple of hours, I feel like at least having some sensible names for things, some comments here and there (in particular TODOs), etc helps think (and prototype) much faster.

learningwebdev 6y ago

I'm still teaching myself full-stack web development but I've worked on a couple of projects with a friend who has a great amount of skill and experience. I was slightly horrified to see the kinds of haphazard and occasionally mildly crude comments he was putting in code and git commits, especially since I am very much a perfectionist, but... he gets the job done, and he gets it done well. I think a good team or a good partnership comes from finding one or more other people whose strengths offset your weaknesses and vice versa.

mberning 6y ago

I do understand the sentiment. However I do think there is something to be said for maintaining good habits all or most of the time. It’s kind of like saying I eat trash all time, but when I need to get in shape, I can stick to a diet. Easy to say, hard to do.

worik 6y ago

Not a good idea. That is not a good idea of you let anybody in a management role see your prototype. It will be the product. They will start selling it straight away. If there are any problems, you, my dear young and foolish friend, will be the one at fault. It is your wonderful self that will staying up all hours desperately trying to fix the problems. Otherwise peachy!

atomicity 6y ago
I do not understand how you cannot easily "spin" a prototype that the company wants to sell into a good thing. When you write that awesome prototype, your management will be thinking about rewarding you, not blaming you. They will listen to your concerns. So, you can say that it's not ready. You can mention that you alone are not enough to fix the bugs that come up in greenfield code right away. You can even ask for people to help on your project. Why would management say no if they want to sell it? Then when a manageable amount of bugs come down the road and everybody is happy, you are now in a far better position to negotiate a higher salary. You have far more responsibility. You have a great track record. Nobody wants you to leave. The cost of developing a prototype when you handle every error you see along the way, set up all of those dev tools (tests, logs, CI, formatting, etc.), and test every branch like a madman is too high. You'll probably end up taking weeks to develop something that you could "code in a weekend". Then, since you never verified, it may turn out that nobody wants to use the prototype for obvious reasons
- worik 6y ago
  Spin? My leaky, fragile, missing important parts, flaky prototype has been sold for a lot of money and is now supporting business decisions.... Spin? Like tail spin.... When the prototype explodes in exactly the way I expect it to management are not going to reward me... I said it is not ready. Several times. To the point where management stopped taking my calls..... Manageable amount of bugs? There is a problem of definition here. The cost of developing a prototype that demonstrates the interesting and cool parts of the project - whilst leaving the tricky bits for implementation is my job. So I gota ask: that cost is too high for whom? It has been fun....
6y ago

kstenerud 6y ago

I do the opposite: - I paper prototype until we have something that makes sense, fills the space our crew sees an opportunity in, and seems to do the job without needing too much work to implement. Takes about half a day to a day of "what if we did this" and "how about that" scribbling to do this if everyone's available and focused, and then we discuss what we have and whether it works for us and whether we actually have a business or not. - Next, I spend a day or two thinking: What architecture makes the most sense? What language makes the most sense (in terms of what it can do for us and how many people know it)? What technologies will cut away the most work without requiring a lot of shoe-horning? etc. - Next, I write the minimum within that framework to get a visual prototype that allows us to go through the various sections and see it in action. - Next, we look at this prototype and decide how closely it matches our vision, and whether our vision needs changing. From there, the most common changes to the actual code are tweaks to systems rather than the whole architecture, but the architecture itself makes this easy since it's designed to be modular for our particular use case. I actually can't think of a single prototype that I've thrown away to rewrite in the last 20 years, including a complex 6-minigame educational product I brought from zero to live-and-generating-revenue in the app store in 3 months as the only developer. Clean code isn't for your clients; it's for YOU and your team. Clean architecture, code and discipline make your work go easier and faster IF you actually do it. If you're starting with code prototypes rather than paper prototypes, you're doing it wrong and it will take you longer as a result (and you'll probably also need a rewrite).

scrubs 6y ago
Wanna know what? Amen to that approach. Nothing like throw away papers and throw away prototypes. Nothing like getting the team on the same page --- more grounded in reality than chit chat or PPTs or bubbles and arrows --- while not under pressure to cross Ts and dot Is.

m463 6y ago

> The prototype software is write-once, read-maybe. "aaaand, I'm going to need to pull you off of this xyzzy, and put you on this high-priority-showstopper-stop the presses project ..." and then 10 years later you're writing this blog article where you explain where someone else shipped unfinished code and ...