4 ms·

Works great if you are a single developer owning an isolated piece of the stack. Doesn't work so great if you need to collaborate with others to maximize your

Works great if you are a single developer owning an isolated piece of the stack. Doesn't work so great if you need to collaborate with others to maximize your productivity.

TeMPOraL 10y ago
Collaboration is overrated. IMO the biggest purpose of a good software architecture is to minimize the amount of required collaboration between programmers. Each gets a well-defined place to work on and focuses on that, instead of constantly discussing how to build every single class. The latter gives you a diffused design in which nobody understands any part of it. The former gives you design in which, while single person may understand all of it (as it always is due to fractal complexity), every piece of that design is fully understood by someone.
- dasil003 10y ago
  You speak as if the only work that exists is cathedral software development. Look, I get you, I've been a professional programmer for a couple decades now, and hobbyist for another decade on top of that. But there are so many times when it helps to have a conversation with someone. Maybe you're team is not all senior level architects, maybe someone is working with tech someone else on the team understands better, maybe the designer is delivering an unworkable visual design and the engineer is implementing it by making tradeoffs that result in a terrible UX, maybe the programmer is going into a cave polishing his own micro-architecture without regard to what is useful and good use of time for the team as a whole. The point is, it's not wise to cultivate a worldview where you hold your own knowledge and experience on a pedestal above everyone else. The things which a great team can build will always surpass what a great individual can create, and a bunch of great individuals operating independently without sufficient collaboration does not a great team make. Maybe collaboration is overrated by clueless MBAs, but I'm not a clueless MBA, so don't make that straw man argument to me.
  - TeMPOraL 10y ago
    I agree with what you wrote here, but I don't think having a good team requires perfectly synchronizing their work schedule, as long as it somewhat overlaps most of the time. There are many times when you want, or need to sit down with your teammates and discuss stuff - design the overall architecture, brainstorm particular solution, troubleshoot a bug - but most of the actual coding work is done in silence and requires focus. And this work takes most of the actual productive time, so it doesn't make sense to synchronize the entire schedules just for the brief moments of direct, synchronous collaboration (quite a lot of teamwork can - and is done best - asynchronously, e.g. via e-mail). > Maybe collaboration is overrated by clueless MBAs, but I'm not a clueless MBA, so don't make that straw man argument to me. Apologies. I definitely didn't want my comment to sound personal in any way.
    - dasil003 10y ago
      I'm a firm believer in flex time and heads-down time. Heck, I led an engineering team from 2 engineers (one of them being me) up to an engineering/product team of 25 with more nationalities on the team than employees (if that doesn't compute remember dual-citizenship), and distributed across 9-10 countries. I have successfully scheduled a three-person call between Melbourne, San Francisco and Berlin. All this by way of saying: I have fully tested the philosophy that you should hire the absolute best engineers you can, no matter where they are based and when they want to work. For the right individuals with the proper workloads it's definitely worth it. But we shouldn't pretend it doesn't come with real tradeoffs. A story to illustrate my point: I had my best video engineer in London, and my best ops guy in Seattle (and he didn't like waking up early). Even though these guys could do 95% of their work independently, there were times when they had to sort out hairy issues related to bugs or edge cases in 3rd party software. There was no way to easily shove it on one of their plates, the bottom line is it requires both their expertise. We nearly burnt out the first guy by making him stay up until 4am in order to get the necessary collab time. These are juniors either, but it still was a real issue that cost a significant amount of productivity and morale. (PS I upvoted you as I don't see why you deserve downvotes)
- vvanders 10y ago
  So I'm assuming you write all your code with zero dependencies then?
  - TeMPOraL 10y ago
    No, but I keep my dependencies isolated in a well-defined way, and I provide well-defined interfaces for people who want to depend on my stuff. That's basically software architecture 101 (modularization), and it serves exactly this purpose.

Works great if you are a single developer owning an isolated piece of the stack. Doesn't work so great if you need to collaborate with others to maximize your productivity.

TeMPOraL 10y ago

Collaboration is overrated. IMO the biggest purpose of a good software architecture is to minimize the amount of required collaboration between programmers. Each gets a well-defined place to work on and focuses on that, instead of constantly discussing how to build every single class. The latter gives you a diffused design in which nobody understands any part of it. The former gives you design in which, while single person may understand all of it (as it always is due to fractal complexity), every piece of that design is fully understood by someone.

dasil003 10y ago
You speak as if the only work that exists is cathedral software development. Look, I get you, I've been a professional programmer for a couple decades now, and hobbyist for another decade on top of that. But there are so many times when it helps to have a conversation with someone. Maybe you're team is not all senior level architects, maybe someone is working with tech someone else on the team understands better, maybe the designer is delivering an unworkable visual design and the engineer is implementing it by making tradeoffs that result in a terrible UX, maybe the programmer is going into a cave polishing his own micro-architecture without regard to what is useful and good use of time for the team as a whole. The point is, it's not wise to cultivate a worldview where you hold your own knowledge and experience on a pedestal above everyone else. The things which a great team can build will always surpass what a great individual can create, and a bunch of great individuals operating independently without sufficient collaboration does not a great team make. Maybe collaboration is overrated by clueless MBAs, but I'm not a clueless MBA, so don't make that straw man argument to me.
- TeMPOraL 10y ago
  I agree with what you wrote here, but I don't think having a good team requires perfectly synchronizing their work schedule, as long as it somewhat overlaps most of the time. There are many times when you want, or need to sit down with your teammates and discuss stuff - design the overall architecture, brainstorm particular solution, troubleshoot a bug - but most of the actual coding work is done in silence and requires focus. And this work takes most of the actual productive time, so it doesn't make sense to synchronize the entire schedules just for the brief moments of direct, synchronous collaboration (quite a lot of teamwork can - and is done best - asynchronously, e.g. via e-mail). > Maybe collaboration is overrated by clueless MBAs, but I'm not a clueless MBA, so don't make that straw man argument to me. Apologies. I definitely didn't want my comment to sound personal in any way.
  - dasil003 10y ago
    I'm a firm believer in flex time and heads-down time. Heck, I led an engineering team from 2 engineers (one of them being me) up to an engineering/product team of 25 with more nationalities on the team than employees (if that doesn't compute remember dual-citizenship), and distributed across 9-10 countries. I have successfully scheduled a three-person call between Melbourne, San Francisco and Berlin. All this by way of saying: I have fully tested the philosophy that you should hire the absolute best engineers you can, no matter where they are based and when they want to work. For the right individuals with the proper workloads it's definitely worth it. But we shouldn't pretend it doesn't come with real tradeoffs. A story to illustrate my point: I had my best video engineer in London, and my best ops guy in Seattle (and he didn't like waking up early). Even though these guys could do 95% of their work independently, there were times when they had to sort out hairy issues related to bugs or edge cases in 3rd party software. There was no way to easily shove it on one of their plates, the bottom line is it requires both their expertise. We nearly burnt out the first guy by making him stay up until 4am in order to get the necessary collab time. These are juniors either, but it still was a real issue that cost a significant amount of productivity and morale. (PS I upvoted you as I don't see why you deserve downvotes)
vvanders 10y ago
So I'm assuming you write all your code with zero dependencies then?
- TeMPOraL 10y ago
  No, but I keep my dependencies isolated in a well-defined way, and I provide well-defined interfaces for people who want to depend on my stuff. That's basically software architecture 101 (modularization), and it serves exactly this purpose.