3 ms·

> it have been divided in more that 25 files that hold 3 or 4 lines of code at most, with so many abstraction layers that it's impossible for the best of us to

> it have been divided in more that 25 files that hold 3 or 4 lines of code at most, with so many abstraction layers that it's impossible for the best of us to follow in one go. When you put engineers in charge you get overengineering and when you put managers you get underengineering. Is there a way out?

oscarcp 5y ago
At the moment, there's no way out, plannign stipulates that all our microservices must be rewritten to accomodate this super abstract DDD design (and youy're right, it was an engineer who created our current layout)
deleted 5y ago
[deleted]
tragomaskhalos 5y ago
This is so true, and has been forever. In the early 90s I worked on a system where you couldn't just write structs, rather you had to submit their definition to a guy who entered the details into a database, and there was a daily run to generate the C header files from that database. To this day I'm convinced the only reason it was done this way was that it could be done this way.
- macando 5y ago
  It's an over-reliance on ceremony. On some days I think it's a character trait.
- lgvld 5y ago
  Ouch! Crazy ;-)
deleted 5y ago
[deleted]
mytailorisrich 5y ago
> When you put engineers in charge you get overengineering This means you picked the wrong engineers. An engineer's job and skill is to be able to make this sort of call. The same goes with managers or any other role. So the way out is always to carefully select experienced, competent, no nonsense people.
andi999 5y ago
Getting experienced senior engineers, probably they have seen both; and in the best case they have worked on a middle ground project so they experienced how to do it and how not to do it.
- macando 5y ago
  Experienced and exposed to areas outside their main expertise so they are well rounded and pragmatic.
- moonchrome 5y ago
  I think you need to have a few of those "I've use this pattern and had to stay up 24 hours to meet a deadline because shit was way too complicated for the delivered value" to instil a healthy fear of overcomplicating solutions. I've worked with developers with 5+ years of experience that haven't went trough that (either corporate culture allowed them to deliver minimum value in 5 days or jumping projects before it gets to the WTF stage of complexity). It's hard to learn if you never get burned.
rapnie 5y ago
> When you put engineers in charge you get overengineering and when you put managers you get underengineering. Is there a way out? The whole idea is to bring them together "in the same room" and allow common understanding of the domain so they stay on the same page throughout the project. Then they'll do each what they are best at (managers whip up glossy slides, and devs crank out reams of code ;)

oscarcp 5y ago

At the moment, there's no way out, plannign stipulates that all our microservices must be rewritten to accomodate this super abstract DDD design (and youy're right, it was an engineer who created our current layout)

deleted 5y ago

[deleted]

tragomaskhalos 5y ago

This is so true, and has been forever. In the early 90s I worked on a system where you couldn't just write structs, rather you had to submit their definition to a guy who entered the details into a database, and there was a daily run to generate the C header files from that database. To this day I'm convinced the only reason it was done this way was that it could be done this way.

macando 5y ago
It's an over-reliance on ceremony. On some days I think it's a character trait.
lgvld 5y ago
Ouch! Crazy ;-)

deleted 5y ago

[deleted]

mytailorisrich 5y ago

> When you put engineers in charge you get overengineering This means you picked the wrong engineers. An engineer's job and skill is to be able to make this sort of call. The same goes with managers or any other role. So the way out is always to carefully select experienced, competent, no nonsense people.

andi999 5y ago

Getting experienced senior engineers, probably they have seen both; and in the best case they have worked on a middle ground project so they experienced how to do it and how not to do it.

macando 5y ago
Experienced and exposed to areas outside their main expertise so they are well rounded and pragmatic.
moonchrome 5y ago
I think you need to have a few of those "I've use this pattern and had to stay up 24 hours to meet a deadline because shit was way too complicated for the delivered value" to instil a healthy fear of overcomplicating solutions. I've worked with developers with 5+ years of experience that haven't went trough that (either corporate culture allowed them to deliver minimum value in 5 days or jumping projects before it gets to the WTF stage of complexity). It's hard to learn if you never get burned.

rapnie 5y ago

> When you put engineers in charge you get overengineering and when you put managers you get underengineering. Is there a way out? The whole idea is to bring them together "in the same room" and allow common understanding of the domain so they stay on the same page throughout the project. Then they'll do each what they are best at (managers whip up glossy slides, and devs crank out reams of code ;)