13 ms·

People blame developers but it's all driven by a product mentality that favors rapid iterations and technical debt to run business experiments on customers. Slo

People blame developers but it's all driven by a product mentality that favors rapid iterations and technical debt to run business experiments on customers. Slow-and-steady, carefully written software isn't tolerated within many product orgs these days.

FridgeSeal 6y ago
I very much agree. I get that “done is better than perfect” but it feels like we’ve swung so hard in that direction that we seem to be largely neglecting stepping back and building the rough roll for the job in all but the largest places who have the luxury of having enough resources to assign a big enough team in the background to do it.
- JanisL 6y ago
  There seems to be this version of “done is better than perfect” thinking where people think that aiming for quality in any form will get in the way of getting things done. Where this gets especially pathological is when people assume that the best way to get things done is by explicitly decreasing quality, the underlying flawed assumption being that decreasing quality can be directly traded for a shorter schedule.
enraged_camel 6y ago
>>Slow-and-steady, carefully written software isn't tolerated within many product orgs these days. The problem is that this works only for large clients and conservative problem domains (such as accounting) where things change at a glacial pace. Back in the day, only such clients could afford enterprise/custom software, so using a waterfall methodology to develop that software worked well enough. Took five years to deliver the final product? No problem because the set of requirements you collected five years ago and based your software on probably still apply at the time of customer sign-off. Things have changed. Software has gotten much cheaper to develop, which means it has become way more affordable, and the types of businesses who need that kind of software are in heavy competition with each other and their problems and needs change at breakneck speed. So your best best is to have your own software development practices to match that speed.
- Chris2048 6y ago
  There are lots of laws and regulations around building to prevent e.g. bridges falling down. So just remove them. Now buildings have gotten much cheaper to build, which means they have become way more affordable, and the types of businesses who need that kind of building are in heavy competition with each other and their problems and needs change at breakneck speed. Failing that, keep the regulations, and apply more to software. The "needs" of business will change, and competition will move. "Slow-and-steady" needn't be glacial, and there's a lot between that and "breakneck speed". Plus there is a difference between time it takes to deliver, and frequency of requirement collection - your example implies you get requirements/sign-off exactly once before final delivery (5 years later). If we contrast "final" delivery with intermediate releases - why are the requirements not re-evaluated at each release time? You can still have slow, steady development, with lots of feedback - there just has to be an understanding that software delivered long term should not be interfered with short term concerns.
munificent 6y ago
> it's all driven by a product mentality that favors rapid iterations and technical debt to run business experiments on customers. Which is in turn driven by a venture capital industry that cares only about massive growth and nothing else.
- mcguire 6y ago
  It's common outside the startup world, too. I think it's more to do with a disinclination to touch anything "legacy". New and shiny good, otherwise bad.
  - devonkim 6y ago
    “Legacy” both works and delivers value. It also doesn’t get political visibility by making something new as a manager. Optimizing the costs of existing business lines is essentially a cost center career track in itself and is why IT people get screwed a lot and those with 90%+ of the same skills in a software development shop will get a bump in pay.
    - richiebful1 6y ago
      Yup. We have an in-house MDM solution at work that is mostly composed of stored procedures, SSIS and small C# desktop apps. It could do with some improvements, but overall it works like a charm. But we're rewriting it to use Snowflake and Kafka. With no real use case for the rewrite.
    - the_gipsy 6y ago
      There's two kinds of legacy, though. The proven, you talk about, and the tech-debt.
  - _AzMoo 6y ago
    Feedback from our HR department indicates that we struggle to retain younger employees in large part because they don't want to use legacy systems.
