8 ms·

As I had to work more with teams and then supervising teams I changed the abstractions I value from when I was programming solo: Now I care less about my projec

by Iv 9y ago

As I had to work more with teams and then supervising teams I changed the abstractions I value from when I was programming solo: Now I care less about my project's function than the structure of the team. There is a saying that any complex project will end up mimicking the communication structure of your organization. I must confess I thought it was silly until I realized it happened to us. I now favor code that has a lot of independent modules that can have hacky inner code but that must have clear, explicit and preferably simple interfaces. The project's manager role is to design these interfaces and has the last work on their implementation. This is a bit the Unix way. Every module has to do one thing (and optionally do it well). This allows veteran programmers who know all the subtleties of the programming language to collaborate with rookie programmers who may write okay-ish modules that we may have to rewrite later but that work well enough. It also allows programmers, these very territorial beasts, to have their own little realms they control and where they are acknowledged. It helps non-tech managers understand who has to be assigned on different issues and evolutions.

Clubber 9y ago
Absolutely this. Some people think silos are bad, but it absolutely works brilliantly in terms of team cohesion. No stepping on toes. Few arguments because everyone is responsible for their own stuff. No nitpicking over irrelevant style preferences. Pride in ownership, self accountability, thoughtful decision making (mostly). All this leads to good working relationships that come in handy when cross-realm issues arise. Every place that had a great team did it this way.
- curun1r 9y ago
  Until someone goes on vacation, their area blows up and everyone else has to panic fix some code that they've never seen before. As a manager, one of my main jobs is ensuring that the team's bus number is always above 1 and scheduling vacation time so that we always have full coverage should stuff go down. There's a huge difference between a silo and giving someone responsibility for driving the design of a component/module. The latter is great, the former is a failure of the team's leadership. You can still get pride of having built something even if you're building it for the team and, through code review, the team is accepting ownership. But individual ownership of key pieces of code has been responsible for most of the top-10 shit storms I've seen in my career and I'm never letting it happen on a team I manage ever again.
  - humanrebar 9y ago
    There are infinite ways to organize teams so your concerns are addressed. For example, you can have primary, secondary, and backup developers for each component of the system. That keeps you bus factor down and makes it more clear what the progression of responsibility looks like. But, absolutely, a lack of peer review, authentic feedback, and general teamwork causes all sorts of issues in so many ways.
    - vog 9y ago
      > That keeps you bus factor down Small nitpick: I assume to wanted to say this keeps your bus factor up.
      - humanrebar 9y ago
        Oh. Right! Thanks.
  - Iv 9y ago
    You are right that this is something to consider. In my case the "realm" think was emergent and not enforced at all, but it was a bit implicit that if possible, you ask Bill his advice before rewriting a function of his model. The lead dev was still nosing around everywhere and had authority to call a piece of code defective and impose a rewrite. One of the important function of the project manager is also to communicate clearly with upper management about what the team is and can do. We were working on a product that was not deployed yet and our priority was to release a functioning version ASAP, so redundancy was irrelevant. We had n features to develop, assigned to various developer. When one developer is on holiday, their features did not advance. We worked around it thanks to our modular architecture. It meant that sometimes, <urgent but usually irrelevant feature> was impossible to code before <meeting with potential client next week>. I scheduled or denied those. This team and project structure is optimized for fast development with an heterogeneous team, not for reactivity.
  - Klockan 9y ago
    > As a manager, one of my main jobs is ensuring that the team's bus number is always above 1 Bus number of 1 would be nice to experience for once, I have yet to see a team with a bus number above 0...
