3 ms·

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

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.

pylua 2y ago
I feel like this is typically not the right choice.
bazoom42 2y ago
How did you measure the 3x factor?
- free_bip 2y ago
  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.
  - bazoom42 2y ago
    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.
  - butlike 2y ago
    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.
jmull 2y ago
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.
- mvdtnz 2y ago
  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.
  - bazoom42 2y ago
    If the team was top-notch and disciplined they would continously refactor and improve the code base.
    - lanstin 2y ago
      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.
klyrs 2y ago
> ....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?
speed_spread 2y ago
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.
- free_bip 2y ago
  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.
seabrookmx 2y ago
"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.

pylua 2y ago

I feel like this is typically not the right choice.

bazoom42 2y ago

How did you measure the 3x factor?

free_bip 2y ago
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.
- bazoom42 2y ago
  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.
- butlike 2y ago
  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.

jmull 2y ago

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.

mvdtnz 2y ago
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.
- bazoom42 2y ago
  If the team was top-notch and disciplined they would continously refactor and improve the code base.
  - lanstin 2y ago
    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.

klyrs 2y ago

> ....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?

speed_spread 2y ago

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.

free_bip 2y ago
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.

seabrookmx 2y ago

"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.