draw_down 6y ago
We all know the drill. Good fast cheap pick two- two if you’re lucky! And I can guarantee you not a single PM or product owner on this earth will care about “code is easy to checkout and build five years from now”.
deleted 6y ago
[deleted]
vvanders 6y ago
Go spend some time with PLC/automation engineers and you'll find the same thing. Safety stuff? Done then right way with the proper attention. Rest of the production line stuff? Hack on hacks in order to get things online ASAP. At least that's my impression from the outside view I've seen.
- causality0 6y ago
  It really is the worst. Machines custom-built thirty years ago with documentation that reflects about 25% of the current configuration. Processes that rely on five lines of code and run great for six hours before completely breaking for no good reason. Windows XP boxes that've been on continuously for five years because the moment they shut down a boiler fails that requires a 24-hour restart process. I'm incredibly glad I got out of that industry.
  - vt240 6y ago
    A 24-hr restart plan, sounds like a properly documented quality management process for a large boiler? Disconnecting the "Windows XP box" is removing the control system correct? Not really the same thing is it? There's no reason the XP Embedded hardware platform could not have been engineered with high availability in mind? It's not as if there are no comercial-off-the-shelf options here. The company who chooses to let the bosses son, who built custom PCs in high school, design the critical process control systems, is I'd say, outside the scope of the argument here.
    - causality0 6y ago
      It was literally an e-machines desktop.
      - vt240 6y ago
        Haha. Been there. Seen that. I do feel for you though.
      - vt240 6y ago
jSully24 6y ago
I think this is an over simplification. Software teams are forever trying to find a balance between getting value to customers and getting the code, tests, architecture, docs, etc right. If you have nothing to sell you’re done. If your legacy cruft becomes overwhelming you’re done, but likely via a slow death. Good teams are always struggling with this balance and there is no way to be right, but hopefully you can find that balance and be good enough.
papito 6y ago
I am really hating working in the current state of the industry right now. I am used to writing robust, clear, well-tested, and easy to maintain systems. The job right now seems just stitching AWS services together, and spending the rest of your time debugging and putting out fires.
- Jade_Jet 6y ago
  You’ve spelled out exactly how I feel.
- xwdv 6y ago
  Just means you gotta work higher up in the food chain. You need a new job. Build what other developers eat.
  - caretak3r 6y ago
    Build what other developers eat. I am interested in this topic, can you elaborate? Or any thoughts from anyone?
    - thethethethe 6y ago
      I think OP is referring to things like working on cloud infrastructure, systems software like web servers and reverse proxies, programming languages, or foundational libraries and frameworks libraries—all of which are consumed by application developers
      - Ericson2314 6y ago
        Or have my job, switching periodically between on all that stuff and the end application. Make sure the tools you make are actually useful for the problem they purport to solve! We just refuse to use vendor-lock-in cloud crap as a matter of principle. Regular server processes (though Haskell), regular machines (the NixOS), PostgreSQL, no problem.
        6y ago
Nasrudith 6y ago
I would have guessed the cause as HR recruiting and ladder climbing related. The latest hotness being needed to get a higher paying job elsewhere as opposed to just going with what works. Disregard for technical debt is certainly a force.
sytelus 6y ago
Slow and steady is not useful if it's too little too late. I deal with so many broken websites, products, working with customer support that it is amazing how slow organizations are at reacting to customer needs. Sometime it takes 6 months before simple bug fix finally shows up in product. We are living in fast changing world and one need to weight getting things out now vs being perfect. The thing that matters is not eventually releasing perfect software but rather can you iterate fast enough to get there eventually?
- arexxbifs 6y ago
  Higher churn leads to more features being crammed in which leads to more bugs and increased technical debt.
- orev 6y ago
  It takes 6 months to get those things out the door because teams are so busy dealing with fires and other technical debt that has built up from all the previous “do it dirty now and we’ll fix it later” features. Eventually you’re buried in keeping things afloat all the previous mistakes and just can’t move forward on anything.
  - quantified 6y ago
    My experience matches this. I was there when all the “move fast and break things, we’ll fix it later” became bugs and bad situations that suck all the energy from adding anything. Several years later, nothing can get fixed, it’s all fighting the fires. And it was all done following fashion, there was no real need.
    - cogman10 6y ago
      Meanwhile, you've got management demanding more features and getting upset when you say "we can add it, but we need time to fix the mistakes of the past" "No, there's no time for that, MVP, get something out! We'll fix it later!"
  - deleted 6y ago
    [deleted]