humanrebar 9y ago
> It also allows programmers, these very territorial beasts... They should be. It's difficult to get quality experience if you're only designing by committee or executing on someone else's designs. In other words, carving out niches for people is a great way to get your engineers to level up from junior to senior to beyond. They should, hopefully, appreciate the clarity in career progression also. They should be able to see themselves making bigger and more important decisions as they prove themselves.
nickbauman 9y ago
> allows programmers, these very territorial beasts, to have their own little realms they control My 25 years of programming experience says otherwise. The only place where this works is with good(ish) programmers who are assholes and must have their huge, fragile egos stroked or they'll throw a diva fit. I don't hire or work with those people anymore. Neither should you. Joint code ownership produces better code because everyone wrote some of it and nothing is mysterious.
- humanrebar 9y ago
  > Joint code ownership produces better code because everyone wrote some of it and nothing is mysterious. I don't think it's one or the other. You need people to be able to jump in and contribute and improve things. But you also need responsibility for the code as a body of work. If everyone with commit access owns the code, nobody does. As time goes on and it's a snarl of spaghetti code and slapdash design, it turns out it was nobody's job to make sure that didn't happen.
  - nickbauman 9y ago
    What you said is contradictory. Jumping in and contributing and improving things happens when everyone is encouraged to change the code anytime. When individuals get territorial is when it rots because people are afraid to touch that "other person's code."
    - humanrebar 9y ago
      That could happen. But if your technical leaders are rejecting patches for ego reasons, you need to correct that regardless of how you organize your code. Worst case, some people aren't cut out for technical leadership.
- Iv 9y ago
  I agree that my wording maybe gave a wrong idea about the strength of the "ownership". Code has to be readable and commented and peeking into each other code is welcomed, calling for help or reinforcement on a module is recommended. "Realms" is something that is unenforced and that emerges implicitly. On the other hand, joint code ownership leads to endless discussions about proper whitespace formating, variables naming and accessors. It leads to never-enforced style rules that no one likes nor follows. > I don't hire or work with those people anymore. Neither should you. If you are unable to work with some people by refusing to use a code architecture that would allow you to use them, does that really make you a superior project manager? Don't get me wrong, different projects call for different processes. You don't code a blog framework in PHP the same way you program an embedded medical device. In some cases it is a bad idea to give free reign to individuals. I simply notice that when it comes to abstracting your code, team structure and general project context is often more important than the project's function. In my case (non critical C# project with easily compartimentalizable functions with diverse team members of different skills, different maturity levels and a propensity to argue over minor formatting details) it meant isolated modules communicating through a well-defined API. The alternative would have been to fire half the team and make a nicer code in twice the time. Not what I was hired for.
TeMPOraL 9y ago
I believe so too, but it's not even that much a function of team structure. A proper design will have lots of places that are mostly self-contained at various levels of abstraction - more than people you have in your team. I believe work should be distributed among those boundaries, because it lets people agree on the interfaces and work mostly in isolation. Also, most of the time, small self-contained units of code are trivial to fix if the original developer goes under the bus, because small means any half-decent developer should be able to read the code[0] and understand it, and self-contained means you're not afraid to change things because you can easily track how the effect of your changes propagates. -- [0] - an activity that people often shy away from, or are afraid of. Can't for the love of God understand why.
- foota 9y ago
  Re: 0 sometimes I wish I could just be paid to read and understand code.
  - TeMPOraL 9y ago
    Unless one's in constant crunch mode, just hammering out whatever crap that makes tickets disappear, there's always time for that in programming. Often it's just jumping into a library method and looking around instead of opening a new browser tab and typing "how XYZ works stackoverflow".
  - boomlinde 9y ago
    Are you being paid per written line of code or something? I just can't think of a reason to believe as a programmer that your job responsibilities don't include reading and understanding code.
    - foota 9y ago
      They definitely do, but there's so many other things, and they come with all sorts of distractions. (I love my job, don't get me wrong)
stormbeta 9y ago
I refuse to work with people which such fragile egos, but I agree on the architecture. Having a lot of individual pieces that connect using simple, straightforward interfaces is much more flexible and maintainable in the long run - it's the same reasoning that draws people to microservices.
r3dk1ng 9y ago
You're talking about Conway's law.
vog 9y ago
> There is a saying that any complex project will end up mimicking the communication structure of your organization. I must confess I thought it was silly until I realized it happened to us. Is this necessarily a bad thing? I know this quote and it always made a lot of sense for me. But I never understood where exactly is the problem, and why one should go to great lengths to avoid this. Moreover, in this concrete example, isn't assigning modules to individual developers (as opposed to collective code ownership) essentially the same? i.e. structuring the code along the organization communication structure?
- AndrewDucker 9y ago
  They aren't saying it's bad. They're saying it happens. And that you need to be aware of that if you want your code to end up maintainable.
  - vog 9y ago
    What does it mean to "be aware" of this? What should one do differently from one would otherwise do?
    - speedplane 9y ago
      It means that poor communication among team members will lead to poor code, and likely a poor or late product.
