The Hidden Cost Of Speed 

BRUH

Damn, beat me too it! 🤣🤣🤣 Flip, you are Legend. Never stop being you.

Hahahaha this made me laugh so much!

it aint much but its honest work🙏

8:43

that was real footage btw

This is a different problem. Of course managers don't get, that a car with no engine is not just one quick fix away from winning a Grand Prix. But in my opinion the problem discussed in the article is that project requirements often start with describing a single-seater that can corner well. And end up with wanting a bulletproof SUV with designer cup holders. So if you go fast and deliver features quickly at the start, you're likely to lock yourself into a path that's not compatible with changes in requirements. While if more attention is given to first actually develop the product and also to write more generic future proof code, you could potentially get more done by going slow.

I do think this isa problem that is smaller in real life than you make it look though. The issue with inputting wrong characters should be handled by your forms library or at least by a standardised component that is ready to be used. Are you telling me you rewrite all that code for every input field? Adding a simple feature that uses standard components that are already in use (extra fields etc) really should be a 10 min job. The whole idea of an architecture is to make jobs like these easy.

​@@garma7939Right just recycle a pre-existing standard forms library with zero research when rapidly prototyping a novel app that might be relying on a novel framework that might have entirely different escape characters and code injection vulnerabilities. That's definitely gonna allow a prototype to be shipped straight to production ready. Yes, I'm being sarcastic.

@@KucheKlizma that's not what I said. I said reuse what you already have in production. You SHOULD have a forms library in production that already takes care of those issues.

That’s deep, actually.

'Nothing is so permanent as a temporary government program. (c) Milton Friedman

The entire point of the video is that this is not true.

@@anonymousperson7536 What company you work at?

@@Leonard0F41G he's unemployed most likely

Early in my career, when I was too young and naive to know any better, I got myself into this exact situation. I learned a lot from that.

The critical flaw is not asking how they will use it. You don't present a bunch of ways something can be used. You ASK questions, you have to actively seek information when you do requirements gathering. You can't expect your end users to understand what you're going to code well enough to know what they need to tell you, so you have to ASK. You shouldn't even have a demo of anything at all until you've asked stakeholders about what they want, the use cases for it, and plans for the future. These are very basic things that would take AT MOST an hour to hash out. You can't skip requirements gathering. Trying to work on solving a problem you do not understand is a rookie move.

I remember working on a legacy desktop application asking why things were done a certain way, and I was told that the application was originally a demo that was pitched and won a contract. Apparently after the demo they were going to rewrite it correctly but the customer said something along the lines of "I don't understand, I don't want it redone. I want what you just showed me and I want it now" so their hands were tied

@@adammiller9029 Yes, a rookie move my company makes all the time.

@@mangalegends it's on the sales guy to explain that to the customer if they can't your sales team sucks.

got you my man🙏

like this. I always try to leave a piece of code less messy than I found it. If I’m already spending time understanding what it does, I might as well write a comment about the confusing bits, so it’s easier the next time I look at it. If I’m already going to have to restructure it to add a feature, might as well try to simplify and improve the structure a little bit. I cannot write super well structured code the first time around, but I continuously try to make things a bit nicer than I found them and overall I find most of my codebase pretty easy and pleasant to work with, and I feel like it’s the most practical approach for managing messiness and complications in code for me.

Agreed I think it's a really healthy way to view tech debt since, as Prime mentioned, all code has tech debt. You never really get out of it but you can make the best of it and learn to prioritize and constantly make small improvements. And I enjoyed that Kevlin Henney talk as well. He has a nice way of focusing on how we speak as developers.

"Uncle" Bob Martin makes this point as well: your codebase becomes an unmanageable mess because you never took the time to tidy it up as you went along. Treat it like a mechanic's workshop and you'll always know how to get started on the next job.

Isn’t that the principle behind LEAN?

Them experiencing it doesn't inherently mean they got the right takeaway. But there could very easily be something left out of the narrative that made that a good takeaway. I'm most reminded of that "we migrated with prisma. never use prisma" and 80% of the things they said were serious issues with what they were trying to do and not with prisma, and the last 20% was something people sometimes complain about but nobody has yet actually demonstrated was a problem

appreciate you brotha💪

8:58

