211–220 of 331 posts
- opportunity cost for the product since you aren't fast enough to chase new revenue channels, this cost is almost invisible,
- the product can become plainly unable to run on newer platforms because of debt,
- unpleasantness of the codebase that will lead to loosing engineers.
It's a slow and excruciating process.
I think implementations are more often killed by technical debt rather than products or brands tbh. Although at that point I wouldn't call it technical debt. If you've a million lines of spaghetti code, then you've a million lines of spaghetti code not technical debt. I.e. a camel is a camel. It's not a horse with technical debt.
Nice line though, made me smile.
Earlier quoted context omitted.
"They did it that way because they where stupid" is a ridiculously common assumption, when the correct answer is often "They did it that way because they knew stuff I don't know".
There's obviously a lot of stuff I don't know then. Like the benefits of copy pasted code, or 300 column lines, or implementing the logic in 20 places when it has existed in the standard library for a decade. If only the ancient sage I inherited this code base from had left notes to guide me on this path of wisdom.
Earlier quoted context omitted.
Some of the worst examples of that are when a project uses a custom build of a library of which the source no longer exists and no record of the changes exists either.
Builds that involve non-version-controlled files that exist only on a certain developer's machine, and because that developer is a control freak (or overworked), he refuses to automate or put those files in version control...
Earlier quoted context omitted.
There's obviously a lot of stuff I don't know then. Like the benefits of copy pasted code, or 300 column lines, or implementing the logic in 20 places when it has existed in the standard library for a decade. If only the ancient sage I inherited this code base from had left notes to guide me on this path of wisdom.
See, taking a reasonable generalization and interpreting it as an absolute statement is a classic case of "assuming they're stupid".
Earlier quoted context omitted.
I worked for a company that grew considerably for 10 years and then lost its biggest client and folded quickly. We had spent a few years reworking our platform in a way that might have been successful enough to weather the storm of losing that client, but technical debt really slowed us down. Technical debt may not have killed the company directly, but we have to wonder how we might have done if we could have spent m…
This is revenue diversification not technical debt. Companies with a single customer funding the business should be actively pursuing a high priority strategy to reduce this risk.
Earlier quoted context omitted.
Seen this a lot. A lot of companies think they are "product" companies, but due to their unwillingness to push back on customers, they become custom engineering shops, bolting on little one-off mods to their project over and over to appease bad customers (or to appease POTENTIAL customers who haven't even bought the product yet). Stop me when you recognize this one: "Hey your product is great, but we really want some…
"Let us use our logo" doesn't seem like an unreasonable request.
That was part of the problem: the sales people couldn't push back on most requests because they were often quite reasonable. When they were more demanding, it was usually from a large prospective buyer so we had to bend over backwards.
The result was that we had huge tasks to do with no (current) revenue, and small tasks to do that took 10x as long as they should have. Since servicing existing revenue streams (even on reasonable requests) became so time-consuming, handling big enterprise demands became totally untenable.
I worked on an EDA product for a short time. Its code base had a few components, some of which were written by the product team, and some of which were copied (without source history) from other teams. The team decided to make a cloud version of the product too, and to do that, the team split in half and each new team had their own copy of the code base.
No sharing code, because those other teams were our competition. There were teams working on components for our product, and another team working on a copy of our product, but nobody shared code. So bugfixes from one of the components would never make it into our code base. (The components were products in their own right.)
The code base was ~30 years old, and it had "survived" a port from Unix to Windows. The build system was a hellish nightmare of Cygwin, makefiles, Perl scripts, hard-coded paths, and unsupported internal tools, and after ~2 hours of manual fiddling it spat out a build. A few million lines of code, which according to my tests, would take ~10 minutes to build with a proper build system. I have a proper rant about the horrors I saw in the build system, I had never imagined that a build system could be so bad, and whenever I mentioned the name of the internal tool it was built on, company veterans on other teams would recoil.
Meanwhile, I witnessed how much damage the other developers were doing to the product. Some were trying to catch up with feature requests, some were adding hacks to the core algorithm to try and improve numerical stability, and some were doing real damage to the code base by adding buggy and poorly designed features--think major performance regressions, memory errors, and deadlocks fixed by adding calls to Sleep().
I tried to improve things as much as I could there. The company culture had some upsides (good work/life balance) but the internal competition strangled innovation, the wrong people made technical decisions, and the team didn't have a balanced set of skills.
The product hasn't been "killed" per se. It's still for sale. But it's the walking dead. Being EDA, licenses can run into five figures per seat, but the product's revenue was on a downward trend last time I checked. I have a couple friends that still work on the team but I'm encouraging them to apply for new jobs. I left when I got an offer from a major (big five) tech company.
Earlier quoted context omitted.
"Let us use our logo" doesn't seem like an unreasonable request.
thats one line of code on some part of some html template if done in a non-idiotic fashion (speaking to the javascript overcomplicators)
And it was one line of code, after several hundred lines had been torn out and rearranged to ensure that different clients could insert their own pictures of different sizes without everything exploding. The whole team was desperately trying to force enough flexibility into the software that one-line changes could be made in 100.
Earlier quoted context omitted.
If I had to guess, I'd say it's probably an issue with the build/deploy system. Perhaps someone deployed a broken build, then tried to revert/rollback, and realized that the previous version didn't build "cleanly" anymore. This could happen if you have a lot of dependencies, switched compiler versions but left the binaries "in place" and deployed changes incrementally.
Yet another reason I swear by Heroku - you can rollback to the actual prior release, not rollback the code and try to rebuild.