91–100 of 230 posts
But IAC... I would much rather throw away someone else' code. :D
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.
Earlier quoted context omitted.
I don't really feel that attraction to complete rewriting. I wonder if the people who do are very smart, and thus able to hold more state in their head, so ugly code bothers them more even if it's not actively a problem, because they are able to have background tasks in their mind to worry about it? And at the same time, perhaps their code is less encapsulated, because they didn't optimize for abstraction, they optim…
Speaking personally my urge to rewrite at least partially comes from not truly understanding the problem and the solutions to it until I've written something reasonably functional. It doesn't matter how much time I put into sitting and theorizing, there's always things I didn't anticipate and assumptions that turned out to be incorrect. This usually means that rewrites are significant improvements across the board, e…
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…
Earlier quoted context omitted.
Throwing away an established code base is a completely different thing from throwing away a few-days-old prototype, and not what the article is suggesting. The points you mention don't apply to the prototype case.
Yeah, this thread is a somewhat strange read. People don't seem to understand what "draft" or "prototype" means. Odd.
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 yo…
I’m extremely defensive and try to think through everything. Aside from analysis paralysis which is a real obstacle, it’s still not enough. Or rather, it’s not the best way to use a human brain. At some point for a complex project, no matter how smart and experienced you are, assumptions break down. The mental model changes based on “friction” with the gritty world. Prototyping is one way to confront wrong assumptions earlier rather than later.
All creative and intellectual endeavors have analogous process. Writers don’t structure a book and write it perfectly in a methodical fashion. Basically, turning chaos into order can – almost per definition – not be proceduralized.
Earlier quoted context omitted.
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.
Sabotage your prototypes then. Have it reset its state every 5 minutes or deliberately leak memory.
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.
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 prem…