
Ask HN: How do you think about dependency management? - steviee
Dear engineers and architects,<p>how much do you value having certain (micro-)services under your teams&#x27; direct control&#x2F;influence over having other teams maintain those services in a central manner?<p>Also how does this reflect the changes in the industry regarding microservices (and data-locality) and conways law?<p>As a developer (or engineer if you want) I always strive to have _less_ dependencies and easier access to the systems _I_ (or my team) has to maintain in a production state.<p>How do you think about this kind of dependencies?<p>Kind regards,
Steviee
======
PaulHoule
I had an interesting talk about software architecture the other day and noted
that the term "dependency" is used for very similar things that happen at
different levels.

For instance a "dependency" exists in project planning in that some tasks
require others to be completed; thus over time scales of weeks and months that
kind of dependency has to be managed.

Then at runtime a framework like Spring "resolves dependencies" to initialize
objects. You could look at it as a backwards or forwards chaining problem, but
either way it knows that "A depends on B" so it initializes B first. A and B
are software objects instances in this case. The timescale is usually less
than a second here.

Then there is the dependency resolution done by Maven at build time, which
might take a few minutes. There A and B are software packages that mainly
contain software object definitions.

These different levels of dependency are somewhat but not perfectly parallel
to each other -- e.g. the Conway's law that you mention.

Aside from that I think you have to be aggressive about managing the "little
things". If you go full polyglot and let coders pick any version of any
language that they want you are not going to realize the productivity and
quality gains that you can get from microservices. For instance years ago we
had a JDK 7 client and JDK 6 server and found that a set of JAXB classes we
made weren't portable. It took us a few days to understand the problem, but it
would have taken many more days to convince management that if they want
ultra-fast software development we have to have less problems like that.

You have to standardize as much as you can about build process and libraries
that people use. I've found that this kind of functionality frequently gets
re-developed:

[https://www.envoyproxy.io/](https://www.envoyproxy.io/)

If you can standardize on a limited selection of "middleware" you may come out
ahead with microservices, but having five different ways to do the same thing
will end in tears.

