[kerkeslager]

I'm not sure I could count the number of 100-line long throwaway scripts that I wrote that are still being used in production systems before I realized how dangerous that idea is and stopped treating any code as throwaway code. If I show my code to another human, there's a chance it will end up in production.

The Pragmatic Programmer says to throw away prototypes, but in practice it always seems easier to click the merge button than to rewrite working code.

[amichal]

And what utility did it provide while it was in production for the effort that was put into it? We had a nasty nasty 3k line Perl script “in production” at a former client for like 10 years. It was written in a couple of weeks by another outside vendor and did it’s job well enough. It had basically zero abstractions. Minimal dependencies. Did one thing and was well commented on intent. The investment vs utility made it last a long time. Yee, rewriting a decade later with minimal Perl knowledge wasn’t fun but the business rules had also evolved so we really used it as reference docs and did just fine

[lonelappde]

Reverse-survivor bias.

You aren't seeing the non-existence all the well engineered stuff you never had time to build "properly".

[kerkeslager]

So?

If only 1 in 10 throwaway scripts survives, that can easily cost more in the long run than writing all 10 scripts in a sustainable way.

The open secret is that you almost always have time to do it properly. Doing it properly doesn't take that much more time, and most deadlines are self-imposed and artificial.

EDIT: Time isn't actually the most important cost. Not my code, but a coworker's throwaway script where he thought, "We'll just log this to a file for now" filled up a production DB server with log entries and took down a high-traffic e-commerce site for 6 hours. That easily cost more money than an entire career's worth of "doing it properly". There were obviously multiple mistakes that allowed that to happen, but removing the "we'll do this properly later" mistake would have prevented it.

[an_ko]

It sounds like the problem was really about failing to document technical debt.

> Doing it properly doesn't take that much more time

If you don't have a cutting board for a small thing, surely you wouldn't put your cooking on hold to drive out to the kitchen supply shop to buy a cutting board. You'd just use a stack of cardboard or something. (And make a note to buy a proper cutting board later, of course.)

[kerkeslager]

> It sounds like the problem was really about failing to document technical debt.

Technical debt is inevitable, and it will never be adequately documented. That's not really the situation we're talking about here.

This is more about stuff that was written with the mindset of "this will go into prod" versus "this will never go into prod". If your code is never going into prod, it's often acceptable to have huge, critical bugs--that's a very different thing from technical debt.

> If you don't have a cutting board for a small thing, surely you wouldn't put your cooking on hold to drive out to the kitchen supply shop to buy a cutting board. You'd just use a stack of cardboard or something. (And make a note to buy a proper cutting board later, of course.)

Well, sure, but this is a great example of why analogies aren't a good way to make arguments.

You're talking about using the right tools, not doing things properly. Sure, if I don't have the right tools, I'd do the best I can with the tools I have. But you'd better bet that a professional chef shouldn't just skip chopping the carrots because "it's just a throwaway dish, no need to do this properly" when there's a chance that it's going to be served to a food critic.

[volgar1x]

So what ? You care too much about these things.