Once you get to the point of something working, the business is going to move on ahead without giving your team any time to go back to refine and improve.
Bug fixes will be given some time but telling management/business, we need 2 months to go and clean up everything we've built over the last 6 since we now have an idea of how to structure this capability is gonna be met with a laugh and a no.
Inevitably something will break or a new feature will not be possible cause of existing limitations and everyone will get mad since no one told them something could break without an improvement even though you told them well beforehand that the ground was shaky.
I think companies not prone to this are ones where their product is a technical one like cloud services where the business really is the engineering and engineering isn't a means to an end.
Personally it feels like modern management and organizational practices have prioritized feature velocity over a lot of other concerns. Business likes this because they can come in, request X number of features and then everyone works like hell to get those features in
Then, seeing the speed with which those first X features got implemented, they now request Y features and the cycle repeats.
But constantly measuring feature/release velocity means that things that do not directly benefit new features/releases get de-emphasized, such as encouraging developers to not just implement a feature, but go back to their code and try to disentangle the code they just wrote from any other code they may have stepped on. And it's even harder to get the business to agree to not push out features but instead give time to just go back, look and what's there, and figure out how to make it possible to add the next Y amount of features
There's something intoxicating about being able to have a bunch of teams pushing out new updates, but these high velocities can make it near impossible to revisit something. Hell, I've gone back to code bases on projects I haven't touched in only a few months to suddenly find everything has become riddled with spaghetti code and weird hacks to bypass systems. It works, but each release starts developing longer and longer bug fixing time
In my experience one way this manifests is how every new project you'll get PM and management rushing you to use some dead simple user authentication so you do then 6-8 months later they're asking you to add RBAC to all the features you've had nothing like that planned for. Like it's the most obvious eventuality with any of these apps sold B2B and it's always put off and fucks up any architectures and forces various "pivots" because management couldn't be bothered to listen and prioritize foundational stuff.
Management practices are bad because managers/directors/VPs are not the first to be fired.
In a scenario where the management would be the first to be fired for non-delivery of features, management would go to extreme lengths to improve developer environments, tech debt, and in keeping people happy and for longer duration.
100% this. Velocity above all else, in conjunction with the bad practices around treating product as the source of truth pretty much always, and pushing back on technically infeasible (for the time frame, usually) is a no go.
I know as engineers we have some salary privilege, but few groups get squeezed as hard by both sides of the business layers as engineers do, in my experience.
> Personally it feels like modern management and organizational practices have prioritized feature velocity over a lot of other concerns.
I agree. In the defense of business, our industry typically does a horrible job explaining concerns other than features. This isn't going to change things across the board, but I think a meaningful percentage of businesses will make better decisions with more mature presentations.
Here’s what I do: once I’ve gotten something working, I don’t put up the PR immediately. I let it sit for a day, then I look at it the next morning with fresh eyes. Inevitably, I find things to clean up, improve, and refactor.
Maybe you’re talking about getting something “working” in the larger sense, as in a full feature, made up of lots of PRs, but slowing things down just a little bit and focusing on quality in each individual PR is much easier to budget for (no one notices the extra half day) and buys you a lot of quality in the long run.
In practice it isn't even that much more likely to break, or even add features to. The code is just much uglier and more complex than it could be, and probably slower. But it runs and keeps running.
Most of the time those business types are correct on this.
The only thing is that once the original team has moved on, then if the code is too complex, it can become almost impossible to change.
It's a hard balance to strike. On one hand, the code is ugly and difficult to understand, but it has that ugliness for a reason, it's solving edge cases that you don't remember and a rip and replace is always expensive and no guarantee it won't devolve just as quickly.
How do you strike the balance of the dev team wanting to fix unbroken code for long term health, and investing in new features that grow the business.
Personally, I am biased towards encapsulation as a means to handle a lot of these types of tech debt. Wrap the old stuff in an orchestration layer and build new features with the orchestration layer in the middle. It's a bit of sweeping the dirt under a rug, but it also gives you a real solid base for later coming back and cleaning up the ugliness if it's really needed by giving solid contracts between the consumers and the orchestration layer and the legacy system and the orchestration layer.
> we need 2 months to go and clean up everything we've built over the last 6 since we now have an idea of how to structure this capability is gonna be met with a laugh and a no.
How do we break this mold? While this absolutely does happen with some management, it's not all management in my experience.
I am an engineer that's found myself in a management role, and I want my team to do exactly this--don't invest tons of up-front effort trying to guess the models and abstractions we're gonna need. Build, iterate, and we'll clean it up when we know what we don't know right now.
It is blatantly obvious to me that things will be on shaky ground, I have a keen sense of what will break and when. And I'm totally good with that! I put "architect for real" time into the roadmap.
But even still, I get pushback, sometimes a lot of it. Like the idea of shipping functional-but-ugly code is somehow totally unacceptable for some reason (even when it's obvious the "pretty" version isn't even future-proofed or appreciably better). And the excuse is usually "Well we'll never have time to fix it".
In a 20+ year career so far, I've never seen a company break the mold. At best, the company will pay lip service to software quality, but reality is that everyone up the food chain is incentivized to run as fast as they can cramming features. At worst, quality will be deliberately shunned: "Get it to barely work to the point where the customer won't outright reject it, and then ship it!"
If there is any company out there that still encourages and rewards the craftsmanship and attention to quality/detail that is embodied in that old Steve Jobs quote[1] I haven't found that company yet.
1: “When you’re a carpenter making a beautiful chest of drawers, you’re not going to use a piece of plywood on the back, even though it faces the wall and nobody will ever see it. You’ll know it’s there, so you’re going to use a beautiful piece of wood on the back. For you to sleep well at night, the aesthetic, the quality, has to be carried all the way through.”
I was going to point out that , sadly it’s not just software companies that are run like that. Honestly I wouldn’t know who to point the finger at, consumers crave “features”(be it software or hardware ones) because companies have been pushing them as the Nr1 selling point.
> Like the idea of shipping functional-but-ugly code is somehow totally unacceptable for some reason (even when it's obvious the "pretty" version isn't even future-proofed or appreciably better). And the excuse is usually "Well we'll never have time to fix it".
You are thinking of it from your team's perspective. We have some shipping code, we just need to clean it up and architect it properly to do the exact same thing! Sounds reasonable, right?
Now think about it from the point of view of the customer that's paying you money for the feature. Do you think they would want a feature that has "architect for real" in the roadmap after they pay you money for it? Would you pay money for such software? [Yes, they don't need to know, but think about what if they did.]
How this actually plays out in the real world is that customers pay money based on a somewhat vague promise of features in the future. If your "architect for real" delays the launch of those features (as it likely will, these 'simple refactors' have a habit of becoming not-so-simple), then it's bad look. So customer-focused teams try to get it right the first time and deliver a cohesive, architected feature.
I did say "try" above. Like all real software, it's impossible to be perfect. But "we'll do it for real afterwards" attitudes like yours often tend to produce friction, and this is my attempt to explain why.
Tech debt means the next is feature 5% more expensive... compounding.
I'm now on a project that has spent 2 months (10 people months) to add a box to the checkout screen for the cashier to enter a special discount amount. No business logic, straight pass through. Originally, I thought it could be done in a week by one person: nope. Once you get in the weeds, it takes this.
This is now 4000% more expensive (literally, do the math) because of compound interest. Tell me that isn't valuable to the customer.
If that were the only reason tech debt were bad, I wouldn't worry about it so much. But I'd estimate at least 25% of the bugs in our software come about because of existing tech-debt - developers make reasonable assumptions about how things work when implementing new features (or fixing other bugs), but because of hidden tech debt, those assumptions end up not being true in significant corner cases. A classic example is when code is originally written for a very specific purpose, then later gets "somewhat" generalised in order to support a wider-range of cases - but lots of the original code that only made sense for the initial implementation is left in place, instead of properly separating out the "specific-case" code and the shared logic. Years later devs (not involved in the original development) reasonably assume it's intended to act as a general purpose component and use it as such, only to find it starts misbehaving because it was never properly refactored from its original implementation.
I feel like way too many people here haven't exactly experienced a long term project. Spending extra 20% now to get it right always pays off on anything longer than say a year or two. Even spending 50% or 100% sometimes does.
In my experience it tends to work like this. New feature is added. Client tests it and it works great. Client has a few more subrequests to make the feature excellent for them that take a month or two to implement. In the meantime huge amounts of data are building up in the database. The even newer features get implemented and suddenly the customer system explodes in a ball of fire. Turns out they are taking those new features and doing things you never expected with other existing features and now your system isn't performant enough. Now the entire process of adding new features for other clients has stopped as 'redneck architect' the system to a point it doesn't fall over, all while the customer is pissed.
> Now think about it from the point of view of the customer that's paying you money for the feature. Do you think they would want a feature that has "architect for real" in the roadmap after they pay you money for it? Would you pay money for such software? [Yes, they don't need to know, but think about what if they did.]
At least I am this kind of person. :-) I also believe that on HN, you would find some people who are also of this kind of breed.
The problem rather is that many customers do not value this.
TBH it really depends on the industry and the nature of the product. Like, even within the same industry consider Video Game A vs. B
A) you are making some single player narrative adventure. You don't expect many post launch updates and no DLC plans. You don't really care if the code is spaghetti as long as the core features work: maybe in a potential follow up you clean up a little bit, but not much. The art assets are the biggest factor for reuse.
This sounds like the kind of product you work with and while it hurts on an engineering level, I can understand the need to focus more on getting something out than "doing it the right way".
But you always have to keep in mind as a company that employees look out for their best interests, too (especially in thei current market). Some employees are fine providing a product, but others may have other aspirations. They may have eyes on another role and saying that they were essentially a scripter isn't good for their velocity. Being able to describe an elegant system they architected and how they improved the performance of a product will be what gets them through their career.
B) you are making some multi-player, networked arena battler. You have 2+ years of battle-passes and quarterly character roster/weapon updates. You want to be flexible to provide new modes of battle based on player feedback and be able to quickly rebalance battle systems to ensure nothing ever feels too over/underpowered. Fast iteration times post-launch are a must to properly address this timeline
This is where those suggestions from engineering should provide more pause. If you need to move quick 6+ months down the line, maybe those 2 months of re-factoring is worth looking into. Granted, this isn't at all how real multiplayer modern video games work (just throw it all at QA, it's fine), but there should be more discipline in how the code is organized and documented. Especially if you potentially need to hire new talent to ramp up post launch.
Perhaps you're a testament to why we actually want "managers who are also engineers" in these roles - for exactly cases like these, where you have the experience to know what "done" means.
I had a sobering realization the other day. Of all the companies that I have worked for over the years, the ones that had really solid engineering practices, the kind that made me proud, didn't make any money.
That doesn't mean that it's a general rule as I am sure there are plenty of exceptions, but it was still striking. In fact, I think I can say that the places that I have worked that were the most profitable were the ones where everybody agreed that the code base was an absolute mess.
Successful businesses can paper over bad code with money, because ultimately bad code just costs the business money.
A better way of thinking about this, I think, is that code quality expresses itself first and foremost in the product's long-term quality. And code quality, like all product quality, costs money.
But not all companies need good quality. Each business niche has a different quality level : product cost niche. A business will do best if the engineering quality matches the business needs, and vice versa.
A company that has spent money writing beautiful code that costs more to support than that business can generate, is in just as bad a place as a business that is growing massively and burning cash papering over a low-quality engineering department with all their new sales contract money.
Good code is basically investment in future velocity of the project.
And vice versa. But while "take a loan to get first version out of the door" is widely understood to be generally good decision, "invest into code so it can pay dividends later" appears to be some dark incantation nobody seems to understand...
Your table says code does not matter, but it does for consumer software. That's why Friendster failed and Google succeeded. Figma was made possible by WebAssembly. A lot of businesses had no "business" at the beginning; just a good product (and the code is part of that).
A quantitative way to say that is that rightsizing¹ your quality for your requirements maximizes the chances of success.
But code quality is much more flexible than business quality, so that large changes on code still have a smaller impact on success. What absolutely doesn't mean that code is irrelevant; it just means that marketing in incredibly important.
1 - What is a different word from "maximizing" for a reason.
Bad code can lose customers and eventually fail the business. I've seen it. The code was for paying customers and once the system was buggy enough, they left. All driven by clueless agressive management who read too many blogs about MVP etc.
How about "the companies with a very profitable business can afford to have a mess" and so they continue to have a mess because they are already surviving.
I understand where you are coming from, but I disagree with this. It is the engineering team that says whether or not something is "done", and if there is tech debt that must be addressed before a feature can be implemented, then it needs to be done as part of that feature.
In majority of the cases I have encountered the tech debt is optional to address, the risks around them have varying implications depending on the case and there is no blanket decision to cover them. In most of these cases, it is simply a matter of explaining the business people the risks of taking shortcuts. In the end not every tech debt needs to be paid immediately, and not every tech debt is bad. If the tech debt allows you to make money today instead of 2 months from now, you might very well take the debt and think about it later if what you need is money.
I'd recommend talking to business people and making sure they understand the risks of these decisions, then they will be more in favor of addressing them, in some cases even more than you would do yourself.
Couple of things I've done. One is build refactoring into the estimate for the improvements, especially since if you did take two months to refactor and then added improvements, you might have to refactor yet again.
Another thing I do is reserve X% of sprint stories for maintenance work such as refactoring so some improvements do get made. I don't think you ever fully pay down tech debt, you just have to do as much as you can given other constraints.
> I think companies not prone to this are ones where their product is a technical one like cloud services where the business really is the engineering and engineering isn't a means to an end.
I currently work for a company providing "cloud services" to other software shops. Part of what drew me here was that the ethos around how we get stuff done does encapsulate this. The engineering culture is pervasive. Here's to hoping we can maintain that as we grow.
This is an hypothesis, so take what I'm saying with a lot of salt, not just a grain.
I've been exploring a tool in ruby called packwerk, that helps introducing gradual boundaries within a system (made by shopify).
The beauty is that while you can see violations you can still run your code.
Now, my thought process is that identify the core high level boundaries is very important to design a system, so this type of tooling will go a long way.
So far to enforce boundaries you either have nothing, which leads to a design that's just a mess, or you have something strong like go packages, which can slow you down.
Design is super valuable, but there are just parts of the software that have little enough business value or will never be touched again, so nobody cares.
I think design being adjusted to business and team needs make sense, but we might not have explored hoe to do it. Also, I noticed it's not something every software developer is good at, which means not everybody can do it
Even worse is when a product gets mature and a team IS given a blank slate to do a rewrite, but the company insists on repeating design mistakes despite being specifically apprised of them and how they cripple the product... simply because they fear "change."
This happens at tech-centric companies that sell software. The biggest, in fact. It's depressing.
They should laugh and tell you no. Interrogate why they need 2 additional months to build it the right way. Why didn't they build it the right way to begin with, adjusting approach at every step?
In my experience, engineers (I am one too) tend to reach for quick and easy more than correct and hard, and that choice is coming from them, not the business.
I just had a ticket that was supposed to take 2 hours but took 6. A process that was created 2 contractors ago was unknown to anyone and I had to figure it out from scratch. My PM complained that I didn't complete in the time estimated and that some of these hours couldn't be billed.
If that's the situation, why would anyone explore the "right way to begin with" instead of what's quickest? The right way is the way the business accounts for, not what creates the best quality product and experience. Story as old as time.
"Supposed to take 2 hours"... Who said it should take 2 hours? And an estimate is not a promise. You did the right thing. Sounds like your PM is terrible.
> In my experience, engineers (I am one too) tend to reach for quick and easy more than correct and hard, and that choice is coming from them, not the business
In my experience, devs do this because they're required to meet a deadline that is shorter than it should be.
Even if they get a say in the timeline they might botch their initial estimate. I might guess 2 months to build this thing for which I have barely even had a chance to look at, let alone design, because I'm still trying to finish up my last project and then when I get into it and find a cluster bomb waiting for me they're already planning my next quarter. Or some things need to be rushed because they're holding up 5 other projects
It is true, the art of building complex products is to avoid shutting any doors by choosing short cuts or acquiring tech debt that can't be paid. If there are features that can't be implemented because of limitations, it's probably already too late.
>In my experience, engineers (I am one too) tend to reach for quick and easy more than correct and hard, and that choice is coming from them, not the business.
you get what you pay for. I tend to suggest the easy and "correct" way on any given feature with estimates for each. My lead will 99% go for easy. Don't know who up the chain is at fault, but that is clearly the preference.
>It's their job to stand by the truth of the work. If management can't deal with that, I'd be looking for my next place to work.
pretty easy way to end up jumping jobs every 2-3 years. I haven't found that "good management" yet, 6 years and 3 jobs later. It may not even exist in my industry.
The consulting, it is either done the first time, or it isn't.
There isn't anyone taking care of the code like a tiny bonsai tree, unless there is a consulting contract to do exactly that.
One thing I learned moving from product development to consulting, is that developers that are too deep into engineering organizations usually don't realize how much money per hour they burn doing beautiful coding.
When each hour of coding has a price tag to it, one realizes there is a certain need to map how that value turns into the expected ROI from business side.
Which for the majority of companies whose software isn't their main business, rather a means to an end, e.g. sell shoes, the value of perfect code how it is preached at conferences isn't exactly what will help to sell more shoes.
> One thing I learned moving from product development to consulting, is that developers that are too deep into engineering organizations usually don't realize how much money per hour they burn doing beautiful coding
Did you also learn that not doing enough is just going to cost next person touching the code, compounding on eachother till someone has to rewrite it?
There is a certain level of engineering where it's obviously code wankery with no actual profit but it is not close to "first, easiest to code answer to a problem that developer can make".
Spending 100% or 200% extra on designing and coding something is probably not worth it most of the time, but spending 20% over minimum is near always worth it.
Sure if your project takes 6 months and you then throw it away, fair enough, but for anything that has ongoing maintenance and development I've seen waaay to many projects falling into MVP trap.
Lets put it this way, there are consulting gigs where people get paid by the ticket, and they get a fixed hour budget for example 3 tickets, and move into the next customer after they are done.
Naturally when customers are willing to pay for quality time, the approach is different.
> Once you get to the point of something working, the business is going to move on ahead without giving your team any time to go back to refine and improve.
Just recently on HN: 'Software engineers hate code'[0]
It does seem once every modular part of your system works, it's enshrined as a microservice and forgotten about. Tech debt happens this way.
> Bug fixes will be given some time but telling management/business, we need 2 months to go and clean up everything we've built over the last 6 since we now have an idea of how to structure this capability is gonna be met with a laugh and a no.
There are certainly many businesses where this is true, but there are also many business where it isn't true at all.
Bug fixes will be given some time but telling management/business, we need 2 months to go and clean up everything we've built over the last 6 since we now have an idea of how to structure this capability is gonna be met with a laugh and a no.
Inevitably something will break or a new feature will not be possible cause of existing limitations and everyone will get mad since no one told them something could break without an improvement even though you told them well beforehand that the ground was shaky.
I think companies not prone to this are ones where their product is a technical one like cloud services where the business really is the engineering and engineering isn't a means to an end.