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, "project 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."
Yeah, tech debt has a magnitude...
How bad is your technical debt… on the Richter scale? 😏
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, "project 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."