51–60 of 104 posts
I’ve heard from a couple people that Stripe is in limbo because they started a rewrite of their monolithic ruby app, but it stalled when the champion of the rewrite left. So now they are supporting both the new app and the legacy app in prod. Sounds miserable.
I’ve heard from a couple people that Stripe is in limbo because they started a rewrite of their monolithic ruby app, but it stalled when the champion of the rewrite left. So now they are supporting both the new app and the legacy app in prod. Sounds miserable.
So, ah, Square (aka Block, Inc.) are currently doing precisely the same thing...
The main reason why developers do rewrites is because it is easier to read your own code than it is to read somebody else's code. Doing a rewrite means you only have to work with code that was written by your current coworkers or by yourself. This is also the core motivation behind all of the schemes to force a single coding style on all developers at the cost of performance and usually with an extremely complicated…
This is why I recommend using a framework in commercial projects, and following it's idioms as closely as makes sense for your project. It means there is a shared idiomatic approach across your team and all the documentation for it is just the framework documentation. It is also easier to hire devs, if you can vet their ability to write idiomatic code in a specific framework then you can better assume they will mesh…
Code may not rust, but it may be broken out of the gate. Joel and others may not have seen really bad code, but it exists. All of us have written code in our careers that we're not proud of. And there's code written by people who are proud of everything they've written or code written by people who just don't care. These two are usually good candidates for rewrites.
Weird to suggest that a veteran of the industry might not have seen "really bad code". I cannot imagine that's true.
The first kind was written by people who know about software, has some attempt at following some conventions, variable names, etc. etc. It's not "clean and shiny", but you can see someone tried. Like if a bunch of first year apprentices built a house. They tried their best, and often did a half reasonable job - at least for a first timer. Plenty of companies are using this kind of software to make many of millions of dollars. I would say this is extremely common in the real world.
And then there's codebases that consist of a single source file that has hundreds of thousands of LOC and that file is called indexNEW.php, indexNEWNEW.php index2022-1.php (and so on). Nobody who works on it has ever studied any kind of software course at any kind of school, and literally nobody has any real understanding of what/why/how, because it gets passed along like a hot potato everytime someone quits due to the insanity. Nobody who works on it even knows what source control is, has no idea why you shouldn't copy and paste code, and has never heard of TDD or automated testing or bullding or literally any software discipline. This isn't like first year apprentices building a house, this is like Homer building the Canyonero - an utter disgrace that just barely functions at all. [1]
I wouldn't be surprized if Joel is talking about type one, and doesn't even really consider type two to be "software" or "a system". It's just a stinking pile of garbage.
(I worked at a very large Telco. The vast majority of code plugging the systems together was type two - it was a nightmare of spaghetti so bad that when a power outage and failed backup generator took down everything (including 911), it took more than two weeks just figure out how to start everything back up again.)
> they think the old code is a mess. . . . they are probably wrong. The reason that they think the old code is a mess is ... It’s harder to read code than to write it. I suppose I think the reason people think code is a mess is because it _is_ a mess. Just yesterday I saw a team decide to override $PATH in 50 separate files because they didn't understand how to package a python library. (I'm not innocent in crazy stu…
There's mess and there's "override $PATH in 50 files" mess. "The old code is a mess" is a really easy conclusion to come to when trying to grok a complicated codebase, and it's not always correct.
The main reason why developers do rewrites is because it is easier to read your own code than it is to read somebody else's code. Doing a rewrite means you only have to work with code that was written by your current coworkers or by yourself. This is also the core motivation behind all of the schemes to force a single coding style on all developers at the cost of performance and usually with an extremely complicated…
LOL: so did you read TFA, or just come up with this yourself?
Perhaps it's rose tinted glasses, but I distinctly remember that Netscape 4 had to repaint the screen on window resize. Like the code was that bad. The product was rushed to market and features were bolted on because there was a browser race/war where quality suffered greatly.
This POV would have been impossible to see if you use Netscape 6 because it was so unusable no one used Netscape 6 except for nerd points and to try out "does my browser support this CSS" tests.
Earlier quoted context omitted.
This is why I recommend using a framework in commercial projects, and following it's idioms as closely as makes sense for your project. It means there is a shared idiomatic approach across your team and all the documentation for it is just the framework documentation. It is also easier to hire devs, if you can vet their ability to write idiomatic code in a specific framework then you can better assume they will mesh…
Using a framework doesn't help at all because a framework is still somebody else's code. There is nothing special about somebody else's framework that makes it any easier to deal with that somebody else's non-framework.
I'd say there's quite a bit "special" about all of these attributes, at least enough to warrant careful consideration.
Earlier quoted context omitted.
Using a framework doesn't help at all because a framework is still somebody else's code. There is nothing special about somebody else's framework that makes it any easier to deal with that somebody else's non-framework.
The idea is that frameworks are generally designed to be used by other people, leading to greater focus on documentation, developer ergonomics, community support and generally more versatile code (scales with number of contributers/users; many will report obscure bugs and edge cases you may never consider testing but would impact your end users). Another huge benefit is you don't have to rewrite an entire system from…
If you qualify this advice to the point where it actually becomes useful it turns into, "Use code written by other people that doesn't suck." And that, of course, is indeed a good idea, but it's a lot easier said than done.