Comment by PragmaticPulp | Hacker News Reader

Comment by PragmaticPulp | Hacker News Reader

> Take pleasure in writing more code

Very common trap. Most of us grew up with a natural enjoyment of programming, so it’s easy to lose sight of the fact that our job as engineers isn’t to produce more and more code. Our job is to deliver results, not lines of code.

This often manifests as developers or entire teams that can’t stop rewriting, refactoring, and rearchitecting code that is already good enough. They might want to rewrite their otherwise working service in Rust because Node.js is no longer popular, or rework the stable React app to use hooks, or fork and maintain a popular open-source project because they think they can improve it. They prefer to write generalized solutions or frameworks from the start instead of writing a specific one-off solution to get the job done. Or maybe they just have perfectionist tendencies and struggle to submit that PR until they make just one more improvement.

This isn’t unique to developers, of course. My last company had a major problem with UI/UX designers who could never finalize their designs. We lost countless months to endless iterations and tweaks. Part of the problem lies with management, of course, if they’re not enforcing actual project deadlines and end times.

As a technical manager, the most important thing I end up doing is snipping off complete re-writes or re-architectures in the bud.

I've also found that management is actually the greatest source of UI/UX reworks; once they've seen the pixel perfect mockups, management thinks that "the job is done" and they want to iterate ...

At my first real software job one of the engineer always used very rough outlines that are obviously unfinished. He always said that having pixel-perfect mockups is a sure way to have your meeting sidetracked by someone asking if "the button should be bigger" or "the orange should be more red-ish" and then not understand why it would take 5 engineers 6 weeks to "just make the button bigger".

I work as a backend engineer now because I just couldn't take those meetings anymore.

I gotta ask, though, how do you handle it when a product ISN'T working?

I've dealt with a product that was so poorly architected that, to this day, it is constantly causing production outages, bad data, etc. And the root of the problem is that it wasn't built to do the right thing. At it's very core, it processes and stores data incorrectly. (Leading to "there are good days and bad days and ops will handle it").

Yet, I met the "We CAN'T REWRITE" pushback, which, ok, but here's the solution that doesn't involve a rewrite, it'll be 10x more expensive because the slow evolution will be a whole lot harder and more risky than a fresh solution with an adapter to the old interface.

I certainly don't take rewriting lightly, and don't generally suggest it, but I have to ask. How can you sell it when the alternative is what my company deals with today?

I find myself saying "beware the protoduction trap" a lot because of exactly this. Get-it-out-there prototype code pushed into production roles can work great. It also can not work great and can have discontinuous failure modes. You're placing a bet that it won't fail until you somehow outpace the need to care about it, and...well, I don't love that bet when I'm the one advocating for it, if I'm advocating against it it's probably because I can see the crack and hear the rumble on the horizon.

> I gotta ask, though, how do you handle it when a product ISN'T working?

Yeah, sometimes you have to rewrite/rearchitect but more often you don't. But sometimes the job is to actually get some one to let go of the control of strange baby they implemented so you can rewrite.

Years ago I worked on DNA analysis software where the entire thing was abstracted; codons could be any number of bases instead of just 3, there could be any number of bases instead of 4, there was a whole system for managing amino acid names that assumed there could be an infinite number of amino acids. Loading a sequence involved millions of checks to see if there were any matches against 4 base codons or 5 base codons ...

That definitely was a rewrite; but the developer fought it every step of the way.

I rewrote a product which was not working and was never completed 100%. New version is better but I had to hack things here and there due to constraints of the existing systems. Additionally, the number one problem is lack of documentation, not in the app but in the business sense.

In order to write a good application the process it is going to support needs to be well documented. This wasn't the case and I had to go back in circles a few times but you live and learn.

I strongly believe that regular refactoring (rarely rewrites) is very beneficial, efficient and has strong implications on sustainability of the code and the competency of programmers.

But too much refactoring doesn't really make sense because you cannot see where chaos wants to go, so you'll constantly find local maxima.

I believe we often have to use heuristics and "best practices" as guidelines for refactoring, structure and design. However one of the best methods I find is to just observe for long enough where problems start to arise. Like pumping a liquid through a thing so you see where it leaks if that makes sense.

> This often manifests as developers or entire teams that can’t stop rewriting, refactoring, and rearchitecting code that is already good enough.

We got tons of code that I'd love to rewrite or refactor. But it works. Has done for 15 years and will continue to. Instead I can fix proper bugs and add new features.

Sure if the old mess is standing in the way of delivering something important I will do something about it. But not until then, we just tweak it when needed and that's it.

Unfortunately, it's common to get "stakeholders" involved who want to "approve the design" before a feature's green-lit, as in, exactly what's going to be built, or at least very close. Because they're "important" so they must know software UI design better than the UX experts, designers, and developers they've hired. "No no no, this delete icon must be a red X, even though that could easily be mistaken for 'close' in this context, and I will fight you for weeks to make sure it happens". They don't like wireframes or deliberately-rough mockups.

Or you get branding lunatics involved who aren't able to produce and provide visual-design guidelines that they trust well enough not to need to stick their nose into every project to make sure the button corner radius is "on-brand" and can't ever let a design pass without some kind of tweak, because that means they're doing work, I guess.

So what is the correct way to think about refactoring?

Should code that is delivering results, but is hard for others to understand & work on be refactored?

Reply on news.ycombinator.com