> Start from the opposite assumption: the people before you were not fools.
I always do that. I used to assume they knew better than I. I've been wrong a lot about that.
Most rewrites serve the engineer, not the business
51–60 of 71 posts
Re: Most rewrites serve the engineer, not the business
#52serving the engineer _does_ serve the business, ultimately.
Came here to say this - you can construct a point to win this argument that needless rewrites are only for the engineer's satisfaction and serve no business need, but the article clearly argues against itself IMO. Rewriting to make it more ergonomic for developers to work with is ultimately going to be better for the business
Re: Most rewrites serve the engineer, not the business
#53serving the engineer _does_ serve the business, ultimately.
This is my thinking as well. Although the 'never do full rewrites' rule is canon for most of the software world, I have led rewrites of two large front-end applications to great success - replacing an app that 'worked' but took an order of magnitude more time to iterate on than the codebase that replaced it. That said, it's probably more dependent on what a 'full' rewrite actually is - I would be much more reluctant…
I do feel like rewriting a front end that depends on the same backend is much less perilous than the alternative - in the end its basically just a presentation layer change
Re: Most rewrites serve the engineer, not the business
#54Earlier quoted context omitted.
> I've also been in situations where the person claiming it simply refused to become competent in the language, framework, or persistence technology that the system was built on. To all managers out there, this is a strong negative signal in the employees mindset, and a strong positive signal that there was a mistake in hiring. Eliminate this type of behavior immediately and if the person wont change then fire them (…
> this is a strong negative signal in the employees mindset, and a strong positive signal that there was a mistake in hiring Agree that it's almost certainly a mistake in hiring but strongly disagree that it's a negative signal in the employees mindset Being specialized in one area is actually a good thing for many people and many roles. It's actually kind of bullshit that software companies expect everyone to be a g…
Strong (but polite) disagree. Domain knowledge is now commoditised more than ever, the only valuable employees are intellectually flexible ones with a can-do mindset, ideally more senior ones who will also take responsibility for the final output. Thats all we hire right now.
With the exception of companies so huge that economies of scale make hyperspecialisation the sensible choice, however I ignored these because this is a startup and small-medium business community
Re: Most rewrites serve the engineer, not the business
#55[flagged]
Re: Most rewrites serve the engineer, not the business
#56> Most rewrites answer to the engineer - what they want to learn, what offends their taste, what looks good in an interview - and not to the company paying the salary.
One big caveat to this is that a large (and increasing) part of the value of the senior engineering hire is their taste. ‘Taste’ as honed by the software industry approximates business needs that the business doesn't even know it has. Sometimes engineers struggle to articulate ‘why’ a particular change is beneficial because they're just pattern-matching: they've seen the existing pattern break in a dozen different ways in a dozen different codebases, so now when they see the same thing again it ‘offends their taste’ — it looks indefinably wrong even though it doesn't seem to be causing any direct harm right now.
(Of course, sometimes it turns out just to be that they don't understand what's going on, especially but not exclusively for more junior engineers. Pobody's nerfect.)
Re: Most rewrites serve the engineer, not the business
#57With a title like that you have to back it up. It's a shallow article. > why it was worth doing, because it wasn't, at least not to the business. The application did the same job for the same users at the same speed as before. Application have many other properties then "doing their job". Running cost, maintainability, ... it's endless. Any of them going seriously wrong can tank the company owning it. But I agree, re…
> It's a shallow article.
Yeah, because it was generated by AI.
As soon as I got to "That is the pattern worth naming. Most rewrites answer to the engineer - ", I stopped reading.
Re: Most rewrites serve the engineer, not the business
#58The article is AI slop, obviously, like practically everything on the internet these days it seems. Awful writing, circling endlessly around the same point. The entire article could have been a single sentence. Which of course, is how it began. As a prompt. The article is also wrong. Or, at least, indicative of a broken relationship between management and engineering. If you have an engineer who can decide to rewrite…
I am sorry to hear the article sounds like AI slop to you.
Re: Most rewrites serve the engineer, not the business
#59This is not right. The engineer uses the re-write to serve business better.
Except the Rust rewrites that have been ordered directly by "business"
Re: Most rewrites serve the engineer, not the business
#60I've worked in projects where change was expected, so a policy of strict integration testing was introduced - test that treat the system as a black box and aren't aware of its internal structure (to a point, there is always some compromise). Every bug had to have a matching integration test. This made rewrites cheap, boring even (there is always _some_ danger of course, but the approach significantly simplified the decision to rewrite some part of the system or another).