6 ms·

> But in the world of the factory factory factory, the apprentice carpenter (who really just wanted to drive a few nails) is now faced with trying to understand

> But in the world of the factory factory factory, the apprentice carpenter (who really just wanted to drive a few nails) is now faced with trying to understand the gargantuan complexity of the factory factory factory. Sometimes I wonder if that's the point of all this complexity. (EDIT: I mean really excessive complexity as alluded to in the article with factory factory factories, or 100 microservices all in different programming languages just for a website (true story)) I mean who actually gets to decide what sort of approach to use, and what are their incentives? The senior in the team is in charge of deciding what approach to use. The senior's (personal) objective is not to get fired, maintain their position as the most senior so they can get the payrises and promotions, etc. So they sort of have an incentive to choose something that is going to be easier to understand for them than for others e.g. juniors, a kind of "moat" to protect their position of power and high salary getting attacked by lower paid juniors who don't yet have the experience to understand complex abstractions over manual tasks they haven't yet done themselves. I mean obviously that's not a kind thing for a senior to do, nor something that's in their employer's interest, but on the other hand it is rational given their incentives...

josephg 3y ago
Senior here. I think this is an overly cynical take. You want to pick a set of tools which will help you get the job at hand done most effectively. It’s often easier and cheaper to hire or train a team to use a framework or library than it is to reimplement the functionality that library provides from scratch. Eg, if I was building a big single page app, I’d rather use react than reimplement react’s functionality, badly, on top of jquery or something. Projects last years. An engineer with solid fundamental knowledge can get up to speed with most of these tools and libraries in a few days. The math usually checks out to make them worth using. But I still acknowledge your point. There are plenty of terrible senior engineers out there making bad choices on tools. And there is a lot of damage a bad tool choice can make to a project. Libraries and frameworks rarely tell you when they’re buggy messes. And coworkers rarely tell you when learning some new tool feels beyond them. So I’m sure there’s plenty of projects out there trying to use fancy tools which have a net negative effect on team productivity.
- adrianmsmith 3y ago
  You're absolutely right, there is definitely an optimal level of framework usage, for the reasons you state. I suppose what I meant was really excessive framework usage, the type of which is alluded to in the original article with the factory factory factories etc. I shall edit my comment to clarify that.
  - josephg 3y ago
    Yeah fair enough. The whole factory factory factory thing feels separate to me. I think of it as a disastrous, productivity destroying meme that spreads through words like “hidden implementation” and “one interface, multiple implementations”. You don’t to be a senior to be vulnerable to the mind virus, though once it gets into the heads of your senior engineers your whole team or company can be in peril. The disease has claimed entire programming communities with its cloying rot. (Dare I say the J-word and invoke its wrath?). As an individual, it can take years to recover from these ideas. Some poor hacker souls never recover.
    - sfn42 3y ago
      Sounds like you haven't really understood the benefits of polymorphism, encapsulation etc. The general idea is to compartmentalize your logic and only expose the important parts like if you need to generate pdfs from html you may need to use a lot of moving parts to make that happen but you hide all of it and only expose an interface with a single action that takes html and returns a pdf. If you later need to change how you do the pdf generation you can freely mess with the internals of the system any way you want because consumers have no dependencies on any of it. If you need to rewrite it from scratch you can implement the same interface and none of the code using it needs to change at all.
      - BlargMcLarg 3y ago
        Not everything needs a hyper-abstracted solution. Most people suck at writing neat abstractions, so they spend an excessive amount of time writing shoddy solutions which no one really wants to deal with but there's a soft, begrudging agreement to use them anyway while the business sees no value in having their devs rewrite it. This goes double when you step into the world of microservices, where you now have another layer where you can easily swap the implementation behind the interface. Surely years of old Java shops with absolutely dreadful software architecture, sloppily copied from literature, showcase the path to hell being paved by good intentions.