WillReplyfFood 9y ago
I laughed at ascii-string protocolls- then i realized how great self-explaining interfaces are.
nradov 9y ago
Project managers usually shouldn't define interfaces between code modules. That's a design lead or architect responsibility.

by Iv 9y ago

Clubber 9y ago

Absolutely this. Some people think silos are bad, but it absolutely works brilliantly in terms of team cohesion. No stepping on toes. Few arguments because everyone is responsible for their own stuff. No nitpicking over irrelevant style preferences. Pride in ownership, self accountability, thoughtful decision making (mostly). All this leads to good working relationships that come in handy when cross-realm issues arise. Every place that had a great team did it this way.

curun1r 9y ago
Until someone goes on vacation, their area blows up and everyone else has to panic fix some code that they've never seen before. As a manager, one of my main jobs is ensuring that the team's bus number is always above 1 and scheduling vacation time so that we always have full coverage should stuff go down. There's a huge difference between a silo and giving someone responsibility for driving the design of a component/module. The latter is great, the former is a failure of the team's leadership. You can still get pride of having built something even if you're building it for the team and, through code review, the team is accepting ownership. But individual ownership of key pieces of code has been responsible for most of the top-10 shit storms I've seen in my career and I'm never letting it happen on a team I manage ever again.
- humanrebar 9y ago
  There are infinite ways to organize teams so your concerns are addressed. For example, you can have primary, secondary, and backup developers for each component of the system. That keeps you bus factor down and makes it more clear what the progression of responsibility looks like. But, absolutely, a lack of peer review, authentic feedback, and general teamwork causes all sorts of issues in so many ways.
  - vog 9y ago
    > That keeps you bus factor down Small nitpick: I assume to wanted to say this keeps your bus factor up.
    - humanrebar 9y ago
      Oh. Right! Thanks.
- Iv 9y ago
  You are right that this is something to consider. In my case the "realm" think was emergent and not enforced at all, but it was a bit implicit that if possible, you ask Bill his advice before rewriting a function of his model. The lead dev was still nosing around everywhere and had authority to call a piece of code defective and impose a rewrite. One of the important function of the project manager is also to communicate clearly with upper management about what the team is and can do. We were working on a product that was not deployed yet and our priority was to release a functioning version ASAP, so redundancy was irrelevant. We had n features to develop, assigned to various developer. When one developer is on holiday, their features did not advance. We worked around it thanks to our modular architecture. It meant that sometimes, <urgent but usually irrelevant feature> was impossible to code before <meeting with potential client next week>. I scheduled or denied those. This team and project structure is optimized for fast development with an heterogeneous team, not for reactivity.
- Klockan 9y ago
  > As a manager, one of my main jobs is ensuring that the team's bus number is always above 1 Bus number of 1 would be nice to experience for once, I have yet to see a team with a bus number above 0...

humanrebar 9y ago

> It also allows programmers, these very territorial beasts... They should be. It's difficult to get quality experience if you're only designing by committee or executing on someone else's designs. In other words, carving out niches for people is a great way to get your engineers to level up from junior to senior to beyond. They should, hopefully, appreciate the clarity in career progression also. They should be able to see themselves making bigger and more important decisions as they prove themselves.

nickbauman 9y ago

> allows programmers, these very territorial beasts, to have their own little realms they control My 25 years of programming experience says otherwise. The only place where this works is with good(ish) programmers who are assholes and must have their huge, fragile egos stroked or they'll throw a diva fit. I don't hire or work with those people anymore. Neither should you. Joint code ownership produces better code because everyone wrote some of it and nothing is mysterious.

