Hacker News Reader

Comment by 16s | Hacker News Reader

Over the years, I've noticed that many programmers who want to re-write, just aren't comfortable modifying other people's code, or it wasn't written in their favorite language. So, they are critical of the code and urge for a re-write. These people generally make bad programmers. If you have people on your staff that want to re-write this program, or switch to this framework (because it's what they are used to), then watch out. That's a bad sign.

Competent programmers can maintain other people's code, those who cannot want to re-write everything. Train wreck in progress. Run from these people, or fire them if you're in a position to do so.

View on HN

I've come to a situation in the past, where there would be endless lines upon lines of PHP code intermixed with random static functions and HTML markup.

I'm talking 40, 2000 LoC files that all called the database whenever they felt like it, all echoed out data and modifed each other in wierd ways.

I spent about two weeks trying to untangle the mess and threw the towerl in at day 15. We just rewrote it using a PHP framework that not only let us query the database using a sane ORM, but also gave the project STRUCTURE and added mantainability value.

Sometimes a rewrite is the best cure. ;)

What an excellent why of shutting down critique of your choices and protect your self from having to learn new ideas.

Probably why most big companies have such a horrible time getting good people to work for them: who really wants to work in a place like that if you have options somewhere else?

I think that's more a sign of inexperience than a character flaw. The potential benefits of a Big Rewrite are obvious. The potential pitfalls are not.

I totally agree that much of the time, it's just people wanting to work on something they find familiar, being incapable of maintaining code other than their own.

But then again, sometimes, the problem is just that the legacy code is shit. In a project last year, for instance, I had to rewrite every class I touched; the whole thing was so fragile that it was impossible to change anything without the rest breaking. So, I did this “incrementally” rather than all at once, and factored this into the cost of the features I was implementing for the client.

Absolutely agree, and I personally use this as a potential red flag for new people we hire.

Legacy systems have gone through so many fixes and shifts that it's almost impossible to recreate them without deep understanding of the business demands it meets.

The business part, I would say, is critical to being able to maintain (or re-write) a project.

On the other hand, sometimes you've wound up with 100k lines of bash and things are breaking regularly in odd ways.

Competent programmers known when its time to maintain code or to re-write it and theres no easy answer. But i definitely agree with your point that insisting on a switch of framework just because its more familiar with out any real compelling reasons is a very bad sign.

Reply on news.ycombinator.com