Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

[DL Neil]

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
>> job-seeking.
> 
> 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 
'Python', apologies!)

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 
relationship.


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 
it'-Agile environment)?

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 
'other things'?

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...
-- 
Regards =dn