News for hackers. Stuff that matters.

A comment on Software Engineering ≠ Computer Science (2009). Parent comment

Re:Software Engineering ≠ Computer Science (2009) by Denzel on Sunday August 06, 2017 @11:30PM (#14945117)
Yes, this is of extreme interest to me as well. The why behind SOLID. I think you could formulate more rigorous support based upon information and graph theory, maybe neuroscience, and other areas I'm less familiar with.

For example, the Single Responsibility Principle (SRP) is primarily concerned with making software more manageable on both an individual and team basis. How? By minimizing:

1. Communication overhead between teams/modules

2. Information overload in an individual

You could look at #1 from a graph-theoretic and information basis. I'm sure there are many interesting things to prove there. Like Amdahl's and the opposite of Metcalfe's Law [1][2] applied to team/communication/module dependencies. Just as a basic example, if one class has 10 responsibilities shared by 10 engineers with no boundaries specified, then the probability of conflict and unintended consequences rises. Thus the rate of development slows.

As for #2, applying more rigor and proof to the question of how these principles help a human understand quicker.

I don't have the necessary background right now to explore this in more detail, but like you, I'm very interested in any possible formulations.

[1]: https://en.wikipedia.org/wiki/Amdahl%27s_law

[2]: https://en.wikipedia.org/wiki/Metcalfe%27s_law

[ Parent | on HN ]
Re:Software Engineering ≠ Computer Science (2009) by hobls on Monday August 07, 2017 @11:22AM (#14948157)
The problem is that even things like "how many people touch this class" and "how many external teams do we work with" aren't simple at all. Some external teams are much easier to work with than others. Sometimes you want your whole team to intimately understand an area of your code. Making software is an intensely human process, which is why managing software teams is almost entirely about considering the people on your team, and what makes each of them different.
[ Parent | on HN ]