amrx101 6y ago
I have been asking my product managers time so that I can update libraries and what not. Nope. All these MBAs and non MBAs and Safe and Agile managers, they are all talk but dont allot time for issues that helps in better code-quality.
- tobyhinloopen 6y ago
  Don’t ask, just put it in the next estimate.
- mrmonkeyman 6y ago
  Ask? Just do it.
throwaway189262 6y ago
In the micromanaged world of agile, ticket velocity is more important than any other metric. At least everywhere I've worked. Open source is the only place I regularly see high quality code. There the devs are allowed to love their code like pets not cattle.
tluyben2 6y ago
The self imposed complexity of brittle aws microservices/lambda stringed together is definitely the fault of developers. There are a handful of companies that need (and can afford!) architecture like that (maybe, Uber is backpeddling on it) but the vast majority of the world is shooting themselves in the foot and that is on developers and resume driven dev. Nothing to do with faster iterations, although that is probably how it is sold to management. The developer should know better.
- ChuckNorris89 6y ago
  The resume driven development is a consequence of poor hiring practices that discriminate candidates on the language/framework hype instead of hiring based on experience, know-how and potential. Our company is looking for an experienced dev with Node and AWS experience. What's that, you have 15 years of industry experience but it's all on-prem Java/PHP? Too bad. NEXT!
  - r_c_a_d 6y ago
    Spot on. I always used to get a certain company local to me flagged up by recruiters when I was job hunting. Every time they rejected my resume without interview because it did not have "Spring" on it. Years later I worked at this place as a 3rd party contractor. What little bit of Spring I needed to know I picked up in the first few days. Their codebase and methodology was very poor and they were drowning because they only had one or two experienced people... but all the people they had had "Spring" on their resumes.
  - nicbou 6y ago
    I think it's also a consequence of developers just getting bored. I don't care so much about my resume, but I'm always eager to try new things.
baxtr 6y ago
I had a discussion with one our devs just yesterday about this. He had the exact opposite notion that some devs are too focused on getting things perfect and don't care about the value they deliver to the business. I guess it's crucial to get the right balance.
meheleventyone 6y ago
This is still squarely on the developers. Slow and steady might be your preference and the best way to make some software or parts of software but that’s not universally true. A lot of creative domains really benefit from fast iteration times to experiment. It might not be your ideal environment to be making products but it is our job to square the circle otherwise we’re not going to have jobs. For a concrete example look at the way game engine development happens. By and large engine development is slow and steady. Whilst making a game is something that massively benefits from blazing iteration speeds. Having that split between technology and product means you can do both. Of course we’re also dealing with messy reality so things are faster or slower than each team would like at times.
tarsinge 6y ago
Are we talking about tools or enterprise software? Slow and steady carefully written software never existed for the latter, it was always a mess of moving requirements. I’m not sure what’s worse between previous grandiose UML specified software that failed to be implemented after many years and millions spent, or the current state of affairs where at least software projects move on.
onion2k 6y ago
Slow-and-steady, carefully written software isn't tolerated within many product orgs these days. Rapid iteration is driven by customers not actually knowing what they need. There are places where "slow and steady" development would work, but very often you'd just find out what the customer needs isn't what they've asked for over a much longer period. You'd end up throwing out a lot of the perfectly crafted artisanal code anyway just as you would in the rapid dev version. The main difference is that the customer would have run out of money by then, and failed, and you'd need a new job.
notacoward 6y ago
It's both, and then some. Product folks surely do love to get new features out. Developers also love it, because writing new code is far more fun than improving reliability, performance, security, or operational load for old code. In 30+ years I've worked in all sorts of environments, but accumulating technical debt has been one of the few constants. Everyone tries to say the right things in meetings. Maybe tech-debt reduction even makes a brief cameo in early planning sessions, but good luck getting it into the final plan. Even if that happens, guaranteed that it will show up as a miss at the end of the cycle, because it's always the very last thing on everyone's list and everyone's list is always too long. A dozen companies, maybe twice that many projects, twice again as many architects/managers/whatever, always the same story. As for "and then some" that's the part that's on senior management and HR, for setting up review/promotion structures that actively incentivize sloppy engineering. When all of the rewards are for New Shiny, some people will actively sabotage efforts to spend time any other way. Nobody wants to delay their new-feature effort to deal with new test failures or cleaned-up APIs. Even those who have enough of a conscience to to the right thing get kneecapped at every turn.