weinzierl 3y ago
What you wrote matches my experience. Not that I approve of it, of course, but it is often like that. "The senior in the team is in charge of deciding what approach to use." The only thing I'd like to add is that the senior is rarely free in their decision. It is often an unspoken choice dictated by culture and upper management. (Ironically it's worse in companies with technically apt management.) You work in a Java shop, everything else than the couple of standard Java frameworks will be an uphill battle and you bear all the risk to get your problems blamed on your framework choice. This is not an excuse of course, but unfortunately our choices are rarely by technical merit alone.
- tough 3y ago
  Choose the tool you know is the best answer tho.
  - tracker1 3y ago
    That assumes you and everyone you work with want to use that tool... you can write COBOL in any language, you won't always like the result.
  - BuckRogers 3y ago
    Not only that, but let’s face it, a popular Java framework is going to be far more stable and long lived for years to come compared to what someone grabs off GitHub. A business sticks around for a long time. Some guy building with the flavor of the month is a big problem.
- josephcsible 3y ago
  That's a really common trend today even outside of frameworks and software development. It's super common for people to make a worse choice when they know a better one is right in front of them, because blame if the worse choice fails will be diffused, but blame if the better choice fails will be placed entirely on them.
whstl 3y ago
Thing is, I've had non-Seniors-Developers asking for more complex stuff as often as I had seniors doing it. It's cultural. Complexity is often part of developer culture, period. I've even had a non-technical CEO asking to use Angular around 2013-2014. Developer culture is leaking. Also a lot of accidental complexity comes from the business/staffing side. So, you need to have 200 developers because some high-up said so? Better jump on that Kubernetes and Microservices train. Are the business processes more complex than they have to be because of inertia and disorganization? Let's spend a million bucks customizing that off-the-shelf ERP system.
- Aerbil313 3y ago
  > Complexity is often part of developer culture, period. I’d even say no one seems to realize that the default tendency for a developer is to complexify. One either needs to learn to keep things simple by experience or is forced to it by constraints like time.
sanitycheck 3y ago
I'm even more cynical than you. The senior's (personal) objective is to add fashionable buzzwords to the resume/CV so in a year they can hop to another company and get paid 20% more. You get a pay rise and a promotion a lot quicker by changing jobs than sticking around. No Kubernetes experience? Just unnecessarily add Kubernetes to your current project. Now look for that Kubernetes job! The worst thing is, this is totally rational behaviour.
- Aeolun 3y ago
  I dunno, I just want an environment in which I can deliver the features biz requests without fear or fuzz. Right now it’s just firefighting every second of the day.
  - sanitycheck 3y ago
    Perhaps that's what we should call ourselves, instead of "engineers". I suppose that'll only annoy the real firefighters instead though.
Aeolun 3y ago
No, I choose the technology and/or fundamentals that the juniors will have to learn if they want to level up as a developer. The best way to get them to work the right way is to use a framework that incentivizes it. If doing things wrong is made harder, and doing things right is made easy, everyone wins.
- hinkley 3y ago
  Until they’re second system and they find out why you insisted on things.
noobermin 3y ago
Are you sure it isn't their employer's interest? What if the company sells training or licenses for the framework? Then it definitely is in their interest. There are obvious examples out there.
notjoemama 3y ago
Senior here. Where I work, everyone has the authority of the position below them. The middle management above my team decides language, framework, and architecture. They were hired from much larger companies, so naturally they just know more. I think our 10mil/yr company doesn't need the complexity of a 100mil/yr solution because we're not Amazon and we're never going to be Amazon. But, we now we have dozens of lambda functions in multiple languages with multiple configs designed in different ways deploying from multiple processes from multiple repositories. Our team is having a hard time changing and fixing anything because the cognitive overhead nears the limit of human capability. I was told "off the record" its because we didn't execute their vision the right way. I'm starting to think I work in a toxic environment.
- pnt12 3y ago
  Yeah that's quite toxic. If the project is successful, the top level gets the praise for the vision. If it doesn't, the team gets the blame for lousy execution. The responsible for executing should have a day in a lot more things, else it's gonna be a blame game.
  - BuckRogers 3y ago
    You had it right with your first statement. Blame always goes to the top. They don’t do anything, making decisions is easy, compared to actually getting it done on a deadline. Get all the credit when things go well, deserve all the blame when things don’t. Because it’s also poor management when your workers aren’t properly managed and thus don’t properly build out your vision.
