111–120 of 177 posts
We often say that we hate reinventing the wheel. But life is actually full of reinventing-the-wheel experiences. Maybe that's the point of a life.
My employer started quickly and grew exponentially ... but ... our client requirements didn't stay fixed. What were N pieces eventually had to be integrated because clients didn't wanna hear subsystem N1 works with N3 but not N5. And after around 10 years a lot of that code became debt, and the company has had to fix/remove/evolve it while it works in production for any number of reasons: it's too slow; it doesn't scale; we relied on vertical scaling and that's long dead; can't know or can't well manage capacity concerns; customer A's load breaks customer B's work; the code is so over hacked it's a big ball of mud etc.. And eventually software engineering concerns become cool again. This is a long way to say that true success inevitably brings with it the need to expand and integrate. Here maintainability is a core business strategy.
Here's something else worth remembering: the old school idea of TQA (true quality attributes) v. SQA (substitute quality attributes). Nobody (minus experts) rolls into a dealer and starts by asking the steel v. aluminum mix of the block. They don't ask how mm of coating was put on the __widget_here__ Those are SQAs. They ask about TQAs: price, quality, warranty, HP, resell value, whether it has AWS, power steering etc... but if anyone of those things breaks and the dealer has to fix it or the manufacture has to do a recall, the focus goes right back to the SQAs, the opportunity defects which allows those crappy SQAs etc.. etc.. So yes the client doesn't care what's under the hood, until one day you have to because one of the TQAs is violated. SQAs are the producers/suppliers implementation to gain the TQAs. They are separated in time --- time to when the client sees an issue --- but not in cause and effect. Software isn't magic. A lot of the SQAs eventually align with maintainability for the long haul.
"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…
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.
Earlier quoted context omitted.
Do you throw that code away and start over when you're done prototyping?
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.
"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 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…
Earlier quoted context omitted.
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.
> 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.
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.
I care about my clean code. Nearly every line of code I write is "clean", because it affects the bottom line . Messy codebases and bad architecture quadratically drive up the cost of development time. I've experienced this countless times for over 10 years, and it's endlessly frustrating. The state of web has gotten so tirelessly messy, I had to write my own framework to return to the clean web architecture we once h…
"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…
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.
Earlier quoted context omitted.
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.
> 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 wor…