I particularly enjoyed the bit about leader & managers not using system thinking, which is a major cause of frustration for me in my career... Because they keep us churning more feature, more tweaks, to the detriment of the whole system, and soon the code entropies to the point where every single little thing takes an eternity, because they would not let us architecture the software/system, all they wanted was to add features, no matter the cost, no matter the problem it will generate in the future
This has been my experience in a lot of jobs as well. Not all though, there are companies and leaders that "get it." Also hopefully this is coming out in the video, but I actually understand and empathize with those leaders/planners that are pushing for features. They're also under pressure from the business to deliver.
Doesn't matter how beautifully designed your system is if your software cannot be released! Software must be useful to someone for the company to survive.
@@FixingSoftware I found that companies where business pushes to deliver fast are very rarely efficient. If your business is not in decline, you can afford people refactoring stuff and you should allow them to do that without any constrains, because building poorly designed software creates not only tech debt but toxicity in the company, not to mention that it encourages taking shortcuts. Eventually if the software written degrades beyond a point, all good engineers will leave as they get tired of working in such conditions and you will be stuck in the low efficiency zone forever, I've personally seen a few companies failing their business this way.
@D4no00 that’s a good point about the state of the business. I’ve also seen it in low margin businesses. Like in private equity situations where excess profits are siphoned and returned to the holding company shareholders, vs being re-invested.
@MFTGShane much appreciated! you can tag me in your share as well and I can answer questions or make clarifications, this is me on LI: www.linkedin.com/in/benjaminrthorp/
> what is the solution > we don't have leader that can modelize complex-systems Here the start of a solution: - find and encourage social-skilled developers to become manager and in leadership position while providing training - prevent non-techies in leadership positions that manage software development, slowly replace them - be able to visualize your domains and systems, if you can't, then you either over-engineered your codebase OR badly designed it (to be too complex) Also what helped (in my exp) with predictability: - learn DDD and EDA - use documentation tools, visualization tools, comprehensible monitoring tools - avoid splitting your codebase too much into too much services Great video as usual, your opinions are highly appreciated!
I've worked in a company where this was in place and it worked greatly! You have folk that interacts with the client and comes up with the requirements (yet still have a good understanding of how technically this should work) and you have some very skilled and socially apt software developers, that not only understand in detail a part of the business, but can also come with a solution to the problem on their own. Each of them work in cooperation to achieve a result, as there is no chain of command that would allow one or the other to take the decision alone. I'm really embarrassed about the processes at my current work, as it is exactly the opposite. Total lack of any form of documentation (both technical and from business side), untested projects, using services + shared global storage (I guess they missed the part of data owning when they've read the definition of microservices). Their focus is on delivering features, however I can easily say that the rate they deliver features is at least 10x slower and more painful than the company mentioned above.
@D4no00 yeah sometimes speed is an illusion because of the accumulation of undone work and tech debt. It slows everyone down. And it doesn’t take long for that to happen.
I think predictability has a lot of value. If my team is relatively good at estimation, that means they have reduced the amount of uncertainty in the system to the point that they can deliver consistently, which I think is often a sign of a good engineering manager. I like having that predictability on my team because it reduces the risk of giving an incorrect estimate and then having to work long hours to hit the incorrect date. It’s definitely a trade off though. If you want more predictability from a team, then the team has to work in a more rigid fashion. Sometimes that’s bad, and sometimes it’s good (large cross team projects). I think some companies make the mistake of thinking that it always has to be one way or the other (especially if they make everything rigid).
Once again, well said. My issue isn’t with predictability itself, hopefully that was clear. It’s the negative downstream consequences of optimizing solely for predictability. Yes an engineering manager who gets the multitude of ways predictably can be achieved, without killing the longer term sustainability of the team, they’re the keepers. To play devil’s advocate: if a team is encouraged to have accurate estimates, might that incentivize deviant corner cutting behavior?
The "add more lanes creates congestion" is a really poor example. What actually happened there is that with more lanes, more people got served, even if it's at the same level of quality as before; -- as previously these people would not even attempt to get to where they want to.
Thanks for the comment. That’s partially true but regardless, it still paradoxically resulted in more congestion. It’s similar to how speed control can actually increase throughput in traffic. It’s a paradoxical non-intuitive result. There’s a similar paradox with electronic devices. The more energy efficient they become, demand for them increases and the more electricity end up being used.
![Ice On My Teeth - ATEEZ エイティーズ 에이티즈 [Music Bank] | KBS WORLD TV 241115](http://i.ytimg.com/vi/c-n92OgbbwA/mqdefault.jpg)
I particularly enjoyed the bit about leader & managers not using system thinking, which is a major cause of frustration for me in my career... Because they keep us churning more feature, more tweaks, to the detriment of the whole system, and soon the code entropies to the point where every single little thing takes an eternity, because they would not let us architecture the software/system, all they wanted was to add features, no matter the cost, no matter the problem it will generate in the future
This has been my experience in a lot of jobs as well. Not all though, there are companies and leaders that "get it."
Also hopefully this is coming out in the video, but I actually understand and empathize with those leaders/planners that are pushing for features. They're also under pressure from the business to deliver.
Doesn't matter how beautifully designed your system is if your software cannot be released! Software must be useful to someone for the company to survive.
@@FixingSoftware I found that companies where business pushes to deliver fast are very rarely efficient. If your business is not in decline, you can afford people refactoring stuff and you should allow them to do that without any constrains, because building poorly designed software creates not only tech debt but toxicity in the company, not to mention that it encourages taking shortcuts. Eventually if the software written degrades beyond a point, all good engineers will leave as they get tired of working in such conditions and you will be stuck in the low efficiency zone forever, I've personally seen a few companies failing their business this way.
@D4no00 that’s a good point about the state of the business. I’ve also seen it in low margin businesses. Like in private equity situations where excess profits are siphoned and returned to the holding company shareholders, vs being re-invested.
This nails a lot of the problems.
Your videos deserve an order of magnitude or 2 more in terms of views. Really high quality content!
@MFTGShane appreciate the kinds words! Helps if you share but obviously only if you want to.
@@FixingSoftware shared on LI, this will definitely help someone in my network.
@MFTGShane much appreciated! you can tag me in your share as well and I can answer questions or make clarifications, this is me on LI:
www.linkedin.com/in/benjaminrthorp/
> what is the solution
> we don't have leader that can modelize complex-systems
Here the start of a solution:
- find and encourage social-skilled developers to become manager and in leadership position while providing training
- prevent non-techies in leadership positions that manage software development, slowly replace them
- be able to visualize your domains and systems, if you can't, then you either over-engineered your codebase OR badly designed it (to be too complex)
Also what helped (in my exp) with predictability:
- learn DDD and EDA
- use documentation tools, visualization tools, comprehensible monitoring tools
- avoid splitting your codebase too much into too much services
Great video as usual, your opinions are highly appreciated!
this is great, would love to work on a project together!
I've worked in a company where this was in place and it worked greatly! You have folk that interacts with the client and comes up with the requirements (yet still have a good understanding of how technically this should work) and you have some very skilled and socially apt software developers, that not only understand in detail a part of the business, but can also come with a solution to the problem on their own. Each of them work in cooperation to achieve a result, as there is no chain of command that would allow one or the other to take the decision alone.
I'm really embarrassed about the processes at my current work, as it is exactly the opposite. Total lack of any form of documentation (both technical and from business side), untested projects, using services + shared global storage (I guess they missed the part of data owning when they've read the definition of microservices). Their focus is on delivering features, however I can easily say that the rate they deliver features is at least 10x slower and more painful than the company mentioned above.
@D4no00 yeah sometimes speed is an illusion because of the accumulation of undone work and tech debt. It slows everyone down. And it doesn’t take long for that to happen.
I think predictability has a lot of value. If my team is relatively good at estimation, that means they have reduced the amount of uncertainty in the system to the point that they can deliver consistently, which I think is often a sign of a good engineering manager. I like having that predictability on my team because it reduces the risk of giving an incorrect estimate and then having to work long hours to hit the incorrect date.
It’s definitely a trade off though. If you want more predictability from a team, then the team has to work in a more rigid fashion. Sometimes that’s bad, and sometimes it’s good (large cross team projects). I think some companies make the mistake of thinking that it always has to be one way or the other (especially if they make everything rigid).
Once again, well said. My issue isn’t with predictability itself, hopefully that was clear.
It’s the negative downstream consequences of optimizing solely for predictability. Yes an engineering manager who gets the multitude of ways predictably can be achieved, without killing the longer term sustainability of the team, they’re the keepers.
To play devil’s advocate: if a team is encouraged to have accurate estimates, might that incentivize deviant corner cutting behavior?
The "add more lanes creates congestion" is a really poor example. What actually happened there is that with more lanes, more people got served, even if it's at the same level of quality as before; -- as previously these people would not even attempt to get to where they want to.
Thanks for the comment. That’s partially true but regardless, it still paradoxically resulted in more congestion. It’s similar to how speed control can actually increase throughput in traffic. It’s a paradoxical non-intuitive result.
There’s a similar paradox with electronic devices. The more energy efficient they become, demand for them increases and the more electricity end up being used.
The video is choppy, it’s distracting and hard to watch
choppy as in the actual audio and video is cutting in and out? Or the content itself is choppy?
Ok yeah I see it. Thanks. I accidentally had my phone connected through Bluetooth instead of USB for this video 😩