So my real job is technical due diligence on companies being purchased. I get the keys to the kingdom when we do a diligence and trust me, there are just as many people making unmaintainable monstrosities that get bogged down in tech debt in Ruby. Looking at this scenario is literally my job, and the company I work for does more of these than anyone in the world.
Bad coders can make terrible stuff in any language, and with two as similar as Python and Ruby, the minor differences are a drop in the bucket in the grand scheme of things. Both Django-database code and RoR's Active Record have bogged down many a startup when they got big enough that DB size and query performance mattered.
None of which, as I pointed out, is relevant to the vast majority of scientists writing code.
In your experience, what are most buyers looking for when they get you to do technical DD? Is there a specific set of things they are worried about? Specifically looking to confirm, etc?
Typically they are looking to us to surface areas where they will have to make "disproportionate investment" (as they say) to allow the company to support a ramp up in growth. "What will be a problem when you have 2x as many customers? 10x as many DB entries? 10x as many customers?" etc. Because private equity funds buy companies that are growing and (usually) already profitable, this often equates to tech debt that happens once the DB is big. A very common scenario is that reporting, for example, has become a problem and it's time for the target (as we call them) to be using heavier weight architecture patterns like command query segregation or dedicated reporting databases or materialized views and such. So in the case of Ruby and Python shops, we will definitely be asking if their domain layer is working ok and trying to find out if they've written themselves into a corner by having the code assuming it will always be an RoR app or whatever. I have interviewed more than a few that were in serious trouble from not isolating their Active Record dependency and thus got themselves in a situation where efficiently fixing the database was going to be a lot of rewriting. We see this in other languages too, but Active Record is absolutely a smoking gun there.
The takeaway: always, always, have a domain layer that allows you to refactor your model access without changing tons of code. Data load grows in ways people don't predict. If your company succeeds, in five years you'll wish you had it!
Tech debt kills loads and loads of companies and most folks never hear about it because that's not the stuff that gets publicized or written about. We call it the silent killer...
That's really reassuring to hear. Whenever I say we should spend time on tech debt it's always greeted with "we can worry about that later when we're really successful" as if there will suddenly be an opportunity to completely rewrite everything (because that's what it will take).
Yeah, the idea that tech debt doesn't matter and can just be fixed later is the biggest bullshit myth out there in tech land. The thing is, no one notices or writes about when a startup does an "underwater sale", which is typically an investment firm's portfolio company (company they already own) buying up a competitor for less than the company was worth on the last round, done usually in order to buy the customers, staff, or IP. It happens tons. It's a "cut bait" scenario (i.e. let's lose less now instead of everything later) for the selling company/owners and is usually a result of technical debt.
Bad coders can make terrible stuff in any language, and with two as similar as Python and Ruby, the minor differences are a drop in the bucket in the grand scheme of things. Both Django-database code and RoR's Active Record have bogged down many a startup when they got big enough that DB size and query performance mattered.
None of which, as I pointed out, is relevant to the vast majority of scientists writing code.