7 ms·

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

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.

Scarblac 3y ago
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.
- ilyt 3y ago
  > Most of the time those business types are correct on this. If you can call it making problems after they leave "being correct".
- malfist 3y ago
  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.
bradstewart 3y ago
> 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".
- OzzyB 3y ago
  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.
- quadrifoliate 3y ago
  > 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.
snarfy 3y ago
There's never enough time to do it right, but always enough time to do it twice. Hence, the inevitable rewrite.
cline6 3y ago
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.
- Inviz 3y ago
  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.
- realce 3y ago
  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.
  - cline6 3y ago
    "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.
    - pixl97 3y ago
      "Dear PM, please quit signing off on broken ass bullshit in the first place"
- JohnFen 3y ago
  > 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.
dimal 3y ago
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.
eweise 3y ago
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.
si1entstill 3y ago
> 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.
JohnFen 3y ago
> 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.
royaltheartist 3y ago
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
- wiremine 3y ago
  > 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.
- nine_zeros 3y ago
  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. Management incentives need to be changed.
- wldcordeiro 3y ago
legrande 3y ago
> 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. [0] https://www.dancowell.com/software-engineers-hate-code/ https://www.dancowell.com/software-engineers-hate-code/
karakanb 3y ago
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.
kristiandupont 3y ago
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.
- ep103 3y ago
  You need a truth table. Good code + Good Business = Success. Bad code + Bad Business = Failure. Good code + Bad Business = Failure. Bad Code + Good Business = Success. 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.
  - esafak 3y ago
    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).
    - disgruntledphd2 3y ago
      > That's why Friendster failed and Google succeeded. More to the point of the Friendster example, that's why Facebook succeeded. Sure, their code was crappy but the site stayed up.
pjmlp 3y ago
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.
- ilyt 3y ago
  > 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.
  - pjmlp 3y ago
    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.
esafak 3y ago
It's short-term optimization vs. long-term optimization. One way out is to budget time, say Fridays, for refactoring, bug fixing, and documentation.
ShadowBanThis01 3y ago
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.
ricardobayes 3y ago
You might as well try. In my career I had zero issues explaining why we need to do a cleanup or optimization.
Fire-Dragon-DoL 3y ago
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

Scarblac 3y ago

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.

ilyt 3y ago
> Most of the time those business types are correct on this. If you can call it making problems after they leave "being correct".
malfist 3y ago
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.

bradstewart 3y ago

> 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".

OzzyB 3y ago
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.
quadrifoliate 3y ago
> 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.

snarfy 3y ago

There's never enough time to do it right, but always enough time to do it twice. Hence, the inevitable rewrite.

cline6 3y ago

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.

Inviz 3y ago
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.
realce 3y ago
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.
- cline6 3y ago
  "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.
  - pixl97 3y ago
    "Dear PM, please quit signing off on broken ass bullshit in the first place"
JohnFen 3y ago
> 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.

dimal 3y ago

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.

eweise 3y ago

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.

si1entstill 3y ago

> 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.

JohnFen 3y ago

> 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.

royaltheartist 3y ago

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

wiremine 3y ago
> 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.
nine_zeros 3y ago
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. Management incentives need to be changed.
wldcordeiro 3y ago

legrande 3y ago

> 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. [0] https://www.dancowell.com/software-engineers-hate-code/ https://www.dancowell.com/software-engineers-hate-code/

karakanb 3y ago

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.

kristiandupont 3y ago

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.

ep103 3y ago
You need a truth table. Good code + Good Business = Success. Bad code + Bad Business = Failure. Good code + Bad Business = Failure. Bad Code + Good Business = Success. 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.
- esafak 3y ago
  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).
  - disgruntledphd2 3y ago
    > That's why Friendster failed and Google succeeded. More to the point of the Friendster example, that's why Facebook succeeded. Sure, their code was crappy but the site stayed up.

pjmlp 3y ago

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.

ilyt 3y ago
> 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.
- pjmlp 3y ago
  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.

esafak 3y ago

It's short-term optimization vs. long-term optimization. One way out is to budget time, say Fridays, for refactoring, bug fixing, and documentation.

ShadowBanThis01 3y ago

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.

ricardobayes 3y ago

You might as well try. In my career I had zero issues explaining why we need to do a cleanup or optimization.

Fire-Dragon-DoL 3y ago

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