Hacker News Reader

Yeeeah... I've seen plenty of startup companies end up in "dead man walking" state because tech debt situation paralized their ability to pivot and follow the growing market and couldn't respond fast enough to growing costs. The developers causing the issues also left when the work became unfun, so they ended up without employees as well.

My work puts me in a similar position, but when they've gone bankrupt, and I see same thing. It's common to not invest in good enough developers early enough to manage to delete, refactor, upgrade and otherwise clean their software in time to be able to handle growth or stagnation on the business side.

Once I saw a software that was built mostly by one person, in part because he did the groundwork by pushing straight to main with . as the only commit message and didn't document anything. When they ended up in my lap he had failed for six months to adapt their system to changes in the data sources they depended on.

Sometimes the business people fucks up too, like using an excellent software system to do credit intensive trading without hedging for future interest raises.

I'm not so sure machines will solve much on either side even though some celebrities say they're sure they will.

That sounds really interesting. If you would be open to chatting sometime, I'd love to hear more. I'm writing a book about preparing companies for this, and can be reach at iain c t duncan @ email provider who is no longer not evil.

> I work in tech diligence. This means the companies I talk to cannot lie or refuse to answer a question

Nice. How do I get into that kind of position?

> Tech debt paralyzes companies all the time, but nobody hears about it because there's zero advantage to the companies in sharing that info.

If nobody hears about it, then how do you hear about it? Moreover, what makes you think it's tech debt and not whatever reason the business told you? And further, if it's tech debt and not whatever reason the business told you, then don't you think the business lied? And didn't you just say they're not allowed to lie?

Can you clear that up?

Sure I can clear it up.

What happens is once they are into a potential deal, they go into exclusivity with the buyer, and we get brought in for a wack of interviews and going through their docs. Part of that period includes NDAs all around, and the agreement that they give us access to whatever we need (with sometimes some back and forth over IP). So could they lie? Technically yes, but as we ask to see things to demonstrate that what they said is true, and it would break the contract they've signed with the potential acquirer, that would be extremely risky. I have heard of cases where people did, it was discovered after the deal, and it retroactively cost the seller a giant chunk of cash (at risk of even more giant law suit). We typically have two days of interviews with them and we specifically talk about tech debt.

Our job is to ask the right questions and ask to see the right things to get the goods. We get to look at code, Jira, roadmap docs, internal dev docs, test runner reports, monitoring and load testing dashboards, and so on. For example, if someone said something vague about responsivness, we'll look into it, ask to see the actual load metrics, ask how they test it and profile, and so on.

I got into because I had been the CTO of a startup that went through an acquisition, knew someone in the field, didn't mind the variable workload of being a consultant, and have the (unusual) skill set: technical chops, leadership experience, interviewing and presenting skills, project management, and the ability to write high quality reports. Having now been in the position of hiring for this role, I can say that finding real devs who have all those traits is not easy!

> I can say that finding real devs who have all those traits is not easy!

Sounds like some very high bar to meet, that's for sure!

> We typically have two days of interviews with them and we specifically talk about tech debt.

> Our job is to ask the right questions and ask to see the right things to get the goods. We get to look at code, Jira, roadmap docs, internal dev docs, test runner reports, monitoring and load testing dashboards, and so on.

Call me a skeptic but, given that scope, I have trouble believing that two days is sufficient to iron out what kinds of tech debt exist in an organization of any size that matters.

Well, the two days are just for interviews. So we have a lot longer to go through things and we send over a big laundry list info request before hand. But you're right, it's never enought time to be able to say "we found all the debt". It's definitely enough time for us to find out a lot about their debt, and this is always worth it to the acquirer (these are mid to late stage acquisitions, so typically over $100M).

Also, you'd be surprised how much we can find out. We are talking directly to devs, and we're good at it. They are usually very relieved to be talking to real coders (e.g., I'm doing a PhD in music with Scheme Lisp and am an open source author, most of our folks are ex CTOs are VP Engs) and the good dev leaders understand that this is their chance to get more resource allocation to address debt post-acquisition. The CEOs can often be hand wavy BS'sers, but the folks who have to run the day to dev process are usually happy to unload.

Sounds about right. The startup I worked for (acquired by a FANG) turned over the whole code base, for example.

If I may ask, were you directly involved in the process? I'm writing a book based on my experiences and would love to hear more about FANG diligence differs. I can be reached at iain c t duncan @ email provider who is no longer not evil in case you are able and interested in chatting

I see there being no tech debt with sufficiently advanced AI. If humans are sufficiently out of the picture the AIs can just revert to highly performant binary output.