Hacker News Reader

Comment by woutr_be | Hacker News Reader

A part of a product I worked on was killed by the business and outsourced instead. I’m 100% sure this was in fact because of technical debt, even though my team members would disagree.

It wasn’t even technical debt in the sense that it was bad code, it was because they prematurely tried to optimise everything, so adding a feature would take twice as long. We also couldn’t add new devs to the project because the team lead’s decision to not document the code, because “code should document itself”.

Bugs could only be identified by the dev who wrote that feature because the code was so obscure and undocumented.

View on HN

> A part of a product I worked on was killed by the business and outsourced instead. I’m 100% sure this was in fact because of technical debt, even though my team members would disagree.

I've also had this experience, where a product accumulated so much tech debt (in part, due to my decisions) that it was simpler for the business to outsource the functionality. That wasn't the only reason, but it was a big one. When tech debt sand gets in the software delivery gears, the allure of vendors increases. Sure, the business won't get things exactly like they want them, but they won't have to deal with missed deadlines and degraded functionality either.

> When tech debt sand gets in the software delivery gears, the allure of vendors increases

Well put. Could not have said this better myself. I've experienced situations where the tech debt sand is a consequence of fairly unique business and internal system constraints. The allure of vendors did increase and the company did eventually research vendors, but nothing addressed our snowflake use cases perfectly.

I don't think that's necessarily a positive reflection on our product though. If anything, the lesson I take from that is to build your business processes and teams to reduce as much accidental complexity as possible.

That’s exactly what happened. I’m sure the vendor code is riddled with spaghetti code, poorly optimized and undocumented. But as long as they deliver, the business doesn’t have to care about it. They can also just say what they want, and it gets done, without any real pushback from developers.

I can’t blame them for doing this tho, I often felt like we spend most of our time discussing implementation, doing code reviews and optimizing code for the sake of optimizing it. Towards the end it was also clear the business just didn't want to deal with our team anymore, they were annoyed we couldn’t just build the feature they wanted.

At this point in my career, I just run away from a company that operates that way.

Code tells me what the coder was doing. It does not tell me why. If the why is not blindingly obvious, it deserves a code comment.

What're some good project that has the right balance of documentation? in your opinion

I am looking for projects that are very small.

I think this depends on a per project basis, in some projects the code can speak for itself, any competent developer would be able to look at the code and understand what’s going on.

In projects with a lot of business logic, or projects that require understanding of a specific subject, it’s often better to write comments to clarify what’s going on. Sometimes code alone isn’t enough.

I agree and to that list I'd add:

- Performance optimizations (always worth mentioning why you ugly'd up some code for a necessary speedup)

- Kludges where you're working around something in an external library or service

can you give me any examples

Reply on news.ycombinator.com