Can I borrow your expertise to help kick around a half-crystallised thought?
A lot of my job atm is reimplementing up-to-40yo sh/perl/tcl with some semblance of maintainability.
I need a way to explain to management what's wrong with existing code, and the design goals that are needed.
1/
Apart from horrors like no function parameters anywhere, just scattered globals you have to magically know about, and functions named doit(), the biggest problem is the chaotic and incoherent decomposition of tasks, which describes neither the problem nor the solution.
2/
It's like... like watching an hour of a restaurant kitchen vs a cooking show: all the jobs get done very efficiently I'm sure, but there's no binding narrative, no clue as to intent or what the hell this stuff is for, and impossible to infer shit about until you've internalised the entire thing. 3/
There is no tree of subtasks, just a giant bramble hedge.
Are there, please, any fancy software-engineering words that talk about task decomposition (as opposed to just naming-things) being act of communication-with-humans in and of itself, and thus requiring strong communication skills?