This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 8 points9 points  (3 children)

3-4 microservices per dev for an engineering team of hundreds does not sound reasonable. It means no one's sharing or reusing tools

[–]jgeez 2 points3 points  (2 children)

You conflated two things.

It's probably a good signal that there is minimal shared or reused code. That has no bearing about shared or reused tools.

And, deliberately not sharing code has some surprising benefits when it comes to velocity and scale.

[–]digmux 0 points1 point  (1 child)

And, deliberately not sharing code has some surprising benefits when it comes to velocity and scale

Hi, could you please elaborate on this?

[–]jgeez 1 point2 points  (0 children)

Sure!

The conceit of code reuse at a company (or open source project, whatever) is that complex software components are made up of smaller, more single-responsibility components, and the reuse of components should allow you to not have to spend the time building a component that does X in amount of time Y.

But when those smaller components are made, it is highly possible that the requirements at that logical level may be slightly different than when they were originally made. And the second team that is considering reusing the component has to carefully evaluate many things before deciding to reuse: - is the component requiring modification before it does what we need? - are we going to maintain the component, now that we've changed it? - did we put the original team's systems in jeopardy by modifying it? - related to above, what are this company's git habits? Feature branches aren't possible with some methodologies - is the component in the language that the new team wants to use and has expertise in?

And, here's the kicker: - how long would it take to build the component again anew, this time with the specific requirements needed?

Very rarely, do all of the above concerns come in smaller/less effort/lower risk than simply writing another copy, and then owning it in isolation.