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

41–50 of 142 posts

Re: Red Flags Signaling That a Rebuild Will Fail

#41

Post by [deleted] »

throwaway2048 wrote: post #30
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…

One thing to be careful not to fall afoul of when you choose to remove features is assuming there is some kind of meaningful average user. A good example is MS Office, there are an huge amount of features that only 5% of users might ever use, but the majority of users are likely to use quite a few of these niches individually, and if you remove all the low use features, you piss off basicly everyone. I think the mist…

[deleted]

Re: Red Flags Signaling That a Rebuild Will Fail

#42

Post by oneplane »

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…

I almost had a few similar situations, but after pointing out that being agile doesn't just means changing requirements but also changing time paths or simply different deliveries after each change it got a whole lot clear what agile (and scrum) is good for, and what it's not good for (i.e. agile process but expecting waterfall results doesn't work).

Re: Red Flags Signaling That a Rebuild Will Fail

#43

Post by flukus »

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.

> You are one of those blessed people who can architect a system and the architecture holds up for decades.

This is exactly why maintenance is needed. Proper maintenance that includes things like updating the architecture and gradually migrating the whole system to that architecture, rebuilding small unwieldy components, updating and migrating database schemas as the product evolves, removing unused features.

If a product is just getting bugs patched and nothing else then it isn't really being maintained, it's being deprecated. Unfortunately as an industry we still think that there are distinct build and maintenance phases and that the latter can be done with less resources.

Re: Red Flags Signaling That a Rebuild Will Fail

#44

Post by [deleted] »

munk-a wrote: post #34
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 think it's important to separate feature improvements from a technical rewrite, ideally in the rewrite you mostly just make things work the way they did, sometimes you might fold a feature improvement into it but if you come out of the rewrite with a more stable product that has about the same usage stories you should consider it a success. Sometimes you will want to fold features into a rewrite (remove prompting t…

[deleted]

Re: Red Flags Signaling That a Rebuild Will Fail

#45

Post by flukus »

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…

> I’ve carved a career out of rebuilds

What's your learning process? If you don't do maintenance how do you know your rebuilds aren't creating the same problems that lead to the systems needing replacement?

I've got a very well founded distrust of people that only work on green field projects, they're generally responsible for the system's that need rebuilding.

Re: Red Flags Signaling That a Rebuild Will Fail

#46

Post by hinkley »

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.

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.

Re: Red Flags Signaling That a Rebuild Will Fail

#47

Post by gknoy »

omegaworks wrote: post #13
ronpeled wrote: post #10

Earlier quoted context omitted.

There's no super easy way here. One way to get this done is find independent areas of the app that can be replaced without coupling. Then start building up as you go with the new system. At some point you'll be about 70% through of which you can decide if you want to make the jump and focus your efforts to completely uproot the old one. Sorry for the abstract reference here, but it applies to almost any replatforming…

Are there any examples out there for how to do this with React in an existing AngularJS codebase?

Instead of a Single Page Application, make it an MPA (multi-page application), each of which is basically a separate SPA. You get latency when swapping between sections of your app, but on some codebases (such as for an internally-used app), that's less of a problem.

We did something similar to this when we broke up our Ember application so that we could code new things in React. We still maintain our Ember codebase, but are rewriting parts of some routes in React, and adding all new things in the React app.

We deploy ours as separate pods in a Kubernetes cluster, but you could even host them on the same server with separate nginx routes.

The initial ramp up of this is a little frustrating, as it seems you're adding extra overhead to everything, the long term goal is to have infrastructure and workflow that supports having part of your app in The Old Proven Thing, and part in The New Hotness. This is valuable whether you're switching to React, or upgrading from Ember 2 to 3, etc, as it lets you upgrade a smaller set of dependencies, and experiment with things.

Re: Red Flags Signaling That a Rebuild Will Fail

#48

Post by CydeWeys »

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 rebuild of the application but it's definitely substantial in effort level.

Sometimes a rebuild is just necessary, because you are on a tech stack that is no longer working for you, for whatever reason. How would you solve that kind of problem?

Re: Red Flags Signaling That a Rebuild Will Fail

#49

Post by teddyh »

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

#50

Post by omeid2 »

flukus wrote: post #45
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…

> I’ve carved a career out of rebuilds What's your learning process? If you don't do maintenance how do you know your rebuilds aren't creating the same problems that lead to the systems needing replacement? I've got a very well founded distrust of people that only work on green field projects, they're generally responsible for the system's that need rebuilding.

I have also come to believe that people who jump to rebuilds also tend to have very shallow technical skills and are not keen or capable of studying and analyzing a system at depth.
Post reply on HN