humanrebar 9y ago
> Joint code ownership produces better code because everyone wrote some of it and nothing is mysterious. I don't think it's one or the other. You need people to be able to jump in and contribute and improve things. But you also need responsibility for the code as a body of work. If everyone with commit access owns the code, nobody does. As time goes on and it's a snarl of spaghetti code and slapdash design, it turns out it was nobody's job to make sure that didn't happen.
- nickbauman 9y ago
  What you said is contradictory. Jumping in and contributing and improving things happens when everyone is encouraged to change the code anytime. When individuals get territorial is when it rots because people are afraid to touch that "other person's code."
  - humanrebar 9y ago
    That could happen. But if your technical leaders are rejecting patches for ego reasons, you need to correct that regardless of how you organize your code. Worst case, some people aren't cut out for technical leadership.
Iv 9y ago
I agree that my wording maybe gave a wrong idea about the strength of the "ownership". Code has to be readable and commented and peeking into each other code is welcomed, calling for help or reinforcement on a module is recommended. "Realms" is something that is unenforced and that emerges implicitly. On the other hand, joint code ownership leads to endless discussions about proper whitespace formating, variables naming and accessors. It leads to never-enforced style rules that no one likes nor follows. > I don't hire or work with those people anymore. Neither should you. If you are unable to work with some people by refusing to use a code architecture that would allow you to use them, does that really make you a superior project manager? Don't get me wrong, different projects call for different processes. You don't code a blog framework in PHP the same way you program an embedded medical device. In some cases it is a bad idea to give free reign to individuals. I simply notice that when it comes to abstracting your code, team structure and general project context is often more important than the project's function. In my case (non critical C# project with easily compartimentalizable functions with diverse team members of different skills, different maturity levels and a propensity to argue over minor formatting details) it meant isolated modules communicating through a well-defined API. The alternative would have been to fire half the team and make a nicer code in twice the time. Not what I was hired for.

TeMPOraL 9y ago

I believe so too, but it's not even that much a function of team structure. A proper design will have lots of places that are mostly self-contained at various levels of abstraction - more than people you have in your team. I believe work should be distributed among those boundaries, because it lets people agree on the interfaces and work mostly in isolation. Also, most of the time, small self-contained units of code are trivial to fix if the original developer goes under the bus, because small means any half-decent developer should be able to read the code[0] and understand it, and self-contained means you're not afraid to change things because you can easily track how the effect of your changes propagates. -- [0] - an activity that people often shy away from, or are afraid of. Can't for the love of God understand why.

foota 9y ago
Re: 0 sometimes I wish I could just be paid to read and understand code.
- TeMPOraL 9y ago
  Unless one's in constant crunch mode, just hammering out whatever crap that makes tickets disappear, there's always time for that in programming. Often it's just jumping into a library method and looking around instead of opening a new browser tab and typing "how XYZ works stackoverflow".
- boomlinde 9y ago
  Are you being paid per written line of code or something? I just can't think of a reason to believe as a programmer that your job responsibilities don't include reading and understanding code.
  - foota 9y ago
    They definitely do, but there's so many other things, and they come with all sorts of distractions. (I love my job, don't get me wrong)

stormbeta 9y ago

I refuse to work with people which such fragile egos, but I agree on the architecture. Having a lot of individual pieces that connect using simple, straightforward interfaces is much more flexible and maintainable in the long run - it's the same reasoning that draws people to microservices.

r3dk1ng 9y ago

You're talking about Conway's law.

vog 9y ago

> There is a saying that any complex project will end up mimicking the communication structure of your organization. I must confess I thought it was silly until I realized it happened to us. Is this necessarily a bad thing? I know this quote and it always made a lot of sense for me. But I never understood where exactly is the problem, and why one should go to great lengths to avoid this. Moreover, in this concrete example, isn't assigning modules to individual developers (as opposed to collective code ownership) essentially the same? i.e. structuring the code along the organization communication structure?

AndrewDucker 9y ago
They aren't saying it's bad. They're saying it happens. And that you need to be aware of that if you want your code to end up maintainable.
- vog 9y ago
  What does it mean to "be aware" of this? What should one do differently from one would otherwise do?
  - speedplane 9y ago
    It means that poor communication among team members will lead to poor code, and likely a poor or late product.

WillReplyfFood 9y ago

I laughed at ascii-string protocolls- then i realized how great self-explaining interfaces are.

nradov 9y ago

Project managers usually shouldn't define interfaces between code modules. That's a design lead or architect responsibility.