Lessons interviewing 200 engineers: the perfect process to manage tech debt

The problem is software engineering discipline is wrought with missing the business context and ROI. Everyone talks about unit testing, clean code, refactoring, tech debt, documentation and whatnot. But no one talks about how much unit tests is appropriate for a project. A front-end for a simple simple CRUD todo list shouldn't have as many unit tests as a safety critical application. Unfortunately no one talks about this.

I have seen a startup where ciritical data processing infrastructure doesn't have any kind of tests because the management doesn't understand technical importance. While the front end team which develops a simple web interface for just showing the data to customers follows TDD, tries to achieve 100% code coverage, every single function has documentation, extensive code reviews and whatever new clean-code techniques you can think of. Not surprisingly the front end team has 6 times more people than the data processing team. Obviously bad management is to blame here. But I can't help but think how much all these tech debt and clean code artciles on the internet is responsible for this. Advising people blindly to follow some development methodologies without the discussion in which contexts these methodlogies are acceptable, what are the costs and what are the trade-offs. There's a lot of resume driven developers out there find these articles and waste business resources to fill in their resumes.

This advertisement/article is crap. It contains almost no information, certainly nothing useful or actionable and the title is mostly just buzzwords. I don’t know who’s voting this up but it’s depressing.

Leaving the ad aside, does anyone besides me think it's time for "software engineer" to become less of an aspirational BS title and more of a real standard we can live up to? I am painfully aware that you can't get a job unless you buy in to bad engineering practices, so I don't blame most individual people necessarily, but a duty of care and a duty to the public trust shouldn't be foreign concepts. If we really thought we had a duty to the public, would we leave codebases in such a shambles?

> [blah blah] This process, which sounds laborious, becomes very easy for Stepsize users. [blah blah]

Just go to stepsize.com

This article is absolutely useless and the title is misleading since it provides no lessons at all. I just created an HN account so that I could prevent other poor souls from going to this junk of an article.

The term "technical debt" has a certain semantic load and is therefore almost impossible to have a proper discussion about it.

There are several things that are meant by it:

1. Every written line of code could be improved. If we use such a definition, everything is technical debt and we can spend 100% of our time in improving it and we will still have 100% technical debt. Stepsize would benefit from letting you do this :)

2. Code rewriting needed because of progressive insights and new features that need to be implemented or new requirements, updated dependencies like libraries, frameworks, programming language, runtime system etc.

3. Inadvertently incorrectly written code: this has actually nothing to do with debt. It's a natural and largely unavoidable thing that happens when a human writes code.

4. Deliberate choices while writing code and taking short cuts that are actually almost not acceptable that need to be rewritten later.

Only the last category is in my opinion actual "technical debt" but I would rather call it "shortcuts to be rewritten".

I don't think it makes much sense to discuss it without making an explicit distinction between these 3 categories.