When they cut your time, you ask them what features to cut / make a priority list so you can get as many important features done in the timeframe as possible. (there's diplomatic ways to phrase this) It is true though, that sometimes people don't give you a choice and just "force" you to fail a deadline and then make you responsible for a deadline you didn't even commit to. In this case, you should leave the company rather than work for free.

I left a company exactly because a CEO did this. Unfortunately the one with the purse strings makes the decisions

I mean there is always abusive employers, but usually at least, managers will actually listen. If they don't they are shitty managers. At that point the best thing to do is probably to just leave once you can.

If he has a team ready to do it in 1 week, call his bluff and come back in 1week when nothing works and say now it'll be 4 weeks

​@@StefanErwinBaumerdon't forget: DOCUMENT the deadlines you gave vs. what your manager gave the customers. It doesn't help too much if the entire company is fucked, but at least you can prove that it's not your fault.

That last part is especially true. Sometimes management can be so disconnected from reality that any disagreement is treated as heresy. If something isn't deliverable, it's your fault rather then their unrealistic expectations.

You have to learn this at some point or you’ll be walked on your entire life

​@@olbluelipsYou have to have the right personality type that can get away with it, otherwise you run the risk of coming off as a a**hole or a b**ch. I've had much better success being fluent in "soft" business language and having an "Aw, Shucks" CYOA policy.

Bro!!!!!!! 😂😂😂😂😂😂😂😂😂😂😂😂😂😂

Inducing Scope Creep, Technical Debt, Poor Resource Allocation, and Reputational Risks 101

@@DeveloperToast I'm not sure what you mean by this.

@@kyguypihe’s probably saying to make it good or just don’t make it at all otherwise you risk the following list he commented

@@UniversityOfMassachusets but... Y'all know you can edit code after it's written, right? You can rewrite something. In the real world, there are business pressures that sometimes require that you have to get something together right now and then clean it up later. Technical debt doesn't matter if you're unwilling to meet business needs. If you're that afraid of technical debt, you can avoid it entirely by never writing code. In the real world, I write things fast to meet real world deadlines, and tell my CEO that I will need time later to clean it up. That's way better for him then me refusing to meet the real deadline and making the business suffer for it, and then I actually take that time to rewrite the thing, which turns out way better anyway because writing code twice actually tends to produce good code.

Yeah then if you get asked to add stuff onto it you can just say something like “I’ll add that but the first solution was kinda duct taped together because you needed it really quickly, so I’ll have to spend some time fixing that before I do any add ons”.

I'm posting from an anonymous account, and you don't have to take my word for it, but I feel compelled to share my perspective. Its a long story that could have been a blog post. I'm not regretting anything though, and you've been made aware of the nature of my comment. I’ve been in software engineering for over 16 years, and there’s no platform or problem I can’t tackle-whether it’s working with embedded systems at a register level or building no-code solutions. The only real constraint I face is time. In my role as a senior software engineer, I regularly collaborate with cross-functional teams and deal with quality assurance. One recurring issue I encounter is technical debt. In my experience, both in professional environments and open-source projects, most technical debt stems from poor design decisions-specifically, action-at-a-distance problems. Blindspots of their own design. It’s not the code itself that typically causes tech debt; it’s the underlying architecture that wasn’t designed to accommodate future changes. If you build a framework without prototyping and testing it against the right criteria from the start, you’re setting yourself up for failure. Inadequate testing practices, especially the notion that tests can be an afterthought, exacerbate this issue. One example that comes to mind is to use a third party service immediately to solve a infrastructure or functional requirement, without actually testing the system first yourself against your own criteria. This disconnect between coding and maintainability (testing or refactoring) is where most developers fall short. When technical debt eventually catches up, teams go into maintenance mode, trying to patch things up by retroactively adding tests to stabilize the system. Especially if you didn't test the external services, that's when you first learn if the instabilities of such services. The real issue is that the infrastructure was never designed for self-testing. A solid engineering approach would involve building the system in a way that prevents action-at-a-distance issues from arising in the first place. Testing shouldn’t be an afterthought; it should be integrated from the beginning. Of course, if you cannot explain to your bosses why this is needed, nobody is going to pay for it. Therefore, you must already know this needs to be done, and communicate it, or all testing will automatically be an afterthought. You're being sabotaged by the very people you work for, by YOUR own design. Engineers push back when the evidence shows a choice is bad. The moment your bosses give the green signal regardless, you're absolved of any responsibility of it going wrong. But if you don't communicate, you're still responsible by proxy of your role. A developer who does not communicate, cannot really provide a stable product because you don't have the resources to do it. It requires explanations. The difference between a software engineer and a developer often boils down to understanding and applying engineering principles. Engineering involves anticipating blind spots in your design and addressing them early on. Many who call themselves "engineers" are really developers stuck in a cycle of managing tech debt because they don’t apply these principles effectively (as a team if its a team effort). Having a large amount of tech debt is often a symptom of two things: either the organization fails to define criteria properly, or individuals are too confident in their abilities and overlook the importance of engineering practices. From my experience, most developers fall into the latter category-they’re good at coding, but they don’t understand the engineering discipline needed to prevent problems before they occur. A key way to distinguish a true engineer from a developer is by how they explain their code. Engineers will tie their explanations back to core principles, showing how they’ve accounted for potential issues like action-at-a-distance. Their explanations bring clarity to even the most complex problems because they've done the hard work of analyzing and understanding the underlying system. Developers, on the other hand, often can't articulate these connections and see tech debt as an inevitable part of software development-when in reality, it’s often a sign of poor engineering. As a software engineer, thanks to developers I'll have infinite work. Software engineers actually help finish the job in a sustainable (works for 10+ years) way. If you're working on a project that is already in maintenance mode after 2 years, that's a big big red flag of a dysfunctional company. Its perfect, all the dysfunction gives me significant more time and resources to apply engineering in. After all, engineers can solve problems developers can't. That is what makes an engineer an engineer. If you can't solve ANY software problem as an engineer, you're not an engineer. Note that I'm not saying anything about the time it takes. Some problems take decades to solve, even as an engineer. But you can solve them. If you cannot tell yourself that you can solve a problem you know NOTHING of within let's say, 25 theoretical years, you're not engineer. That's my metric for it. In that timeframe, you can either proof some parts cannot be solved, or approaches can be formulated to mitigate the potential action at a distances. So what do people do who cannot apply engineering principles: They say: "Oh no, our tech debt is now so large, we can no longer properly maintain the existing features! You know what, this will cost us too much! Let's re-develop the same product, only to end up in the same scenario, many years later! Lets not at all learn from our prior mistakes!" And such, the cycle of a new major version of a product every year has come to existence. Good for fooling customers who don't even know what they're working with, horrible for business health. You're essentially: "My prices need to be high, so I can afford doing the wrong thing over and over, and not learn from it. So instead of actually improving, we'll tell everyone we've a high quality brand and up the prices of our products." I'm telling you.. at some point, marketing is the coverup of failure.

I get that we "shouldn't" get permission, but in my case it was enforced by the... very functional... reviewer/senior in charge saying it costs too much time and money. We couldn't do it unless it was a task.

I go back n forth on this, because working in such codebase, actually trained me to be more mindful of how I make a change and also gave me confidence in my ability to reason about code, that you don't get when every single line change goes through 3000 tests and 7 step review process. On the other hand, every now and then I change 300 lines of code at once and have no idea if everything is still going to work the day after.

@@JanVerny its exacly this, cool thing to be mindfull of every piece of code, but when i migrate data/functionality, things breaks maybe 2 weeks on the line because you didnt consider a small functionality that you didnt know it even existes

Skill issue, really.

Not the same thing. If you sucked at design that would imply that you will never get it correct. Or at best you'll get it correct by an accident. Meanwhile acknowledging that design is a difficult problem just means that people should be given more time to do it.

Searches git for #cbt

Yeah, I work on internal tooling and as you say. It's a horror. I learned to overestimate a lot and spend the time trying to improve whatever I know management wouldn't approve me to work on.

Impossible, I would have to be a CEO already. :D

But it's still horrible tool and people are stuck with usesless product. I think devs are just full of themselves

I get what you mean. To me it feels like a puzzle when stuff gets ordered piece by piece and then there are moments when a few parts are decoupled enough to delete a big chunky piece it's like having a big block in tetris disappear, it's so satisfying.

you don't need to use all the principles to be OOP, encapsulation is often enough

I literally have evidence where my type system "saved" my ass, lol