- formulathree 3y ago
  Intelligence won't matter here. Software design doesn't have a formal theory that defines optimal design and there isn't any empirical evidence either. We know the shortest distance between two points because we have a formal theory that defines it. Because software design has no such thing, everyone is making shit up. Doesn't matter how intelligent you are. If the thing that's being designed can't be quantified it's the wild west. Those brains are focused on optimizing things we have no idea how optimize and things we can't even measure.

josephg 3y ago

Senior here. I think this is an overly cynical take. You want to pick a set of tools which will help you get the job at hand done most effectively. It’s often easier and cheaper to hire or train a team to use a framework or library than it is to reimplement the functionality that library provides from scratch. Eg, if I was building a big single page app, I’d rather use react than reimplement react’s functionality, badly, on top of jquery or something. Projects last years. An engineer with solid fundamental knowledge can get up to speed with most of these tools and libraries in a few days. The math usually checks out to make them worth using. But I still acknowledge your point. There are plenty of terrible senior engineers out there making bad choices on tools. And there is a lot of damage a bad tool choice can make to a project. Libraries and frameworks rarely tell you when they’re buggy messes. And coworkers rarely tell you when learning some new tool feels beyond them. So I’m sure there’s plenty of projects out there trying to use fancy tools which have a net negative effect on team productivity.

adrianmsmith 3y ago
You're absolutely right, there is definitely an optimal level of framework usage, for the reasons you state. I suppose what I meant was really excessive framework usage, the type of which is alluded to in the original article with the factory factory factories etc. I shall edit my comment to clarify that.
- josephg 3y ago
  Yeah fair enough. The whole factory factory factory thing feels separate to me. I think of it as a disastrous, productivity destroying meme that spreads through words like “hidden implementation” and “one interface, multiple implementations”. You don’t to be a senior to be vulnerable to the mind virus, though once it gets into the heads of your senior engineers your whole team or company can be in peril. The disease has claimed entire programming communities with its cloying rot. (Dare I say the J-word and invoke its wrath?). As an individual, it can take years to recover from these ideas. Some poor hacker souls never recover.
  - sfn42 3y ago
    Sounds like you haven't really understood the benefits of polymorphism, encapsulation etc. The general idea is to compartmentalize your logic and only expose the important parts like if you need to generate pdfs from html you may need to use a lot of moving parts to make that happen but you hide all of it and only expose an interface with a single action that takes html and returns a pdf. If you later need to change how you do the pdf generation you can freely mess with the internals of the system any way you want because consumers have no dependencies on any of it. If you need to rewrite it from scratch you can implement the same interface and none of the code using it needs to change at all.
    - BlargMcLarg 3y ago
      Not everything needs a hyper-abstracted solution. Most people suck at writing neat abstractions, so they spend an excessive amount of time writing shoddy solutions which no one really wants to deal with but there's a soft, begrudging agreement to use them anyway while the business sees no value in having their devs rewrite it. This goes double when you step into the world of microservices, where you now have another layer where you can easily swap the implementation behind the interface. Surely years of old Java shops with absolutely dreadful software architecture, sloppily copied from literature, showcase the path to hell being paved by good intentions.

weinzierl 3y ago

What you wrote matches my experience. Not that I approve of it, of course, but it is often like that. "The senior in the team is in charge of deciding what approach to use." The only thing I'd like to add is that the senior is rarely free in their decision. It is often an unspoken choice dictated by culture and upper management. (Ironically it's worse in companies with technically apt management.) You work in a Java shop, everything else than the couple of standard Java frameworks will be an uphill battle and you bear all the risk to get your problems blamed on your framework choice. This is not an excuse of course, but unfortunately our choices are rarely by technical merit alone.

tough 3y ago
Choose the tool you know is the best answer tho.
- tracker1 3y ago
  That assumes you and everyone you work with want to use that tool... you can write COBOL in any language, you won't always like the result.
