5 ms·

It's hard to argue with the business sense of pushing out features quickly at the cost of code quality. But I've learned that that there are two kinds of devel

It's hard to argue with the business sense of pushing out features quickly at the cost of code quality. But I've learned that that there are two kinds of development teams: (A) the teams that are "moving fast and breaking things" while "creating business value" and (B) the teams that are "only maintaining legacy code", "not getting anything done", "costing a lot of money" and "complaining too much" about code quality that team A wrote. As an engineer, I've learned that it's less work and more rewarding to be on the (A) teams than on the (B) teams.

nickpeterson 10y ago
The difference is that Team A can leave and a project is delayed. If Team B all left the company would fold.
- ceronman 10y ago
  Both are necessary. If Team A leaves, and no more business value is produced, and the devs only care about beautiful code, the company will fail too. Both kinds of teams are needed. Or even better, teams should not be divided like this, everyone should do their shares of both breaking things, and creating value and cleaning the mess and scaling the things.
- scaryclam 10y ago
  Funnily I've actually seen a Team B leave. There was much panic and thinking it would all go horribly wrong, and indeed it was madness for the first week. Then the people who took over started to stabilise some of the worst parts of the system and it all sort of fell into place after that. Fast forward a couple of months, the project was pretty much hands off and we all realised that keeping a whole team on that project had pretty much been a giant waste of money. They did nothing but create fires for themselves to fix. The Team B's exodus was actually a really great thing for the company. I suppose the thing to learn here is, that you need redundancy in your teams. If we hadn't had other devs to step in and take over, it would have been a bit different. Still, I'm not convinced that a handful of contractors couldn't have been brought in to the same result, just more expensive.
  - brianwawok 10y ago
    How big was team B, and did they leave through a random event (2 guys got hired at Google, and 1 guy found a new job), or some kind of mass "lets show them" quitting event?
sAbakumoff 10y ago
I like type (C) whose motto is "move fast and fix things" https://githubengineering.com/move-fast/ https://githubengineering.com/move-fast/
- ricardobeat 10y ago
  And yet https://github.com/blog/2106-january-28th-incident-report https://github.com/blog/2106-january-28th-incident-report
  - Nition 10y ago
    I like how even the URL has a "bug" (year 2106?).
    - amnah 10y ago
      uh no. that's the id of the blog post https://github.com/blog/2105 https://github.com/blog/2105 https://github.com/blog/2106 https://github.com/blog/2106 https://github.com/blog/2107 https://github.com/blog/2107
      - Nition 10y ago
        Aw, it looked so much like a minor mistake with the Y-M-D date format considering it happened on 2016-january-28th!
  - sAbakumoff 10y ago
    Sure, shit happens to the best of us. It's inevitable.
- collyw 10y ago
  I am type (D) don't move particularly fast, but produce decent code - when management isn't pushing me to be type (A).
liveoneggs 10y ago
That's because team "B" is actually an operations team and, believe me, you don't get into ops for "fun". :)
omouse 10y ago
Yes and that's the perversity of the incentives in the industry. Automation and coding are such high value activities that even the smallest, shittiest piece of code can produce a lot of $$$ that can make up for its crappiness and its maintenance costs.
watwut 10y ago
The best is to work in companies where people maintain their own code and are responsible for fixing what they broke. The moment the split is like you said, A team will produce progressively crappier and harder to maintain code. The B team will have high turnover and require higher salaries to stay in. It is bad organizational structure.
draw_down 10y ago
Yes, thank you. I've been trying to write out that very idea for so long. It comes down to, the heroes are the people making the new stuff, and the janitors are the ones stuck with all the bugs and tech debt of the new stuff. Guess who gets promoted. When you find yourself in the janitor role, time to move on, because your employer doesn't think much of you.
temp_account01 10y ago
I've learned from working in one of the largest companies that there are two kinds of development teams: (1) the teams that mostly depend on the products of other teams; (2) the teams that create products that others depend on. And when the upper management starts rushing the deadlines sacrificing quality for the deliverables guess which team becomes (A) and which team becomes (B)? I currently work in a (B) team, and I try as hard as I can to "move fast and break things" but there is simply no way of doing that because every significant code change that I make requires changing the code we don't own. Since the code that we don't own is written in such scrappy way that you better don't touch it or else it breaks, our team has to resort to only minor insignificant code changes. >>As an engineer, I've learned that it's less work and more rewarding to be on the (A) teams than on the (B) teams. It is certainly more rewarding to be on the (A) team, but do we always have a choice?

