3 ms·
The customer doesn't know about or understand technical debt. Any improvements you make down there are just racking up on time spent that makes the bills highe
by wila 10y ago
The customer doesn't know about or understand technical debt.
Any improvements you make down there are just racking up on time spent that makes the bills higher which they will notice.
They do not see your improvements, but they will notice it if your much betterer code now introduces a new bug.
Higher bills as your predecessor, slow in fixing and new bugs. That is the moment to worry about getting bills paid, not for fixing fast.
- alkonaut 10y agoThe thing is, the existing customers are locked in (or we failed). The customers we want are those that aren't customers yet. Those customers require features that we don't have yet in order for them to become customers. It might be the right decision as a business to screw the existing customers by aggregating tech debt in order to grab new market share before the competition does (again this is in a context where a customer has no chance of leaving once on board - which is more or less the case in all enterprise scenarios I have experience from, both web and desktop). I hate this mentality and as a developer it's terrible - but I can't say that it's the wrong decision to make short term, business wise.
- wila 10y agoGuess I simply do not share your view. My customers are not locked in, in fact I will go out of my way to make it easy for them, their employees or even another consultant to continue on any work of the work I do and have done for them in the past. In addition I am not in favor for aggregating technical debt, I suppose I wasn't clear. The article talked about a 1 line fix and that by itself should not trigger a rewrite of a feature, especially not when the fix has to be done now, not next week.