- BuckRogers 3y ago
  Not only that, but let’s face it, a popular Java framework is going to be far more stable and long lived for years to come compared to what someone grabs off GitHub. A business sticks around for a long time. Some guy building with the flavor of the month is a big problem.
josephcsible 3y ago
That's a really common trend today even outside of frameworks and software development. It's super common for people to make a worse choice when they know a better one is right in front of them, because blame if the worse choice fails will be diffused, but blame if the better choice fails will be placed entirely on them.

whstl 3y ago

Thing is, I've had non-Seniors-Developers asking for more complex stuff as often as I had seniors doing it. It's cultural. Complexity is often part of developer culture, period. I've even had a non-technical CEO asking to use Angular around 2013-2014. Developer culture is leaking. Also a lot of accidental complexity comes from the business/staffing side. So, you need to have 200 developers because some high-up said so? Better jump on that Kubernetes and Microservices train. Are the business processes more complex than they have to be because of inertia and disorganization? Let's spend a million bucks customizing that off-the-shelf ERP system.

Aerbil313 3y ago
> Complexity is often part of developer culture, period. I’d even say no one seems to realize that the default tendency for a developer is to complexify. One either needs to learn to keep things simple by experience or is forced to it by constraints like time.

sanitycheck 3y ago

I'm even more cynical than you. The senior's (personal) objective is to add fashionable buzzwords to the resume/CV so in a year they can hop to another company and get paid 20% more. You get a pay rise and a promotion a lot quicker by changing jobs than sticking around. No Kubernetes experience? Just unnecessarily add Kubernetes to your current project. Now look for that Kubernetes job! The worst thing is, this is totally rational behaviour.

Aeolun 3y ago
I dunno, I just want an environment in which I can deliver the features biz requests without fear or fuzz. Right now it’s just firefighting every second of the day.
- sanitycheck 3y ago
  Perhaps that's what we should call ourselves, instead of "engineers". I suppose that'll only annoy the real firefighters instead though.

Aeolun 3y ago

No, I choose the technology and/or fundamentals that the juniors will have to learn if they want to level up as a developer. The best way to get them to work the right way is to use a framework that incentivizes it. If doing things wrong is made harder, and doing things right is made easy, everyone wins.

hinkley 3y ago
Until they’re second system and they find out why you insisted on things.

noobermin 3y ago

Are you sure it isn't their employer's interest? What if the company sells training or licenses for the framework? Then it definitely is in their interest. There are obvious examples out there.

notjoemama 3y ago

Senior here. Where I work, everyone has the authority of the position below them. The middle management above my team decides language, framework, and architecture. They were hired from much larger companies, so naturally they just know more. I think our 10mil/yr company doesn't need the complexity of a 100mil/yr solution because we're not Amazon and we're never going to be Amazon. But, we now we have dozens of lambda functions in multiple languages with multiple configs designed in different ways deploying from multiple processes from multiple repositories. Our team is having a hard time changing and fixing anything because the cognitive overhead nears the limit of human capability. I was told "off the record" its because we didn't execute their vision the right way. I'm starting to think I work in a toxic environment.

pnt12 3y ago
Yeah that's quite toxic. If the project is successful, the top level gets the praise for the vision. If it doesn't, the team gets the blame for lousy execution. The responsible for executing should have a day in a lot more things, else it's gonna be a blame game.
- BuckRogers 3y ago
  You had it right with your first statement. Blame always goes to the top. They don’t do anything, making decisions is easy, compared to actually getting it done on a deadline. Get all the credit when things go well, deserve all the blame when things don’t. Because it’s also poor management when your workers aren’t properly managed and thus don’t properly build out your vision.
formulathree 3y ago
Intelligence won't matter here. Software design doesn't have a formal theory that defines optimal design and there isn't any empirical evidence either. We know the shortest distance between two points because we have a formal theory that defines it. Because software design has no such thing, everyone is making shit up. Doesn't matter how intelligent you are. If the thing that's being designed can't be quantified it's the wild west. Those brains are focused on optimizing things we have no idea how optimize and things we can't even measure.