Maybe "tsunami intensity scales" is better measuring option, tech debt you kind of gage how bad it is, but only once the wave reaches the shore is when you know how disruptive it will be.
I worked for a product based company where "chaos" was an understatement.
Because "Product" was where all the real work was done, and projects just had to take that robust framework and slap a project database on it and add project specific features, documentation was practically nonexistent, and what did exist was mostly unintelligible.
Whenever a product feature failed on a project, managed always responded with the mantra "we KNOW it works, because it works in product". It was a given that the problem was not product, but the incompetence of the project developers.
One project manager did an analysis, and showed that 85% of project issues were failures in the base product, with only 15% being project issues. Management still maintained that product was rock solid, well tested, and proven. There were even posters on the wall.
As one team member put it, "product is pretty much a cult at this point".
And then, there was... the event.
A catastrophic failure occurred at a customer site. The customer demanded an audit, which the company expected to pass trivially.
The auditor demanded to see the test cases mapped to requirements, and discovered that often, there was no written requirement because the product behaviour was "obvious". When the tester failed the "obvious" behaviour because it didn't work as expected, they'd be told "well, you're on the Berlin project, so the ABC is different than on Copenhagen, talk to the Berlin developer about that".
That auditor determined that testers were interviewing developers to determine how the system should work, which could change daily.
And so, the company was ordered to write requirements for their existing system. This was quite an eye opener for many in management, who assumed that of course, everything was documented with every i dotted and every t crossed.
The best line came from a junior developer at a town hall who was asked what he liked about the company. He said "you know, it's actually a lot easier to know if your function is working properly when you have requirements to test against". It was like a revelation to him. It was something new.
The last I heard, they were now in the seventh year of that six-month audit...
Spoiler Alert: Adding new features qualifies as "touching it" for the purposes of playing tech debt Jenga. 🤷♂️ If you're the one who stacked a new feature on top last, you have to clean up the mess at 03:30 a.m. Them's the rules. 😈
And what's why an incomprehensible polymorphic multi-delegate zetomorphic initiator flenser manifold function has 18 layers of wrappers around it, because no one wants to touch the original function.
I've had several code reviews where reviewers have tried to fail me because the existing code in the baseline wasn't even close to meeting the requirement.
It's even better when the dependency is a 16-bit binary that was last compiled back in the '90s. Nobody has the original source or even documentation for the core encryption algorithm and the original author(s) are unknown or deceased, so you're stuck with an incomprehensible, undocumented "support utility."
That happened during the audit I mentioned in the first message. In order to do black box testing, I had to rebuild the system from scratch, using the documented procedure, and then add some script tests for the audit.
I tried for three weeks. Two different architects looked at it, and said "we don't know what you're doing wrong; the BlipVert.dll is still rebuilding, so it must be your changes". As always, the default assumption was user error.
When three other developers then tried to build it from scratch, and had the same failure, they actually looked into it. After a day, the answer was determined to be that "Blipvert.dll was actually checked into source code control, and hasn't been rebuilt in seven years. It won't work with the version of the current compiler."
Fortunately, for me anyway, my position as auditor/validator meant I assumed that the system did not work, and it was the developer's obligation to prove it did. This was in stark contrast to management's assumption that by default, everything was rock solid and proven.
Well then, it'll be easy to prove, right?
I still remember the look on the CxOs faces when I presented a major systemic failure condition, because it was a condition that they bragged about handling better than the competition. They asked the architect how it got past his testing, only to have the architect shrug and say "well, no, I didn't actually confirm it's okay, but why wouldn't it be?".
Suddenly, they realized maybe they'd shouldn't have spent years dismissing the project teams screaming about all the problems, and maybe, just maybe, the architects' claims about the robustness of their "rock solid" product they were basing the company's success on should be given a little scrutiny.
Historians, too, it turns out, are doomed to repeat history as well.
Guess finding a similar silliness in every company/division that I've worked in over the past thirty-five years isn't just my bad luck (weirdness magnet) in action after all. 😅
This is a similar class of error to a director or VP looking shocked that nobody had "fixed" the code they wrote years/decades earlier in their career and the current disaster is actually, literally their fault.
Yeah, tech debt has a magnitude...
How bad is your technical debt… on the Richter scale? 😏
Maybe "tsunami intensity scales" is better measuring option, tech debt you kind of gage how bad it is, but only once the wave reaches the shore is when you know how disruptive it will be.
I understood the reference!
https://xkcd.com/2347/
I worked for a product based company where "chaos" was an understatement.
Because "Product" was where all the real work was done, and projects just had to take that robust framework and slap a project database on it and add project specific features, documentation was practically nonexistent, and what did exist was mostly unintelligible.
Whenever a product feature failed on a project, managed always responded with the mantra "we KNOW it works, because it works in product". It was a given that the problem was not product, but the incompetence of the project developers.
One project manager did an analysis, and showed that 85% of project issues were failures in the base product, with only 15% being project issues. Management still maintained that product was rock solid, well tested, and proven. There were even posters on the wall.
As one team member put it, "product is pretty much a cult at this point".
And then, there was... the event.
A catastrophic failure occurred at a customer site. The customer demanded an audit, which the company expected to pass trivially.
The auditor demanded to see the test cases mapped to requirements, and discovered that often, there was no written requirement because the product behaviour was "obvious". When the tester failed the "obvious" behaviour because it didn't work as expected, they'd be told "well, you're on the Berlin project, so the ABC is different than on Copenhagen, talk to the Berlin developer about that".
That auditor determined that testers were interviewing developers to determine how the system should work, which could change daily.
And so, the company was ordered to write requirements for their existing system. This was quite an eye opener for many in management, who assumed that of course, everything was documented with every i dotted and every t crossed.
The best line came from a junior developer at a town hall who was asked what he liked about the company. He said "you know, it's actually a lot easier to know if your function is working properly when you have requirements to test against". It was like a revelation to him. It was something new.
The last I heard, they were now in the seventh year of that six-month audit...
Spoiler Alert: Adding new features qualifies as "touching it" for the purposes of playing tech debt Jenga. 🤷♂️ If you're the one who stacked a new feature on top last, you have to clean up the mess at 03:30 a.m. Them's the rules. 😈
And what's why an incomprehensible polymorphic multi-delegate zetomorphic initiator flenser manifold function has 18 layers of wrappers around it, because no one wants to touch the original function.
I've had several code reviews where reviewers have tried to fail me because the existing code in the baseline wasn't even close to meeting the requirement.
It's even better when the dependency is a 16-bit binary that was last compiled back in the '90s. Nobody has the original source or even documentation for the core encryption algorithm and the original author(s) are unknown or deceased, so you're stuck with an incomprehensible, undocumented "support utility."
That happened during the audit I mentioned in the first message. In order to do black box testing, I had to rebuild the system from scratch, using the documented procedure, and then add some script tests for the audit.
I tried for three weeks. Two different architects looked at it, and said "we don't know what you're doing wrong; the BlipVert.dll is still rebuilding, so it must be your changes". As always, the default assumption was user error.
When three other developers then tried to build it from scratch, and had the same failure, they actually looked into it. After a day, the answer was determined to be that "Blipvert.dll was actually checked into source code control, and hasn't been rebuilt in seven years. It won't work with the version of the current compiler."
Fortunately, for me anyway, my position as auditor/validator meant I assumed that the system did not work, and it was the developer's obligation to prove it did. This was in stark contrast to management's assumption that by default, everything was rock solid and proven.
Well then, it'll be easy to prove, right?
I still remember the look on the CxOs faces when I presented a major systemic failure condition, because it was a condition that they bragged about handling better than the competition. They asked the architect how it got past his testing, only to have the architect shrug and say "well, no, I didn't actually confirm it's okay, but why wouldn't it be?".
Suddenly, they realized maybe they'd shouldn't have spent years dismissing the project teams screaming about all the problems, and maybe, just maybe, the architects' claims about the robustness of their "rock solid" product they were basing the company's success on should be given a little scrutiny.
Historians, too, it turns out, are doomed to repeat history as well.
Guess finding a similar silliness in every company/division that I've worked in over the past thirty-five years isn't just my bad luck (weirdness magnet) in action after all. 😅
This is a similar class of error to a director or VP looking shocked that nobody had "fixed" the code they wrote years/decades earlier in their career and the current disaster is actually, literally their fault.
I've had that happen. I still have the (completely undocumented) code.
Here's a typical code fragment:
switch(tecsrch(*(TEC**)(id[*f].ttype),id[*f].var,&s,s=3D=3Dstr?(*str?str:=
"[a-z]"):NULL,func1=3D=3DF02?1:0)){
case -1 :
s=3D(*id[*f].tecfnc)(*(TEC**)(id[*f].ttype),id[*f].var);
if(*s)
...
That was part of a 2,300 line function. The director had written it a decade earlier.
When he was visiting our offices, the maintenance coders who'd been struggling with it for weeks grabbed him and made him explain his own code.
He looked at it for half an hour, and said "I'm not sure what it's doing, exactly, but it seems rather clever, you must admit".
Yes, he couldn't explain it, but he was impressed by it.
The company was bought out not long after, and the buyer used their code base, not the one they'd purchased.