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

51–60 of 142 posts

Re: Red Flags Signaling That a Rebuild Will Fail

#51

Post by wellpast »

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…

As incrementally as possible. Eg, does your entire data model need to move at once? (Probably not.)

Re: Red Flags Signaling That a Rebuild Will Fail

#52

Post by ebikelaw »

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.

Yep, seen that. I worked on a system where the company did not really want a reimplementation but they destaffed a project in one site and reconstituted it with all new people at another site. The new people decided to rewrite from scratch. A year and a half later I start getting questions by email from the new people, questions indicating that not only do they not understand the implementation of the legacy system, they also do not clearly understand the business requirements that resulted in that implementation. Meanwhile, the maintenance of the old system had been neglected to such an extent it had fallen behind critical company-wide mandates. This was more of a lesson about why you shouldn’t destaff a project over some petty geographical squabbles, but also quite clearly about why you should always incrementally reimplement software rather that rewriting it.

Re: Red Flags Signaling That a Rebuild Will Fail

#53

Post by zbentley »

pbreit wrote: post #22
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.

This strikes me as dangerous. Didn't the experts build the first system? Don't you want to deliver a fresher system? Won't the experts be attached to the old way of doing things?

> Didn't the experts build the first system? Don't you want to deliver a fresher system? Won't the experts be attached to the old way of doing things?

With all respect, that means you should not be in a position to rewrite legacy code, or to commit others to such a rewrite.

If all the experts you have worked with have been, in your eyes, overly attached to the old way of doing things, you have one of two issues:

- You have not had enough experience in the field, and have not worked with experts that actually have perspective about when/how to rewrite, abandon, or rework their code.

- You have dogmatically condemned people who think that the latest-and-greatest tech may not be a good solution to the problems at hand to the "old fogey" bin.

Either issue means you're not ready to make decisions at this level. Learn more. Research more. Watch more. Listen more.

Weirdly, gaining this perspective has less to do (in my experience) with years on the job, and more with diversity of team/business environments worked in.

Re: Red Flags Signaling That a Rebuild Will Fail

#54

Post by zbentley »

tomelders wrote: post #38
omeid2 wrote: post #36

Earlier quoted context omitted.

> I’ve always been a big believer in rebuilding your product from the ground up. I think it’s something you should always have going on in the background. Just a couple of devs whose job it is to try and rebuild your thing from scratch. Hahaha. Just a couple of devs?

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.

Re: Red Flags Signaling That a Rebuild Will Fail

#55

Post by zbentley »

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.

That's utopian. The reason cautionary rules like those in TFA exist is because "just undo/revoke all the bad shit that led to your current situation", while certainly appealing in concept, is often impossible in practice. Instead, litmus tests like these, which can be practiced at the dev team level, prove useful. Who knows, if enough dev teams at a company arrive at the same conclusions using reasoning like this, perhaps they really can put enough pressure on management to induce firings of prominent debt-incurring people. Even (and more likely) if not, that understanding at the engineering level will help mitigate future damage/mistakes.

Re: Red Flags Signaling That a Rebuild Will Fail

#56

Post by majormajor »

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 estimate the size of a rewrite...

(This isn't solely for full-parity rewrites: if you're dropping features, what does that look like dropping from the old system?)

Re: Red Flags Signaling That a Rebuild Will Fail

#57

Post by antsar »

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.

Also known as Chesterton's Fence.

https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_...

Re: Red Flags Signaling That a Rebuild Will Fail

#58

Post by manicdee »

lordofmoria wrote: post #32
nostrademons wrote: post #21

#5 has a converse - oftentimes, the only way to get a rebuild to succeed is to drop features, and it's a major red flag if management insists on 100% feature parity. The way to distinguish this from the #5 situation in the article is to ask if you're dropping features because they're hard or because nobody uses them . The former is a red flag; the latter is a green flag. Before you embark on a rebuild, you should hav…

> Before you embark on a rebuild, you should have solid data (ideally backed up by logs) about which features your users are using, which ones they care about, which ones are "nice to haves", which ones were very necessary to get to the stage you're at now but have lost their importance in the current business environment, and which ones were outright mistakes. This is so important. I've been on many a project where,…

Also important to realise that a feature that is rarely used (view history, remove user) might be more important than one used more often (dashboard widget that nobody pays attention to)

Re: Red Flags Signaling That a Rebuild Will Fail

#59

Post by kornish »

lordofmoria wrote: post #32
nostrademons wrote: post #21

#5 has a converse - oftentimes, the only way to get a rebuild to succeed is to drop features, and it's a major red flag if management insists on 100% feature parity. The way to distinguish this from the #5 situation in the article is to ask if you're dropping features because they're hard or because nobody uses them . The former is a red flag; the latter is a green flag. Before you embark on a rebuild, you should hav…

> Before you embark on a rebuild, you should have solid data (ideally backed up by logs) about which features your users are using, which ones they care about, which ones are "nice to haves", which ones were very necessary to get to the stage you're at now but have lost their importance in the current business environment, and which ones were outright mistakes. This is so important. I've been on many a project where,…

> The worst part? Even if you add it immediately, you'll have to wait 2-4 weeks to get a sufficient amount of data.

I think this was the problem a product like Heap [1] was designed to solve: just track all user actions, forever, and then assign pipelines after the fact based on what you want to check up on.

Don't work at Heap or anything, just love the team and product.

[1]: https://heapanalytics.com/

Re: Red Flags Signaling That a Rebuild Will Fail

#60

Post by realusername »

wellpast wrote: post #37

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

Sometimes you just have to. In one previous company, the "system" we were trying to trash was an unmaintainable VBA CRM homegrown mess which was creating lots of internal issues in the company due to the nature of spreadsheets. It took almost a year to replace but it was 100% worth it.
Post reply on HN