4 ms·

I think a lot of this is just a product of the amount of complexity software is expected to manage. No single person can keep it all in their head with all the

I think a lot of this is just a product of the amount of complexity software is expected to manage. No single person can keep it all in their head with all the constantly changing parts. This has followed the shift of oftware development from a capital investment to more of an operational one. The job profile of operational work doesn't fit neatly within the solo developer / deep flow paradigm. Sure, that might be necessary for some dev jobs, but most dev jobs are more figuring out what needs to be built than actually building it. And for better or worse (usually worse for those of us on the spectrum), every job seems headed in this direction.

zozbot234 7y ago
> the amount of complexity software is expected to manage. How much of that is incidental complexity, though? What happened to refactoring and paying down technical debt - weren't these supposed to be tenets of Agile?
- wayoutthere 7y ago
  The best way to think of Agile is "bare minimum project management for the sake of product management". You can get wrapped up in the rituals and "best practices" but at the end of the day, it's usually about delivering software in a way that makes it easy to buy and sell. It's easier to sell software when you can pull a feature on a roadmap up to land a big account than it is to refactor and cut a custom release for them. It's easier to buy software when you know it's constantly improving. Software also does more and integrates with more than it ever has. This is driven by customer requirements, which are pretty much non-negotiable.
  - zozbot234 7y ago
    > It's easier to sell software when you can pull a feature on a roadmap up to land a big account It's initially easier to sell software with that quick-and-dirty approach, but if you keep doing it you'll find that you're incurring a lot of technical debt. Which you'll need to pay down in some way, if you want your software to be "constantly improving". If you're right that customer requirements are requiring more essential complexity of our industry, keeping these dynamics in check can only be even more important, rather than less.
    - wayoutthere 7y ago
      > It's initially easier to sell software with that quick-and-dirty approach, but if you keep doing it you'll find that you're incurring a lot of technical debt. Developers think a lot about technical debt as it relates to engineering (and they should!), but I find that "product debt" (features that need to be combined / streamlined / reimagined for UX / product purposes) is actually more meaningful in most contexts. This can make conversations with product folks difficult as engineering and a product owner often have very different ideas about what the phrase "technical debt" means. It can be hard to pay down either when you're talking past each other. > If you're right that customer requirements are requiring more essential complexity of our industry, keeping these dynamics in check can only be even more important, rather than less. The world is simply a lot more complex and interconnected than it was 20 years ago when the type of development OP describes was still widespread. I don't think we can put the cat back in the bag. Agile approaches honestly reduce the complexity by not building anything that isn't being asked for and being intentional about which tech debt to pay down.
      - pdimitar 7y ago
        > Agile approaches honestly reduce the complexity by not building anything that isn't being asked for and being intentional about which tech debt to pay down. It can do those things, but it very rarely does, even by well-meaning teams. It’s time to drop the “should help” and adopt the “...but historically, did it really?”. Changing that mindset I found to be a nearly impossible task.
        wayoutthere 7y ago
        I think everyone wistfully pining for an era without Agile forgets how many software projects were flat-out abandoned without seeing release after a few years of dev work. Software development was not a "hot profession" until Agile came along and a software product was no longer a multi-million dollar commitment to get money coming in the door. We all owe the success of the industry to Agile / iterative development, because most of the projects that keep us employed never would have gotten off the ground in a pre-Agile world. One of the oldest cliches in software development is "faster, better or cheaper -- pick two". The prevalence of Agile basically means that "faster and cheaper" is the default answer to this question. If you want "better," the CMMI still exists (and is still heavily used in defense / aerospace).

zozbot234 7y ago

> the amount of complexity software is expected to manage. How much of that is incidental complexity, though? What happened to refactoring and paying down technical debt - weren't these supposed to be tenets of Agile?

wayoutthere 7y ago
The best way to think of Agile is "bare minimum project management for the sake of product management". You can get wrapped up in the rituals and "best practices" but at the end of the day, it's usually about delivering software in a way that makes it easy to buy and sell. It's easier to sell software when you can pull a feature on a roadmap up to land a big account than it is to refactor and cut a custom release for them. It's easier to buy software when you know it's constantly improving. Software also does more and integrates with more than it ever has. This is driven by customer requirements, which are pretty much non-negotiable.
- zozbot234 7y ago
  > It's easier to sell software when you can pull a feature on a roadmap up to land a big account It's initially easier to sell software with that quick-and-dirty approach, but if you keep doing it you'll find that you're incurring a lot of technical debt. Which you'll need to pay down in some way, if you want your software to be "constantly improving". If you're right that customer requirements are requiring more essential complexity of our industry, keeping these dynamics in check can only be even more important, rather than less.
  - wayoutthere 7y ago
    > It's initially easier to sell software with that quick-and-dirty approach, but if you keep doing it you'll find that you're incurring a lot of technical debt. Developers think a lot about technical debt as it relates to engineering (and they should!), but I find that "product debt" (features that need to be combined / streamlined / reimagined for UX / product purposes) is actually more meaningful in most contexts. This can make conversations with product folks difficult as engineering and a product owner often have very different ideas about what the phrase "technical debt" means. It can be hard to pay down either when you're talking past each other. > If you're right that customer requirements are requiring more essential complexity of our industry, keeping these dynamics in check can only be even more important, rather than less. The world is simply a lot more complex and interconnected than it was 20 years ago when the type of development OP describes was still widespread. I don't think we can put the cat back in the bag. Agile approaches honestly reduce the complexity by not building anything that isn't being asked for and being intentional about which tech debt to pay down.
    - pdimitar 7y ago
      > Agile approaches honestly reduce the complexity by not building anything that isn't being asked for and being intentional about which tech debt to pay down. It can do those things, but it very rarely does, even by well-meaning teams. It’s time to drop the “should help” and adopt the “...but historically, did it really?”. Changing that mindset I found to be a nearly impossible task.
      - wayoutthere 7y ago
        I think everyone wistfully pining for an era without Agile forgets how many software projects were flat-out abandoned without seeing release after a few years of dev work. Software development was not a "hot profession" until Agile came along and a software product was no longer a multi-million dollar commitment to get money coming in the door. We all owe the success of the industry to Agile / iterative development, because most of the projects that keep us employed never would have gotten off the ground in a pre-Agile world. One of the oldest cliches in software development is "faster, better or cheaper -- pick two". The prevalence of Agile basically means that "faster and cheaper" is the default answer to this question. If you want "better," the CMMI still exists (and is still heavily used in defense / aerospace).