> DEV: "We can only do that by cutting corners, reusing code for purposes we shouldn't, and making it not extensible in the future"
This is an inexperienced dev talking. If s/he was more self-aware, it would be
DEV: I'm not very good at architecture so whatever date you need it by I'm probably going to make a relative mess of it. If you give me more time, at least my rate of introducing mess into the codebase will slow down, so there would be _that_.
> ...because you can’t define it with any precision no matter how hard you try.
For my clients, when we discuss "tech debt", I give it to them in concrete terms.
"You want Capability A at Month 3, but in order to pull that off, you're going to have to give on Requirement 1 and Expectations Lambda, and it will cost us Y months of implementation in Q4 instead of Y-2 months, will that work for the business?"
"Sure."
"So marked in the meeting notes, and filed under our Tech Debt Jira backlog Feature, we won't move forward with Capability A implementation until you send Sam when you need the technical debt paid off by, and we'll slot it in ahead of time, okay?"
"No problem, we'll get it to you with more detailed requirements on Capability A next week, thanks!"
Sure, when you don't track tech debt it is just sloppy work ("incompetence" is a little harsh, I tend to say the staff involved need more coaching and are possibly more junior than their roles require...bees, honey, and all that). It has served me well to get through to those managers who initially demand the impossible.
No, I was on my way to upvote your comment when I got to
> but you know I’m right because you can’t define it with any precision no matter how hard you try.
It's when somebody decides to optimize for one thing that temporarily mattered to them at the time, at the expense of other things that matter afterwards.
Eg, having that demo next week may truly be existential for the project, but all the foundations you didn't dig and the rebar you skipped putting in to tick that box mean you cannot successfully build on it without going backwards first.
It’s a way to act like one “meant” to implement a shitty architecture instead of admitting one’s lack of ability and experience.
It’s the mantra of the expert beginner of which there are so many.
You think I’m wrong, but you know I’m right because you can’t define it with any precision no matter how hard you try.