5 ms·
Great lessons! Although it didn't include one that I had to learn the hard way, multiple times: Your throwaway prototype will be the codebase for the project.
by koonsolo 7y ago
Great lessons! Although it didn't include one that I had to learn the hard way, multiple times:
Your throwaway prototype will be the codebase for the project.
In my career, I've seen multiple throwaway prototypes that were hacked together. None of them ended up in the waste bin.
"Just add X and Y and you're done". "But this is just a quick hack to show the interface, there is nothing behind it!" "Yes, and the interface is fine, so why start from scratch? Just add the rest".
Now I know: I never build throwaway prototypes ever again, it's always a base for the project to come.
- sadness2 7y agoHow about this: Code can add value when it's a lot lower quality than we think it needs to be. Customers will pay for even a crappy solution if you are addressing the right problem. Don't over engineer. But also employ staff for the explicit purpose of gradually increasing the quality of codebases which need to continue to churn.
- mgkimsal 7y ago> But also employ staff for the explicit purpose of gradually increasing the quality of codebases which need to continue to churn. No one ever wants to hear that part.
- sadness2 7y agoThat is either a problem with leadership, or with the way the role is being framed to them. Perhaps this will help your case: https://martinfowler.com/articles/is-quality-worth-cost.html https://martinfowler.com/articles/is-quality-worth-cost.html
- jmcqk6 7y agoI put it this way: There is no floor to how bad code can be and yet still make people money.
- EdgarVerona 7y agoI agree with your perspective on this, as hard as it can be to admit.
- hirundo 7y agoOnce I wrote non-prototype, non-throwaway code to start a large project. After about a month of work on that, due to a dead disk and my own stupidity, I lost all of it. It was throwaway code after all. I was about as upset and angry as I ever get. Then I sat down and rewrote it in about a week, and it was much better the second time, and turned out to be the start of a code base that's still in daily use and evolving 25 years later. The lesson I took from that is, don't write throwaway code, but given a chance, throw it away anyway.
- mgkimsal 7y agoI've had a couple of times where I've been called in to lend a hand on code I wrote 10-15 years earlier. I'm always surprised that it's still going, but perhaps shouldn't be (and may not be in the future). There's sometimes good reasons to upgrade/Greenfield - at some point, in one case, there were structural issues that prevented much more 'refactoring' without heavy work, and 'start over and migrate data' was a more cost effective option. But, until you've done this for 20 years, it's sort of hard to imagine going back to code you wrote 20 years earlier to work on it again. Many of those "best practices" take on a much more concrete meaning. In many cases, I've been ... moderately proud of how well some decisions stood up, and in other cases I remember exactly what I was doing when I cut a particular corner (was late getting home that night, needed to get back home before a winter storm, etc).
- dyarosla 7y agoCould not disagree more with the moral. Write prototypes for sure, toss code out a lot early on, and then once you’ve nailed the direction, start iterating on refactoring the prototype. But to eschew prototype code from the start? That’s a separate hard lesson in itself.
- moocowtruck 7y agooh wow so this...I have about a dozen such stories!
- pstuart 7y agoAdd 'em to the pile here!
- EdgarVerona 7y agoDefinitely true. And I think, in retrospect, that's not so bad. I think the important part is realizing - and convincing people to allocate time to it - when it needs to be refactored: when it reaches a point that it can't sustain itself and doesn't solve business problems anymore. Until then, if it's solving a business need and you're not pouring tons of effort/money into it, it's more about pride than a real problem. That is a lesson I had to learn the hard way, and still struggle with: accepting that sometimes a janky, hobbled-together solution that solves a business problem still solves that problem and might not be worth the cost of "fixing."
- Gibbon1 7y agoI'll hijack your comment to say, it's easier to justify refactoring something totally ass then something half ass. That argues against trying to do too good a job initially.
- lostmyoldone 7y agoIn a somewhat troubled company I worked at, and where I honestly stayed a bit too long, I once resorted to writing a prototype, in bash, and in the most idiosyncratic way possible with two goals in mind: 1) Make sure that I didn't have to handle some messy deployment when it inevitably would become rebranded to production code. 2) Make sure nobody in their right mind would try to extend the functionality and keep me responsible for fixing the inevitable wreck. Obviously it was put into production, still is, and has not been extended with anything except the initial functionality. I don't know if that counts as a success or a failure, but at least deployment was never an issue!
- deleted 7y ago[deleted]
- deleted 7y ago[deleted]
- reacweb 7y agoI love prototypes. You have the joy of the blank page, the freedom of the choice of COTS. You can ignore requirements that would introduce complexity. You do not need to follow the coding rules that impose verbosity. As a result, you can build something simple you can be proud of. The prototype is a showcase that allows to show how development could be faster if there was less stupid requirements and less coding constraints.
- hinkley 7y agoEvery problem is easy if you oversimplify the requirements.
- reacweb 7y agoThe purpose of a prototype is generally to tackle one or two of the difficulties (among UX, thread architecture, dataflow, performance, complexity of data, encoding/decoding, robustness...) while ignoring most of the others. The other requirements will come back, but at least you have a good solution of the most problematic ones.
- lhuser123 7y agoSome researchers wanted a 128-bit space for the binary address, Cerf (recalled) ... But others said, "That's crazy," because it's far larger than necessary, and they suggested a much smaller space. Cerf finally settled on a 32-bit space that was incorporated into IPv4 and provided a respectable 4.3 billion separate addresses. "It's enough to do an experiment," he said. "The problem is the experiment never ended." https://www.networkworld.com/article/2227543/software-why-ipv6-vint-cerf-keeps-blaming-himself.html https://www.networkworld.com/article/2227543/software-why-ip...
- travisjungroth 7y agoIMO, they should have gone with a wildly smaller number. Enough IP addresses to get ~10% of the world online is just about the worst possible pick. It’s enough to get entrenched, but not enough to finish the job. If it was 1024, they would have run into the problem while it was easily fixable. Y2K wouldn’t have been a problem if two-digit years started being used in 1999.
- bdamm 7y agoThe irony here is Y2K was just the start. We have Y2K-like problems coming up in 2038, 2050, 2106, and many others on smaller scales in between such as the 2036, 2040, and 2042. This tells me that it is not just poor judgement, but rather widespread systematic incomprehension regarding the longevity of systems, protocols, and data.
- p_l 7y agoThey did - original network addresses were, iirc, around 16 bit. Meanwhile OSI went with 20 byte maximum and strong preference for separating service and implementation and putting numeric addresses in implementation side...
- hinkley 7y agoThis got so bad for me that at one point I was doing all POC code as command line only. Because proving the code worked without a UI got us green lit but any UI they wanted to ship.
- trumbitta2 7y agoOnce I wrote a quick demo of a classic content-heavy portal with our in-house portal system (at the time). It took me 2 days over a weekend. Shipped for the demo with some partner, forgot about it. 6 months later, an angry customer wrote to my boss about the "Energy Saving Monitoring System" somebody sold to them stating that some kind of SSO wasn't working as expected. My boss handed the case to me and I, flabbergasted as I was, proceeded to delve deeper into the strange report about that system we were sure we've never written, let alone sold to somebody. Long story short, it was my quick demo of a content heavy portal, turned into that monster of a "Energy Saving Monitoring System" - whatever that is - by the partner we demoed it to, and sold to several customers as a finished product.
- WrtCdEvrydy 7y agoLOL, been there, done that.
- Thespian2 7y agoThere is nothing as permanent, as that which is called "temporary," and nothing as temporary, as that which is called "permanent." Applies to almost every bit of code I've written.
- hnick 7y agoAKA "Nothing is more permanent than a temporary solution." I think that cuts both ways - often the quick fix is good enough, while the "proper fix" is over-engineered and in promising to be all things to all people, anything missed becomes a sticking point and sinks the project.
- maxxxxx 7y agoI also try to write reasonable code for even the smallest projects. It doesn't have to be perfect but it should be possible to add the bells and whistles in straightforward manner. A lot of people seem to spend time thinking about whether they should do the right thing or not but I find it easier to not think about it and do the right thing by default.
- hasbroslasher 7y agoThis is some great advice in my opinion. Every project starts from a base - give it a shitty base, and you're always going to have problems. Spend the time to write an OK base that doesn't try to do anything clever but organizes code in a clear and sane way and you'll be reaping the dividends for years to come. There is nothing more valuable than, from day one, unit testing, organizing files in a clear way, preventing clutter, and starting writing basic documentation of how to work with your software. These simple cues will remind you and others of what the expectations are for your project. As popular as it is to say "just solve the problem in front of you", no one actually does that. No one sits down to work on something with one problem - the sit down with likely hundreds, all vying to be solved. Average engineers will look at one, solve it, test it, put it in a text file, push it to prod, and say "look, done!" Good engineers will look at the whole class of problems and recognize commonalities that inform basic architectural and infrastructural decisions.
- avgDev 7y agoWhen I started I named one of my first projects at work somethingsomethingTest, it is this way 3 years later. Honestly, I tried changing it but it caused a cluster fuck, so every time I have to fix a bug it gently reminds me about being a fresh dev, writing test programs that just somehow wiggle their way into production. Management says, job well done if it works it works. :\
- ChrisMarshallNY 7y agoThis is the reason I am less-than-thrilled with the way most companies get to MVP. Make MVP good quality ("V" should have "Quality" as a principal metric). It may be bare bones, but don't skimp on the quality. Or you'll be very, very sorry.
- mcv 7y agoFor this reason: write even your prototypes in a maintainable way. Don't go overboard, quick hacks are allowed where they save time (you might want to mark them with a // TODO), but even prototype code should be understandable. Also: don't be afraid for dramatic refactoring. If you know it's necessary, do it. It will improve your code base immensely. And the earlier you do it, the easier it is. And even when you do throw away your code, you're not going to throw away all of it. There are always bits that look good and work well, so you copy them into the new version.
- m463 7y agoYou can get around this (a bit) by squirreling away and enhancing a "template" program in the languages of your choice. For example, I have a "template" python script that does meaningful things like importing stuff, parses arguments with argparse, does logging with debug/verbose flags, and some other common things. So starting a "throwaway" project, it's initially over-engineered but that quickly averages out.