FridgeSeal 6y ago

I very much agree. I get that “done is better than perfect” but it feels like we’ve swung so hard in that direction that we seem to be largely neglecting stepping back and building the rough roll for the job in all but the largest places who have the luxury of having enough resources to assign a big enough team in the background to do it.

JanisL 6y ago
There seems to be this version of “done is better than perfect” thinking where people think that aiming for quality in any form will get in the way of getting things done. Where this gets especially pathological is when people assume that the best way to get things done is by explicitly decreasing quality, the underlying flawed assumption being that decreasing quality can be directly traded for a shorter schedule.

enraged_camel 6y ago

>>Slow-and-steady, carefully written software isn't tolerated within many product orgs these days. The problem is that this works only for large clients and conservative problem domains (such as accounting) where things change at a glacial pace. Back in the day, only such clients could afford enterprise/custom software, so using a waterfall methodology to develop that software worked well enough. Took five years to deliver the final product? No problem because the set of requirements you collected five years ago and based your software on probably still apply at the time of customer sign-off. Things have changed. Software has gotten much cheaper to develop, which means it has become way more affordable, and the types of businesses who need that kind of software are in heavy competition with each other and their problems and needs change at breakneck speed. So your best best is to have your own software development practices to match that speed.

Chris2048 6y ago
There are lots of laws and regulations around building to prevent e.g. bridges falling down. So just remove them. Now buildings have gotten much cheaper to build, which means they have become way more affordable, and the types of businesses who need that kind of building are in heavy competition with each other and their problems and needs change at breakneck speed. Failing that, keep the regulations, and apply more to software. The "needs" of business will change, and competition will move. "Slow-and-steady" needn't be glacial, and there's a lot between that and "breakneck speed". Plus there is a difference between time it takes to deliver, and frequency of requirement collection - your example implies you get requirements/sign-off exactly once before final delivery (5 years later). If we contrast "final" delivery with intermediate releases - why are the requirements not re-evaluated at each release time? You can still have slow, steady development, with lots of feedback - there just has to be an understanding that software delivered long term should not be interfered with short term concerns.

munificent 6y ago

> it's all driven by a product mentality that favors rapid iterations and technical debt to run business experiments on customers. Which is in turn driven by a venture capital industry that cares only about massive growth and nothing else.

mcguire 6y ago
It's common outside the startup world, too. I think it's more to do with a disinclination to touch anything "legacy". New and shiny good, otherwise bad.
- devonkim 6y ago
  “Legacy” both works and delivers value. It also doesn’t get political visibility by making something new as a manager. Optimizing the costs of existing business lines is essentially a cost center career track in itself and is why IT people get screwed a lot and those with 90%+ of the same skills in a software development shop will get a bump in pay.
  - richiebful1 6y ago
    Yup. We have an in-house MDM solution at work that is mostly composed of stored procedures, SSIS and small C# desktop apps. It could do with some improvements, but overall it works like a charm. But we're rewriting it to use Snowflake and Kafka. With no real use case for the rewrite.
  - the_gipsy 6y ago
    There's two kinds of legacy, though. The proven, you talk about, and the tech-debt.
- _AzMoo 6y ago
  Feedback from our HR department indicates that we struggle to retain younger employees in large part because they don't want to use legacy systems.

draw_down 6y ago

We all know the drill. Good fast cheap pick two- two if you’re lucky! And I can guarantee you not a single PM or product owner on this earth will care about “code is easy to checkout and build five years from now”.

deleted 6y ago

[deleted]

vvanders 6y ago

Go spend some time with PLC/automation engineers and you'll find the same thing. Safety stuff? Done then right way with the proper attention. Rest of the production line stuff? Hack on hacks in order to get things online ASAP. At least that's my impression from the outside view I've seen.

