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

121–130 of 142 posts

Re: Red Flags Signaling That a Rebuild Will Fail

#121

Post by zelos »

mehrdadn wrote: post #73
majormajor wrote: post #56

Earlier quoted context omitted.

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 too…

Rewriting "a chunk" of code kind of is refactoring, though.

Re: Red Flags Signaling That a Rebuild Will Fail

#122

Post by toshaga »

jupake wrote: post #104
pspeter3 wrote: post #6

I think people also deeply underestimate the time it will take. We've undergone an incremental rewrite for ~4 years at Asana.

Used your software once before. Loved it! You guys should do a blog post about your rewrite experience. Would love to know what your tech stack was and what your new one looks like.

This could be relevant: https://blog.asana.com/2017/08/performance-asana-app-rewrite...

Re: Red Flags Signaling That a Rebuild Will Fail

#123

Post by philliphaydon »

maxxxxx wrote: post #26
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…

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.

I once worked on a feature that apparently lots of clients were asking for. It took 4 weeks to implement. Went to production. Never heard anything of it. 2 years later if we could modify the feature to work for another usecase. I looked at the database. The feature had never... ever... been used.... rows returned = 0

Re: Red Flags Signaling That a Rebuild Will Fail

#124

Post by mannykannot »

mehrdadn wrote: post #73
majormajor wrote: post #56

Earlier quoted context omitted.

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 too…

Knowing what the system should do, in sufficient detail that there is nothing of significance to be discovered with regard to its requirements, while simultaneously not actually knowing enough about how it works to the point where you could plan how to refactor it, is quite a corner case in the field of legacy systems (the latter is quite commonplace, but the former is almost unheard of.)

Re: Red Flags Signaling That a Rebuild Will Fail

#125

Post by LolNoGenerics »

bkovacev wrote: post #117

This is yet another article where there's a clear managerial-only approach. Sorry, but I dont dig this. As a developer you're constantly fighting managers who want to rush things to get them out and who will eventually blame you for a bug/non-defined behavior once you hit a certain milestone. To me it seems the author of the article doesn't understand the tech debt. If you've ever worked in a startup you'd know that…

His argument is against rewriting a whole codebase. Refactoring is surely an alternative.

Re: Red Flags Signaling That a Rebuild Will Fail

#126

Post by chriswarbo »

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.

Yes, but like the "cookie law" before it, it's absolutely fine to go ahead and do it if it's required (in the case of something like logging aggregate usage counts of APIs, that's easy to justify as a requirement for maintaining a reliable service; it's basic server monitoring).

Things like online stores using cookies to track a user's shopping cart across requests are completely fine, yet it seems like legal departments decided to be overly cautious and treat all cookies as potentially infringing. GDPR may be triggering similar reactions.

I wouldn't have a problem with that if marketing departments became equally cautious, but they seem to just slap on a banner and carry on as before :(

Re: Red Flags Signaling That a Rebuild Will Fail

#127

Post by Djvacto »

konschubert wrote: post #84
tomelders wrote: post #35

I’ve carved a career out of rebuilds. I’m working on a rebuild right now. There’s a ton of companies out there who’ve done very well with their home grown antiquated systems from the late 90’s and early 00’s that are now facing stiff competition from young upstarts who had feature parity from day one and are knocking out new features at break neck pace because they’re leveraging the latest and greatest in tools, tech…

> Just a couple of devs whose job it is to try and rebuild your thing from scratch. That may be good value for big established corporates, but for startups and smaller companies I don't think it is.

Well (on a relative scale), won't most startups or smaller companies be more in the phase of "writing" as opposed to "re-writing"? I think the advice above would in theory apply to companies big enough to have legacy codebases.

Re: Red Flags Signaling That a Rebuild Will Fail

#128

Post by maxxxxx »

philliphaydon wrote: post #123
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.

I once worked on a feature that apparently lots of clients were asking for. It took 4 weeks to implement. Went to production. Never heard anything of it. 2 years later if we could modify the feature to work for another usecase. I looked at the database. The feature had never... ever... been used.... rows returned = 0

That's why its important not to believe what customers and product managers say what features they want. I have had a ton of occasions where it turned out that what they really wanted was totally different from what the devs were told.

Re: Red Flags Signaling That a Rebuild Will Fail

#129

Post by hinkley »

kwhitefoot wrote: post #81
hinkley wrote: post #46

Earlier quoted context omitted.

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.

I've been fighting this problem for my whole software development career (more than 35 years now and no end in sight).

When this happens a couple times you start sounding like Honey from the Incredibles.

It’s difficult not to sound combative when they say they want a convertible but you have to wheedle out of them that they want to take a proverbial road trip through monsoon season. No, you get a Land Rover with a snorkel or you wait, pal.

So bossy and difficult. Why won’t you just give us what we asked for? These meetings would go so much faster.

Re: Red Flags Signaling That a Rebuild Will Fail

#130

Post by ConceptJunkie »

rwmj wrote: post #107

Is "rebuild" new jargon for "rewrite", or does it mean something different? I thought the article was going to be about builds failing.

Yeah, I did too until I started reading the article.

Using the normal sense of "rebuild" didn't make sense.

Post reply on HN