4 ms·

This talks about code complexity a lot. This, however, is not the chief source of complexity in many code bases. The number of tools needed to build things is t

by cjfd 5y ago

This talks about code complexity a lot. This, however, is not the chief source of complexity in many code bases. The number of tools needed to build things is the bane of the modern software developer. Also, the use of microservices where none are needed results in and enormous increase in complexity. Code complexity is relatively easy to fix compared to all of this.

deleted 5y ago
[deleted]
brodo 5y ago
Exactly. Every dependency is a liability.
defanor 5y ago
Indeed; I tried to compose yet another list of factors contributing to (or approaches to estimating) software project complexity in the past, with code complexity being just one out of 18, and not seeing it as particularly outstanding. Perhaps just a bad title.
nine_zeros 5y ago
Yup. Long gone are the days of concise packaging in single executables. Quite literally, software engineers today spend most of their time fighting dependencies and poorly built delivery machines.
kello 5y ago
second this. toolchain complexity is way more of a PITA than code complexity for me these days.
- kitd 5y ago
  Toolchain simplicity is a key reason for why I like Go. One binary to do it all.
epylar 5y ago
I have seen a team be forced to use microservices for things still running on the same machine years later, with absolutely no benefit other than the powerpoint architecture slides looking fancier.
- worik 5y ago
  That may have well got them extra sales, which gave the team pay rises....
- fivea 5y ago
  > I have seen a team be forced to use microservices for things still running on the same machine years later, with absolutely no benefit other than the powerpoint architecture slides looking fancier. The main driving force for microservices is not technical but organizational. Therefore, there are plenty of non-technical issues, such as for example budget to grow and split a team, that make or break the adoption of this style of architecture.
  - epylar 5y ago
    Maybe. These particular ones were never properly decoupled.

by cjfd 5y ago

deleted 5y ago

[deleted]

brodo 5y ago

Exactly. Every dependency is a liability.

defanor 5y ago

Indeed; I tried to compose yet another list of factors contributing to (or approaches to estimating) software project complexity in the past, with code complexity being just one out of 18, and not seeing it as particularly outstanding. Perhaps just a bad title.

nine_zeros 5y ago

Yup. Long gone are the days of concise packaging in single executables. Quite literally, software engineers today spend most of their time fighting dependencies and poorly built delivery machines.

kello 5y ago

second this. toolchain complexity is way more of a PITA than code complexity for me these days.

kitd 5y ago
Toolchain simplicity is a key reason for why I like Go. One binary to do it all.

epylar 5y ago

I have seen a team be forced to use microservices for things still running on the same machine years later, with absolutely no benefit other than the powerpoint architecture slides looking fancier.

worik 5y ago
That may have well got them extra sales, which gave the team pay rises....
fivea 5y ago
> I have seen a team be forced to use microservices for things still running on the same machine years later, with absolutely no benefit other than the powerpoint architecture slides looking fancier. The main driving force for microservices is not technical but organizational. Therefore, there are plenty of non-technical issues, such as for example budget to grow and split a team, that make or break the adoption of this style of architecture.
- epylar 5y ago
  Maybe. These particular ones were never properly decoupled.