Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Red Flags Signaling That a Rebuild Will Fail

pkc.io

Post reply on HN
Print view View original

61–70 of 142 posts

Re: Red Flags Signaling That a Rebuild Will Fail

#61

Post by lyqwyd »

This article really captures the risks of a rebuild. I’ve been through a number of them, all but 1 abject failures. The one success was driven by the executive understanding that the company would fail without a rebounds, and it was still 6 months late, resulted in one of the cofounders being fired, an extremely painful rollout, and the company still failed, due to other problems.

My firm belief is that when you need a rebuild, you are already well into a fail state as a company. Not to stay there can be no recovery, but it is an indication of some deep problems for the company, beyond anything the engineering department alone can resolve... and if the rebuild is not coming from the executive leadership, it is an even bigger issue as it will more likely lead to bigger problems than it will solve.

Re: Red Flags Signaling That a Rebuild Will Fail

#62

Post by bokonon12 »

maxxxxx wrote: post #28
Chyzwar wrote: post #4

The rewrite is usually when it is too late for the project. Need for re-write mean that project maintenance was ignored and technical debt reached critical levels. I would start by firing people that led to this situation.

" I would start by firing people that led to this situation." You are one of those blessed people who can architect a system and the architecture holds up for decades. From my experience most systems will end up in a big mess over time if features get added. There is almost no way around it.

Yup. So much of the time the system starts out at one thing and morphs to another. That can easily lead to core problems with your architecture

Re: Red Flags Signaling That a Rebuild Will Fail

#63

Post by gwbas1c »

majormajor wrote: post #56
maxxxxx wrote: post #5

"Red Flag #4: You aren’t working with people who were experts in the old system.” I think this is most important. A lot of people want to rewrite because they don't understand the current system and don't want to bother learning. Before you rewrite you really should understand the current state deeply.

The way I've phrased something similar before is "don't do a full rewrite if you couldn't write up a plan for refactoring in place to fix the problems with the old system." If you can build that plan, and make the case that it will be easier to do the full rewrite, go for it. But if you couldn't put together the fix-in-place plan, you might not understand everything the old system does well enough to actually estimat…

I was involved in a rewrite where it would have been much easier to refactor the old system.

A year into the process one of the c-level leaders pulled me into a room and asked why I couldn't fix the legacy code, and I basically told him that he should have pushed back on it. I couldn't fix the legacy code because that would be months of refactoring that should have been done instead of the rewrite.

Context: the legacy code had some design flaws that required major refactoring, but the legacy code "worked" except for very large deployments. The only problem was that the legacy system wasn't modular, so it didn't have unit tests and wasn't cross platform. All of those problems are easier to tackle via refactoring instead of a full rewrite.

Re: Red Flags Signaling That a Rebuild Will Fail

#64

Post by omeid2 »

zbentley wrote: post #54
tomelders wrote: post #38

Earlier quoted context omitted.

Their job isn’t to build the whole thing. Their job is to research and explore how new ideas and tools might be useful to your business. It’s just R&D. It’s not an exotic idea.

Some of the best colleagues I've had, and teams I have worked with, have made this position (formally or informally) a rotating one. It's a great way to learn. Corollary: this position needs to be at least two devs. Otherwise, you're rotating in people for redundant discoveries rather than mentorship.

The problem with this idea, to put in terms of the main article, is that it raises Red Flag #1.

It may be a great way to learn, but I think that is better achieved with something like Google's famous 20% program not some vague rewrite attempt with no direction.

Re: Red Flags Signaling That a Rebuild Will Fail

#66

Post by watwut »

hinkley wrote: post #46
maxxxxx wrote: post #26

Earlier quoted context omitted.

I have seen that before. You kill yourself refactoring a feature only to find out it's never or barely used. Deleted code and features are the best.

You hamstring the product to make a feature work one way then find out that what they really wanted would have been easier to implement but they never asked because they thought that would be harder.

That is why social skills and good analysts are important.

Re: Red Flags Signaling That a Rebuild Will Fail

#67

Post by watwut »

Chyzwar wrote: post #24
JumpCrisscross wrote: post #19

Earlier quoted context omitted.

> I would start by firing people that led to this situation Thereby fomenting Red Flag #4, not "working with people who were experts in the old system.”

I am not saying to fire everyone. I am just saying that someone needs to be responsible. If you keep the same people in power they will repeat the same mistake. You need to keep domain knowledge but clueless management is just a burden.

New people will repeat most of original people mistakes too - many bad designs look good before you tried them.

But also, wtf is it with people that the first instinct in any kind of situation is to fire everyone.

Re: Red Flags Signaling That a Rebuild Will Fail

#68

Post by draw_down »

teddyh wrote: post #49
lgleason wrote: post #2

I recently left a project that demonstrated most of these traits. Usually these things are the top of the ice-burg.

Know your burgs and bergs. A “burg” (or burgh) is a fortification, or more usually refers to a city built around (or inside) that fortification. A “berg” is a mountain, or a large hill. Therefore, an iceberg is an “ice mountain”, and a “burgermeister” is a “city master”; i.e. a mayor.

:(

Re: Red Flags Signaling That a Rebuild Will Fail

#69

Post by grey-area »

CydeWeys wrote: post #48
wellpast wrote: post #37

Red Flag #1 should be that you’re doing a rebuild.

I'm potentially looking at a situation like this right now at work. We're on a NoSQL DB and it's just not working too well for us anymore, so we would like to transition to something that provides more relational semantics (PostGres, Spanner, something like that). Migrating the backend between one kind of DB and another is non-trivial, especially because the whole ORM needs to be ripped out as well. It's not a full r…

I'd definitely vote for PostgreSQL, it can handle large loads effortlessly, it's reliable, and yet they keep adding great features.

It could also function pretty much like a nosql db initially, to ease your transition, then you could migrate gradually to using it as a relational db. You need strong checks on data integrity before you start - you could consider double writing (to old orm using nosql + new orm using psql), and comparing data stored to be sure you don't miss anything at first, before you switch?

Re: Red Flags Signaling That a Rebuild Will Fail

#70

Post by DiabloD3 »

_asummers wrote: post #9
maxxxxx wrote: post #5

"Red Flag #4: You aren’t working with people who were experts in the old system.” I think this is most important. A lot of people want to rewrite because they don't understand the current system and don't want to bother learning. Before you rewrite you really should understand the current state deeply.

Even having the entirety of the original dev team there, time takes its toll on recollection of reasoning behind some of the strange decisions made in something that would warrant a rewrite. Much preferable to not having them, of course.

Something I do is if the code looks weird or is rather small for how much work went into it, I leave a comment that says why this was done... just so I can remind myself in 6 months when I go "who the fuck wrote this garbage... oh, me."
Post reply on HN