5 ms·
I used to work in a shop where "bad code is okay, we're a startup" and "our entire system depends on spaghetti written by an intern that quit after six months f
by rolenthedeep 4y ago
I used to work in a shop where "bad code is okay, we're a startup" and "our entire system depends on spaghetti written by an intern that quit after six months five years ago" were the norm.
By the time I came along, the consensus among senior devs was that the entire project was a loss and we'd have to start from the ground up on the next project.
They're still shipping the same showstopper bugs nearly ten years later.
If you want your project to last more than a couple of years, or if you want to use it as a base to build other projects on, you should care about code quality. Don't try to implement an entire game engine on the back of some shit an intern threw down in a weekend and now you're too scared to touch it
- ido 4y agoIf you want your project to last more than a couple of years And yet by your own reporting the project you're speaking of is still around 10 years later.
- graypegg 4y agoI’d imagine rolenthedeep is trying to communicate that they survived in spite of their confusing codebase, not thanks to it. Maybe they could be shipping even more if they didn’t have to deal with the opportunity cost of maintaining it.
- rolenthedeep 4y agoYeah, pretty much. Last I checked, they've made no major improvements to the game since I left. They've just been pumping out DLC for the last several years. It took them a good five years to announce the sequel. Presumably because they had to scrap the entire bespoke game engine and redo everything from scratch. When I was there it was accepted as fact that the only path forward for a sequel was to start from zero and build a whole new engine because it was so bad. I could go on for days about it, but I think the best example was the Character class. At one point it was over 27000 lines of code split across 5 separate files. Characters took up an astonishing fraction of the total cpu time, especially considering that you'd have a dozen or two characters in a world with thousands or tens of thousands of other entities.
- tinglymintyfrsh 4y agoYes, exactly. Throwing tech debt to the wind is going big bags shopping on a credit card. Someone will eventually have to pay the bill. I saw a startup that was so tech debt-heavy that they couldn't move. They were stuck daily patching nasty code. Engineers who don't care about code quality are like coworkers with messy desks that spill onto yours.
- gumby 4y ago> They're still shipping the same showstopper bugs nearly ten years later. They can't literally be showstoppers if they are still in business. Still, nobody accepts that level of crap any more when building, say, a bridge. They used to, back in the Victorian age, until they figured out what worked (the great victorian era bridges still in use are the ones that didn't fall down -- a survivorship bias). I think the fact that we only demand reliability from aircraft, trains, (some) med devices, spacecraft and banking shows how unimportant most software is. Most software will never need the level of reliability of the domains in my previous sentence, but sheesh, the needle needs to move in that direction.
- rolenthedeep 4y agoTo this day I see people play the game on YouTube and the player model will glitch out like it always has. Limbs go weird directions, or the tool you're holding will slowly expand to fill the entire screen. Vehicles regularly sink into the ground, or explode, or have a physics glitch that launches them into space. Totally unacceptable issues that have been around basically the entire life of the game. Their success is complicated, but in general the loyal players became conditioned to accept these bugs, while new players would hang out for a few weeks until their vehicle explodes and they lose days of progress for the nth time. Player turnover was huge, but they have a fairly large core of players who just deal with it.