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

21–30 of 142 posts

Re: Red Flags Signaling That a Rebuild Will Fail

#21

Post by nostrademons »

#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 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. And you should be able to identify at least half a dozen features in the last 3 categories that you can commit to cutting. Otherwise it's likely that the rewrite will contain all the complexity of the original system, but without the institutional knowledge built up on how to manage that complexity.

Re: Red Flags Signaling That a Rebuild Will Fail

#22

Post by pbreit »

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?

Re: Red Flags Signaling That a Rebuild Will Fail

#23

Post by whatshisface »

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…

People sometimes complain about how developers like to "write the operating system and then a language" when it comes to handling every foreseeable permutation of what the program might every be desired to do, but we're all so used to unstable requirements that sometimes the metaphorical programming language research is the only thing that will be general enough to find a use next week.

Re: Red Flags Signaling That a Rebuild Will Fail

#24

Post by Chyzwar »

JumpCrisscross wrote: post #19
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 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.

Re: Red Flags Signaling That a Rebuild Will Fail

#25

Post by pbreit »

curyous wrote: post #20
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…

I'm surprised at what gets called a pattern these days. Fowler didn't describe it as a pattern, but just because Mr. Guru said it, it is now a pattern?

The ways it's referred to as a "StranglerApplication" in this post [1] does suggest more than "just saying it".

1: https://www.martinfowler.com/bliki/EventInterception.html

Re: Red Flags Signaling That a Rebuild Will Fail

#26

Post by maxxxxx »

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.

Re: Red Flags Signaling That a Rebuild Will Fail

#27

Post by bumholio »

lovich wrote: post #12
Buttons840 wrote: post #7

Earlier quoted context omitted.

They're already gone, almost certainly.

I've found that they are usually still there but as they are the CEO/CTO it's difficult to get them fired

Hey, a bunch of shell scripts glued to some DOS executables were good enough in my time. We had no fancy schmancy github back in those days, yet we built this business on nothing but hard work and pizza.

Why, the sources of the DOS exes were long gone by second year, lost in the crash of that old Windows Milenium machine that used to sit in our dorm room and was uniquely configured to compile them using Turbo Pascal - we figured it was a safe option to use as a source repository. But that still didn't stop us - we implemented the remaining features by patching assembly.

Re: Red Flags Signaling That a Rebuild Will Fail

#28

Post by maxxxxx »

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.

Re: Red Flags Signaling That a Rebuild Will Fail

#29

Post by grantism »

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?

No necessarily. It depends on what has lead to the need for a rebuild. Sometimes there weren't previously the resources to "do things properly", Sometimes a feature might only added for a specific client, etc.

You need that previous knowledge to know the "why" of things & if that why is still valid.

IMHO it's more dangerous if you're working with experts who don't want to improve the system.

Re: Red Flags Signaling That a Rebuild Will Fail

#30

Post by throwaway2048 »

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 mistaken idea of an average user is why a lot of metrics driven software seems to get more and more useless with every update.

(I cant see the present/away status of contacts in the newest skype, really guys? )

Post reply on HN