nickpeterson 10y ago

The difference is that Team A can leave and a project is delayed. If Team B all left the company would fold.

ceronman 10y ago
Both are necessary. If Team A leaves, and no more business value is produced, and the devs only care about beautiful code, the company will fail too. Both kinds of teams are needed. Or even better, teams should not be divided like this, everyone should do their shares of both breaking things, and creating value and cleaning the mess and scaling the things.
scaryclam 10y ago
Funnily I've actually seen a Team B leave. There was much panic and thinking it would all go horribly wrong, and indeed it was madness for the first week. Then the people who took over started to stabilise some of the worst parts of the system and it all sort of fell into place after that. Fast forward a couple of months, the project was pretty much hands off and we all realised that keeping a whole team on that project had pretty much been a giant waste of money. They did nothing but create fires for themselves to fix. The Team B's exodus was actually a really great thing for the company. I suppose the thing to learn here is, that you need redundancy in your teams. If we hadn't had other devs to step in and take over, it would have been a bit different. Still, I'm not convinced that a handful of contractors couldn't have been brought in to the same result, just more expensive.
- brianwawok 10y ago
  How big was team B, and did they leave through a random event (2 guys got hired at Google, and 1 guy found a new job), or some kind of mass "lets show them" quitting event?

sAbakumoff 10y ago

I like type (C) whose motto is "move fast and fix things" https://githubengineering.com/move-fast/ https://githubengineering.com/move-fast/

ricardobeat 10y ago
And yet https://github.com/blog/2106-january-28th-incident-report https://github.com/blog/2106-january-28th-incident-report
- Nition 10y ago
  I like how even the URL has a "bug" (year 2106?).
  - amnah 10y ago
    uh no. that's the id of the blog post https://github.com/blog/2105 https://github.com/blog/2105 https://github.com/blog/2106 https://github.com/blog/2106 https://github.com/blog/2107 https://github.com/blog/2107
    - Nition 10y ago
      Aw, it looked so much like a minor mistake with the Y-M-D date format considering it happened on 2016-january-28th!
- sAbakumoff 10y ago
  Sure, shit happens to the best of us. It's inevitable.
collyw 10y ago
I am type (D) don't move particularly fast, but produce decent code - when management isn't pushing me to be type (A).

liveoneggs 10y ago

That's because team "B" is actually an operations team and, believe me, you don't get into ops for "fun". :)

omouse 10y ago

Yes and that's the perversity of the incentives in the industry. Automation and coding are such high value activities that even the smallest, shittiest piece of code can produce a lot of $$$ that can make up for its crappiness and its maintenance costs.

watwut 10y ago

The best is to work in companies where people maintain their own code and are responsible for fixing what they broke. The moment the split is like you said, A team will produce progressively crappier and harder to maintain code. The B team will have high turnover and require higher salaries to stay in. It is bad organizational structure.

draw_down 10y ago

Yes, thank you. I've been trying to write out that very idea for so long. It comes down to, the heroes are the people making the new stuff, and the janitors are the ones stuck with all the bugs and tech debt of the new stuff. Guess who gets promoted. When you find yourself in the janitor role, time to move on, because your employer doesn't think much of you.

temp_account01 10y ago

I've learned from working in one of the largest companies that there are two kinds of development teams: (1) the teams that mostly depend on the products of other teams; (2) the teams that create products that others depend on. And when the upper management starts rushing the deadlines sacrificing quality for the deliverables guess which team becomes (A) and which team becomes (B)? I currently work in a (B) team, and I try as hard as I can to "move fast and break things" but there is simply no way of doing that because every significant code change that I make requires changing the code we don't own. Since the code that we don't own is written in such scrappy way that you better don't touch it or else it breaks, our team has to resort to only minor insignificant code changes. >>As an engineer, I've learned that it's less work and more rewarding to be on the (A) teams than on the (B) teams. It is certainly more rewarding to be on the (A) team, but do we always have a choice?