causality0 6y ago
It really is the worst. Machines custom-built thirty years ago with documentation that reflects about 25% of the current configuration. Processes that rely on five lines of code and run great for six hours before completely breaking for no good reason. Windows XP boxes that've been on continuously for five years because the moment they shut down a boiler fails that requires a 24-hour restart process. I'm incredibly glad I got out of that industry.
- vt240 6y ago
  A 24-hr restart plan, sounds like a properly documented quality management process for a large boiler? Disconnecting the "Windows XP box" is removing the control system correct? Not really the same thing is it? There's no reason the XP Embedded hardware platform could not have been engineered with high availability in mind? It's not as if there are no comercial-off-the-shelf options here. The company who chooses to let the bosses son, who built custom PCs in high school, design the critical process control systems, is I'd say, outside the scope of the argument here.
  - causality0 6y ago
    It was literally an e-machines desktop.
    - vt240 6y ago
      Haha. Been there. Seen that. I do feel for you though.
    - vt240 6y ago

jSully24 6y ago

I think this is an over simplification. Software teams are forever trying to find a balance between getting value to customers and getting the code, tests, architecture, docs, etc right. If you have nothing to sell you’re done. If your legacy cruft becomes overwhelming you’re done, but likely via a slow death. Good teams are always struggling with this balance and there is no way to be right, but hopefully you can find that balance and be good enough.

papito 6y ago

I am really hating working in the current state of the industry right now. I am used to writing robust, clear, well-tested, and easy to maintain systems. The job right now seems just stitching AWS services together, and spending the rest of your time debugging and putting out fires.

Jade_Jet 6y ago
You’ve spelled out exactly how I feel.
xwdv 6y ago
Just means you gotta work higher up in the food chain. You need a new job. Build what other developers eat.
- caretak3r 6y ago
  Build what other developers eat. I am interested in this topic, can you elaborate? Or any thoughts from anyone?
  - thethethethe 6y ago
    I think OP is referring to things like working on cloud infrastructure, systems software like web servers and reverse proxies, programming languages, or foundational libraries and frameworks libraries—all of which are consumed by application developers
    - Ericson2314 6y ago
      Or have my job, switching periodically between on all that stuff and the end application. Make sure the tools you make are actually useful for the problem they purport to solve! We just refuse to use vendor-lock-in cloud crap as a matter of principle. Regular server processes (though Haskell), regular machines (the NixOS), PostgreSQL, no problem.
      - 6y ago

Nasrudith 6y ago

I would have guessed the cause as HR recruiting and ladder climbing related. The latest hotness being needed to get a higher paying job elsewhere as opposed to just going with what works. Disregard for technical debt is certainly a force.

sytelus 6y ago

Slow and steady is not useful if it's too little too late. I deal with so many broken websites, products, working with customer support that it is amazing how slow organizations are at reacting to customer needs. Sometime it takes 6 months before simple bug fix finally shows up in product. We are living in fast changing world and one need to weight getting things out now vs being perfect. The thing that matters is not eventually releasing perfect software but rather can you iterate fast enough to get there eventually?

arexxbifs 6y ago
Higher churn leads to more features being crammed in which leads to more bugs and increased technical debt.
orev 6y ago
It takes 6 months to get those things out the door because teams are so busy dealing with fires and other technical debt that has built up from all the previous “do it dirty now and we’ll fix it later” features. Eventually you’re buried in keeping things afloat all the previous mistakes and just can’t move forward on anything.
- quantified 6y ago
  My experience matches this. I was there when all the “move fast and break things, we’ll fix it later” became bugs and bad situations that suck all the energy from adding anything. Several years later, nothing can get fixed, it’s all fighting the fires. And it was all done following fashion, there was no real need.
  - cogman10 6y ago
    Meanwhile, you've got management demanding more features and getting upset when you say "we can add it, but we need time to fix the mistakes of the past" "No, there's no time for that, MVP, get something out! We'll fix it later!"
- deleted 6y ago
  [deleted]

amrx101 6y ago

I have been asking my product managers time so that I can update libraries and what not. Nope. All these MBAs and non MBAs and Safe and Agile managers, they are all talk but dont allot time for issues that helps in better code-quality.

tobyhinloopen 6y ago
Don’t ask, just put it in the next estimate.
mrmonkeyman 6y ago
Ask? Just do it.

