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

71–80 of 142 posts

Re: Red Flags Signaling That a Rebuild Will Fail

#71

Post by civilitty »

kornish wrote: post #59
lordofmoria wrote: post #32

Earlier quoted context omitted.

> 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/

Any solutions (technical or procedural) that are capable of maintaining user privacy?

I don't think "just track all user actions, forever" is going to be a legally defensible solution for much longer, even in the US.

Re: Red Flags Signaling That a Rebuild Will Fail

#72

Post by brazzledazzle »

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…

There have been a couple times where I’ve tried to use a feature that should have been awesome but was terrible then it got pulled in a newer version of the product. It was incredibly frustrating to wait for a fix that never came. Data on what’s used is good but you need to get feedback about what sucks to go along with it.

Re: Red Flags Signaling That a Rebuild Will Fail

#73

Post by mehrdadn »

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…

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

Hmm... there have been a number of times when I've banged my head against the wall trying to figure out how to make my own code do something, until I finally bit the bullet and decided to rewrite the entire chunk from scratch and suddenly it took a fraction of the time I had spent trying to fix it to get it written and working. Not sure how to reconcile this with the advice you gave.

Re: Red Flags Signaling That a Rebuild Will Fail

#74

Post by kornish »

civilitty wrote: post #71
kornish wrote: post #59

Earlier quoted context omitted.

> 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/

Any solutions (technical or procedural) that are capable of maintaining user privacy? I don't think "just track all user actions, forever" is going to be a legally defensible solution for much longer, even in the US.

Tracking events without user IDs would still allow for aggregate feature usage tracking.

Out of interest, what makes you think that an application won't legally be able to record the ways in which a user interacts with that application?

Obviously I'm not speaking for Heap; just curious.

Re: Red Flags Signaling That a Rebuild Will Fail

#75

Post by CalRobert »

kornish wrote: post #74
civilitty wrote: post #71

Earlier quoted context omitted.

Any solutions (technical or procedural) that are capable of maintaining user privacy? I don't think "just track all user actions, forever" is going to be a legally defensible solution for much longer, even in the US.

Tracking events without user IDs would still allow for aggregate feature usage tracking. Out of interest, what makes you think that an application won't legally be able to record the ways in which a user interacts with that application? Obviously I'm not speaking for Heap; just curious.

We need case law to settle the matter but in general, the GDPR indicates that if you don't need to collect the data in order to perform the requested activity, you need explicit consent for collecting it, and will be held to a high standard in court if this every comes in to question.

Re: Red Flags Signaling That a Rebuild Will Fail

#76

Post by perlgeek »

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…

> And you should be able to identify at least half a dozen features in the last 3 categories that you can commit to cutting.

Ideally, you disable them in the old software, and observe how many people complain.

Too often, product management commits to cutting a feature, and then caves in when paying customers complain. It's best to know in advance which category a feature really falls in.

Re: Red Flags Signaling That a Rebuild Will Fail

#77

Post by eecc »

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…

100% feature parity sounds like the advice in #4, involve Marge, without actually having a Marge to call. That’s supernatural development;)

Re: Red Flags Signaling That a Rebuild Will Fail

#78

Post by kornish »

CalRobert wrote: post #75
kornish wrote: post #74

Earlier quoted context omitted.

Tracking events without user IDs would still allow for aggregate feature usage tracking. Out of interest, what makes you think that an application won't legally be able to record the ways in which a user interacts with that application? Obviously I'm not speaking for Heap; just curious.

We need case law to settle the matter but in general, the GDPR indicates that if you don't need to collect the data in order to perform the requested activity, you need explicit consent for collecting it, and will be held to a high standard in court if this every comes in to question.

Very good to know.

Correct me if I'm wrong - seems like anonymizing the usage data complies with the GDPR, and thus the grandparent post still stands.

Re: Red Flags Signaling That a Rebuild Will Fail

#79

Post by wink »

perlgeek wrote: post #76
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…

> And you should be able to identify at least half a dozen features in the last 3 categories that you can commit to cutting. Ideally, you disable them in the old software, and observe how many people complain. Too often, product management commits to cutting a feature, and then caves in when paying customers complain. It's best to know in advance which category a feature really falls in.

Ideally, disabling features in the old software is not so complicated that a rewrite suddenly sounds even more enticing. /s

Re: Red Flags Signaling That a Rebuild Will Fail

#80

Post by wink »

twunde wrote: post #40
solox3 wrote: post #8

With this good article I think I have a good question. The reference to Martin Fowler’s strangler pattern ( https://www.martinfowler.com/bliki/StranglerApplication.html ) was mentioned in the article to grow the new system in the same codebase until the old system is strangled. In my case (Ionic 1 to 2) however, both the entire framework and the language are different. How should the strangler pattern work in this ca…

For webapps you would use a reverse proxy such as nginx or haproxy and replace your application page by page. Then configure the reverse proxy to send all requests to /home to go to the new stack and all other requests go to the old stack. Then flip the switch for every page you finish converting. For backend work, it's similar. You can have an api built in a new stack and it can just have a different endpoint or use…

Seconded. Took part in a moderately big rewrite with this strategy and it worked pretty well.

Identify key components and subsystems and rewrite them one by one. From the outside you seem to be switching over one REST endpoint after the other, but of course internally it's a bit more difficult, but applications often enough have enough parts that are not SO intertwined that you can do stuff like this. It's a bit related to how you break up a monolith. Find bigger, less coupled parts and shave them off and just touch the glue code.

Post reply on HN