Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)
On 13/02/20 9:17 AM, Michael Torrie wrote:
> On 2/12/20 7:44 AM, Ethan Furman wrote:
>> On 02/11/2020 04:38 PM, Michael Torrie wrote:
> True. Costs can be calculated and planned for. But Technical debt is
> often impossible to quantify in a real, meaningful, business sense,
> other than the that we "know" it's going to cost big time in the future.
> In some senses, it's theoretical future cost. That's what I was having
> a hard time with, and still do to a large degree.
>> I think an oft overlooked aspect of technical debt is the affect on
>> the programmers dealing with it: frustration, burn-out, and
> Yeah for sure. A programmer may not love dealing with technical debt,
> and certainly he may want to chase greener fields. But there are lots
> of things about lots of jobs that are less pleasant than other things.
> Personally I tend to get way caught up trying to get a perfect design
> that avoids technical debt, but often get not much done (on my personal
> projects). Whereas another guy just cranks out code that isn't always
> the best but serves his needs at the time. Guess who is more productive
> overall? Not me.
Applauding your professional attitude, but haven't you (only) defined
"productive" as purely getting 'this job' out the door? cf any
definition of "Total" cost?
I had an IT Manager moaning at me precisely because of one of those
'other guys'. The job had been 'done'. The contract had mere 'words' to
cover 'quality'. Accordingly, difficult to argue that 'the guy' hadn't
done what was asked (my 'specialist' $advice on the matter). However,
the code was 'ramshackle' and had obviously been 'dashed off' in the
shortest amount of time possible. Maintenance costs were expected to be
high; motivation of in-house staff to do so, expected to be v.low!
So, we're re-negotiating the contract-wording... More importantly,
improving their acceptance testing, and adding more detail to their
specs/requirements, etc. (the mistake there, was thinking that reqmts to
external staff would be 'the same' as such to in-house employees)
However, the interesting question was to ask whether he (the manager)
was 'taking advantage' of the "gig economy". (yes, that's what it's
there for!) Thus, what relationship did he (or even, 'they' of the IT
dept) have with the contractor? The home truth: 'using' the cheapest
people creates a 'race to the bottom', and must, by definition, lead to
'the cheapest job' being done. Why the surprise?
(He doesn't hire me as a programmer - and we're not even talking
I asked him if he wanted a 'professional' to do the job, ie in a
'professional manner'. Yes! So, why are you looking for the guy(?)
who'll do it at the lowest-possible price/rate or imposing the delivery
date on a short time-line? Ahh...
The above concerns contractors, but I managed to slide-in a few
questions/comments that relationships with in-house staff require
similar consideration and attention!
OK, so turning it around to people more like 'us': Professionalism? As a
programmer/coder, would you rather work on decent code? So, is that what
you turn-out? Alternatively, vice-versa.
That is a slightly unfair, or biased, question. I am in the fortunate
position of being able to tell certain people that I won't undertake
their work, that where they want me to work will push the price UP, that
their tool-set is sub-standard, or that the existing platform is imbued
with uncomfortably high 'risk'. I quite understand that someone who
'needs the job' will see that as a 'luxury'. (apologies as necessary)
That said, would you build a team with a mixture of 'clock-watchers' and
'professionals' or would/do you enjoy working within such a team?
Both 'sides' need to understand that there are two view-points to every
One thought that occurred to me lurking/reading this thread, is the
likelihood that many of the differing views arise between those working
in an 'Agile' environment, and those not (or a pseudo-/'we call
One of the (social) contracts in Scrum (for example) is that the
professionals estimate the time needed to do the job, cf some (likely
ignorant) 'manager' imposing a deadline. In my experience (YMMV) an
established, professional 'Agile' team tends to follow practices which
attempt to avoid adding to Technical Debt, and factor-in any need to
correct sub-standard or sans-tests old-code. There is no doubt in my
mind, that the participation of 'users' helps to create an understanding
that (like anything else) software takes time (read also $), and that
over-loading (?abusing) development staff is itself a 'Technical Debt'
("Marginal Cost") for the organisation! (absences, turn-over, ... you've
been-there, seen-that...). There again, would user-members of the team
notice if 'we'd' padded our estimates so as to have plenty of time for
It's by no means a cut-and-dried situation. What 'works' in one case may
not even get-of-the-ground in another!
Thanks for provoking the grey-matter to ponder...