Hacker News Reader

Comment by thedevil | Hacker News Reader

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.

View on HN

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

And yet https://github.com/blog/2106-january-28th-incident-report

I like how even the URL has a "bug" (year 2106?).

uh no. that's the id of the blog post

https://github.com/blog/2105 https://github.com/blog/2106 https://github.com/blog/2107

Aw, it looked so much like a minor mistake with the Y-M-D date format considering it happened on 2016-january-28th!

Sure, shit happens to the best of us. It's inevitable.

I am type (D) don't move particularly fast, but produce decent code - when management isn't pushing me to be type (A).

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.

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

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.

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?

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.

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?

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.

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.

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

Reply on news.ycombinator.com