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

131–140 of 142 posts

Re: Red Flags Signaling That a Rebuild Will Fail

#131

Post by ConceptJunkie »

watwut wrote: post #67
Chyzwar wrote: post #24

Earlier quoted context omitted.

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.

I think it's the phrase used by someone else in the comment chain: "clueless management".

You can have the best developers and architects in the world, but clueless management will sabotage anything they do, whereas good management can accomplish plenty with teams that aren't the best possible.

Re: Red Flags Signaling That a Rebuild Will Fail

#132

Post by fgonzag »

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…

But rewriting one chunk at a time could be considered refactoring.

Re: Red Flags Signaling That a Rebuild Will Fail

#133

Post by mehrdadn »

fgonzag wrote: post #132
mehrdadn wrote: post #73

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

But rewriting one chunk at a time could be considered refactoring.

Yes, two other people have said the same thing already. I don't personally agree with it but I don't have a response beyond that.

Re: Red Flags Signaling That a Rebuild Will Fail

#134

Post by esdkl22 »

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…

> If your sales team has more clout than your designers and developers, then you’re fucked. And in the enterprise software world, this is the norm. An uncheked sales team that get’s whatever it wants has already killed your product and made it impossible to rebuild. Their demands are ad-hoc, nonsensical, and always urgent. So urgent that proper testing and documentation are not valid reasons to prevent a release. Their demands are driven by their sales targets, and the promises they make to clients are born out of ignorance of what what your product does, and how it does it.

Well said. This is easily my #1 biggest pain point as a developer.

Re: Red Flags Signaling That a Rebuild Will Fail

#135

Post by darkerside »

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…

It's very hard to get a man to understand something when his salary depends on his not understanding it. By the same principle, as someone who has built a career out of rebuilds, we shouldn't be surprised that you'll recommend this solution for a majority of hypothetical problems. I don't think you are intentionally misleading people, and I'm sure that you want the best for your clients and that you believe that's what you're providing. It's just that, for anyone else reading this thread, please realize that you're getting one side of the story.

Incremental rebuilds are not sexy. Adding unit tests to legacy code (thereby making it not legacy code according to Michael Feathers) is not sexy. Sticking with the tried and true technology is not sexy. But they are typically the most successful approaches for those not compensated for changing things for change's sake.

Re: Red Flags Signaling That a Rebuild Will Fail

#136

Post by philliphaydon »

maxxxxx wrote: post #128
philliphaydon wrote: post #123

Earlier quoted context omitted.

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.

Yeah, I always ask our user stories to have a 'background' section explaining the problem and reason for the feature request so it can help us understand the importance and purpose of the feature.

Re: Red Flags Signaling That a Rebuild Will Fail

#137

Post by Ensorceled »

Cthulhu_ wrote: post #114
Ensorceled wrote: post #18

Red Flag #6: Key stake holders keep moving the goal posts. If your goal moves from feature comparable but on a modern platform, to new features, to a complete reinventing of the product all without actually shipping ... you might be in trouble. I had a rebuild go 6 months over. In the heated executive meeting at t+3 months I was called to defend my team and pointed out that the VP Product had just delivered “final” s…

> The fact that the specs were changing weekly because “we’re agile” is a whole other issue. The article touches on that too; simplified it's stating that if you're not live within 6 months, you're doing waterfall.

That’s not waterfall. Waterfall you don’t start dev before specs are final.

Waterfall isn’t just a synonym for “the wrong way to do it” :-)

Re: Red Flags Signaling That a Rebuild Will Fail

#138

Post by gregmac »

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.

Almost all feature requests are asking to implement a particular solution rather than asking to come up with a solution to solve a particular problem.

The way I try to solve this is to ask "why?" as many times as it takes to get to a fundamental business problem. Then it becomes easier to have a user story (as opposed to a specific feature request) and come up with other solutions that can be measured against the story. It also helps to keep the product focused, as it's easier to tell when a story is not for your target market vs a feature request -- and then you can make a conscious decision to either stay away or deliberately expand to that market.

Re: Red Flags Signaling That a Rebuild Will Fail

#139

Post by zbentley »

omeid2 wrote: post #64
zbentley wrote: post #54

Earlier quoted context omitted.

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.

I completely agree. Having a pure-research team with a mandate of "all your research must be geared towards totally reimagining the entire product" is a dumb idea. Having more granular (and collaboratively driven) goals from "some of your research must be geared towards totally rewriting an area of our application that is a major pain point, and for which all previous attempts to do incremental changes have failed for technical reasons" to "look into better tools or strategies we could use to tune performance of, or write better tests for, swaths of existing code" is more realistic and more useful.

Obviously, other, not-pure-research devs should be given time to do some of that work as well, otherwise the research team becomes the "saviors that are always about to come back over the hill" for every other team while they kick their respective cans down the road.

Re: Red Flags Signaling That a Rebuild Will Fail

#140

Post by pspeter3 »

toshaga wrote: post #122
jupake wrote: post #104

Earlier quoted context omitted.

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

That is definitely the best out there. I'm hoping to write another about what our current stack is.
Post reply on HN