Hacker News Reader

Comment by free_bip | Hacker News Reader

The codebase I work on is a Big Ball of Mud. It takes roughly 3x the effort to make any functional changes due to this (and thus we have 3x the devs we actually need). When it was framed like that, the business was eager to start a total rewrite project.

View on HN

"Grand rewrite in the sky" is also a common pitfall. There is a lot of tradeoffs. If proper practices aren't in place ahead of time and/or an unrealistic deadline is pushed, you often end up writing a new system that's just as bad as the old one.

Hmmm... considering that your current codebase became a Big Ball of Mud, is there any reason to think the same won't happen to your next codebase?

Not that I'm saying don't rewrite. It will certainly be more fun and likely good for the resume.

There's no reason to believe that people, teams and organisations can't learn lessons. This is why we foster a growth mindset. It takes effort and discipline but it can be done.

If the team was top-notch and disciplined they would continously refactor and improve the code base.

There are teams that want to improve the code but get tired of fighting management, but if you go in as senior IC and encourage them, showing it as a heroic fight for the good, the true and the beautiful, they will respond with relief and eagerness and many idea to improve things, and a willingness to find ways to marry the management requests with the proper long term quality way.

Have you considered the possibility that 3x as many programmers were always dedicated to the project made it grow into the big ball of mud that it is?

Team size correlates with system complexity regardless of the problem domain.

The story in this case is a little more complicated than that, we're a team of 3 that inherited a decade old codebase built by lowest bid contractors.

> ....and thus we have 3x the devs we actually need). When it was framed like that, the business was eager to start a total rewrite project.

What fraction of developers is on Team Rewrite?

I feel like this is typically not the right choice.

How did you measure the 3x factor?

Mostly by looking at how long simple changes (e.g. changing a fee + fee message at checkout) that should only take a day or less, actually take.

But how do you know how long a change “should” take? And how do you know if the rewritten code would be any easier to change?

I tend to be sceptical of “rewrite everyting” projects since they are often based on wishful thinking.

Alice has arthritis, so it takes her 3min longer to write any functional changes. She, however, has domain experience across the entire application. Bob can write code 2min quicker than Alice, but is relegated to a specific section of the codebase.

Reply on news.ycombinator.com