Live data from Hacker News

Red Flags Signaling That a Rebuild Will Fail

pkc.io

101–110 of 142 posts

Re: Red Flags Signaling That a Rebuild Will Fail

#101
post #97
post #91

Missing the biggest red flag of all, engineers wanting to just play with new toys and pad their CVs. Ask the engineers why they want to rebuild and listen carefully to the answer and if it’s vague handwaving and buzzwords (microservices! Containers! New JS framework!) and no hard numbers to justify it, just say no. For example “we spend X/year on AWS but if we spend Y to rewrite in C++ we need fewer VMs and can cut t…

The problem is that Y and Z are just numbers you make up. Reliably estimating them is impossible without at least building a prototype.

Sure, but prototypes cost orders of magnitude less than Y. And your engineers can scratch their new toy itch at zero risk.

Re: Red Flags Signaling That a Rebuild Will Fail

#102
post #78

Earlier quoted context omitted.

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.

As long as you anonymise in a way that you can't de-anonymise it should be OK.

>>it seems/should

GDPR, I'm hoping that I don't have to bother my users with a "do you consent to" popup when the only thing I want to do is to log server-side the API calls so that I can see patterns in usage and such. If I were to show such a "do you consent to" popup users might mistakenly think I'm one of those techcrunchers with hundreds of data partners that all get to see your PII. I do not want to affiliate myself with those type of actors.

Anonymously of course. Should be fine, yeah?

Re: Red Flags Signaling That a Rebuild Will Fail

#103
post #91

Missing the biggest red flag of all, engineers wanting to just play with new toys and pad their CVs. Ask the engineers why they want to rebuild and listen carefully to the answer and if it’s vague handwaving and buzzwords (microservices! Containers! New JS framework!) and no hard numbers to justify it, just say no. For example “we spend X/year on AWS but if we spend Y to rewrite in C++ we need fewer VMs and can cut t…

On the other hand, “we cannot hire anyone to work in COBOL/Perl 5.8/Tcl/other outdated language” is a very real problem. It turns out that 2018, developers are judged for working too long in old technologies even when we know as in industry that a developer can learn a new language.

I wonder if that’s really true. I bet loads of people would be delighted for the chance to go on using their old favourites.

Re: Red Flags Signaling That a Rebuild Will Fail

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

Re: Red Flags Signaling That a Rebuild Will Fail

#105
post #102

Earlier quoted context omitted.

As long as you anonymise in a way that you can't de-anonymise it should be OK.

>>it seems/should GDPR, I'm hoping that I don't have to bother my users with a "do you consent to" popup when the only thing I want to do is to log server-side the API calls so that I can see patterns in usage and such. If I were to show such a "do you consent to" popup users might mistakenly think I'm one of those techcrunchers with hundreds of data partners that all get to see your PII. I do not want to affiliate m…

Recital 26:

"The principles of data protection should therefore not apply to anonymous information, namely information which does not relate to an identified or identifiable natural person or to personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable. This Regulation does not therefore concern the processing of such anonymous information, including for statistical or research purposes."

As long as it's not linked to a particular profile ("pseudonymous" doesn't count, it could still be linked), it's fine.

https://gdpr-info.eu/recitals/no-26/

Re: Red Flags Signaling That a Rebuild Will Fail

#106
post #101
post #97

Earlier quoted context omitted.

The problem is that Y and Z are just numbers you make up. Reliably estimating them is impossible without at least building a prototype.

Sure, but prototypes cost orders of magnitude less than Y. And your engineers can scratch their new toy itch at zero risk.

In my experience getting any funding at all is about as hard as getting the whole project approved.

Re: Red Flags Signaling That a Rebuild Will Fail

#108
post #36

Earlier quoted context omitted.

> I’ve always been a big believer in rebuilding your product from the ground up. I think it’s something you should always have going on in the background. Just a couple of devs whose job it is to try and rebuild your thing from scratch. Hahaha. Just a couple of devs?

Their job isn’t to build the whole thing. Their job is to research and explore how new ideas and tools might be useful to your business. It’s just R&D. It’s not an exotic idea.

That's pretty different to what you were talking about originally. You started by talking about rebuilds and said, have two guys just rebuilding the product. Now you're saying they're doing R&D. Those are very different tasks.

Re: Red Flags Signaling That a Rebuild Will Fail

#109
This is gold.

I've become a member of a team the company scrambled to deal with a `legacy` python/SQL - based ingestion/storage system in an effort to 'harden' it. Despite my best efforts, we are going for a full rewrite into java/spring/avro/mongo/es. We have internal users talking SQL and utilising the system at the moment, a fair amount of data is relational.

I have run out of ideas how to convince the team and stakeholders, will have a one-shot chance to talk to VP. Any ideas how to voice the concerns about the full re-design (perhaps I'm just being difficult)?

Re: Red Flags Signaling That a Rebuild Will Fail

#110

This is gold. I've become a member of a team the company scrambled to deal with a `legacy` python/SQL - based ingestion/storage system in an effort to 'harden' it. Despite my best efforts, we are going for a full rewrite into java/spring/avro/mongo/es. We have internal users talking SQL and utilising the system at the moment, a fair amount of data is relational. I have run out of ideas how to convince the team and st…

1. Given the risk, cost and limited upside, the onus is on the refactor team to prove that it needs to be done. Where is the ROI, factor in the risk. Where is this in the stack of things to do? Are there better ROI things?

2. Consider 'what the point' is in the first place, because the entire world could be run on python/SQL and it would be 'hard'. I don't think anyone would consider 'Mongo' to be 'hard' usually people use it because it's fast and easy, not hard. Consider maybe only replacing one part at a time, i.e. Java-SQL.

3. Consider a simple clean up or refactor. No need to learn no languages and tools when maybe you just need a house clean.

4. People seem to be going back to SQL because of it's inherent standardization - so many reporting and analysis systems use SQL as an interface, to the point where even NoSQLs are starting to use SQL.

Post reply on HN