throwaway189262 6y ago

In the micromanaged world of agile, ticket velocity is more important than any other metric. At least everywhere I've worked. Open source is the only place I regularly see high quality code. There the devs are allowed to love their code like pets not cattle.

tluyben2 6y ago

The self imposed complexity of brittle aws microservices/lambda stringed together is definitely the fault of developers. There are a handful of companies that need (and can afford!) architecture like that (maybe, Uber is backpeddling on it) but the vast majority of the world is shooting themselves in the foot and that is on developers and resume driven dev. Nothing to do with faster iterations, although that is probably how it is sold to management. The developer should know better.

ChuckNorris89 6y ago
The resume driven development is a consequence of poor hiring practices that discriminate candidates on the language/framework hype instead of hiring based on experience, know-how and potential. Our company is looking for an experienced dev with Node and AWS experience. What's that, you have 15 years of industry experience but it's all on-prem Java/PHP? Too bad. NEXT!
- r_c_a_d 6y ago
  Spot on. I always used to get a certain company local to me flagged up by recruiters when I was job hunting. Every time they rejected my resume without interview because it did not have "Spring" on it. Years later I worked at this place as a 3rd party contractor. What little bit of Spring I needed to know I picked up in the first few days. Their codebase and methodology was very poor and they were drowning because they only had one or two experienced people... but all the people they had had "Spring" on their resumes.
- nicbou 6y ago
  I think it's also a consequence of developers just getting bored. I don't care so much about my resume, but I'm always eager to try new things.

baxtr 6y ago

I had a discussion with one our devs just yesterday about this. He had the exact opposite notion that some devs are too focused on getting things perfect and don't care about the value they deliver to the business. I guess it's crucial to get the right balance.

meheleventyone 6y ago

This is still squarely on the developers. Slow and steady might be your preference and the best way to make some software or parts of software but that’s not universally true. A lot of creative domains really benefit from fast iteration times to experiment. It might not be your ideal environment to be making products but it is our job to square the circle otherwise we’re not going to have jobs. For a concrete example look at the way game engine development happens. By and large engine development is slow and steady. Whilst making a game is something that massively benefits from blazing iteration speeds. Having that split between technology and product means you can do both. Of course we’re also dealing with messy reality so things are faster or slower than each team would like at times.

tarsinge 6y ago

Are we talking about tools or enterprise software? Slow and steady carefully written software never existed for the latter, it was always a mess of moving requirements. I’m not sure what’s worse between previous grandiose UML specified software that failed to be implemented after many years and millions spent, or the current state of affairs where at least software projects move on.

onion2k 6y ago

Slow-and-steady, carefully written software isn't tolerated within many product orgs these days. Rapid iteration is driven by customers not actually knowing what they need. There are places where "slow and steady" development would work, but very often you'd just find out what the customer needs isn't what they've asked for over a much longer period. You'd end up throwing out a lot of the perfectly crafted artisanal code anyway just as you would in the rapid dev version. The main difference is that the customer would have run out of money by then, and failed, and you'd need a new job.

notacoward 6y ago

It's both, and then some. Product folks surely do love to get new features out. Developers also love it, because writing new code is far more fun than improving reliability, performance, security, or operational load for old code. In 30+ years I've worked in all sorts of environments, but accumulating technical debt has been one of the few constants. Everyone tries to say the right things in meetings. Maybe tech-debt reduction even makes a brief cameo in early planning sessions, but good luck getting it into the final plan. Even if that happens, guaranteed that it will show up as a miss at the end of the cycle, because it's always the very last thing on everyone's list and everyone's list is always too long. A dozen companies, maybe twice that many projects, twice again as many architects/managers/whatever, always the same story. As for "and then some" that's the part that's on senior management and HR, for setting up review/promotion structures that actively incentivize sloppy engineering. When all of the rewards are for New Shiny, some people will actively sabotage efforts to spend time any other way. Nobody wants to delay their new-feature effort to deal with new test failures or cleaned-up APIs. Even those who have enough of a conscience to to the right thing get kneecapped at every turn.