Enjoyed this, but looking at these from manager decision scenario is of course going to bias towards the more subjective.
For a different scenario, imagine you operate a large distributed system and have been paged at 3 am because there is a problem. Besides taking steps to contain the fallout, you want to quickly locate the error and take steps to prevent this stuff from ever happening again.
Unlike a hiring decision, you want to propose measures such that a large number of people get to agree that the state of affairs will improve. It is a truism that we don't want software to fail, so considering expectations may not necessarily help here, and rationality would suggest to strive to achieve an "objective" improvement - and one that does not make the system harder to understand or invite new, different failures.
So all in all, I enjoyed this advocacy of Tellman's perspective, but it does not always seem appropriate to apply it and more meta than the others.
I respect all three authors deeply but this is my first time reading Tellman's take. His idea that "simplicity is not intrinsic ... Simplicity is a fitness between software and our expectations" has a very nice ring to it.
Contrast that with Hickey's notion of simplicity as an objective count of interleaved concerns or "folds". The quibble with this is, how do you delineate the concerns? Depending on your style and knowledge of the system, you'll get a different number. So it's hard to call it objective.
Tellman's definition is nice because it acknowledges the subjectivity, and puts it front and center. IOW the "style and knowledge of the system" form a mental model of the software system. What's important is not the cardinality, OR the interleaving. It's the ability for that model to make good predictions about the software's behavior. Accurate model held in the minds of humans that operate it == simple software.
The hickey definition is from the POV of the engineer - the creation of software with simplicity. Code that is simple, doesn't necessarily result in a piece of software that is simple for the end-user.
The tellman's version is for the end user - simplicity of use, by the user, with their existing expectation, culture and pre-knowledge. It's basically describing skeuomorphism in software (but not limited to just UI). It might be enormously complicated to create for the engineer, while it remains simple for the end-user.
Hickey's approach is relevant in how the software is constructed, and Tellman's is relevant to the user experience. Both approaches are useful for a single application.
Quantifying software complexity is still largely an open problem. There are approaches that focus on quantifying but are arguably of limited use due to their disconnect with mental models, and there are approaches that focus on evaluating mental models but can't be objectively quantified. The best output from the latter group is that they can serve as guidelines on how to make simple software systems,and how to keep them simple.
I like Ousterhout's the best because I think it's the most concrete out of the three. The other two are more subjective imo, of course still very useful and important.
Although I think "dependency" is an overloaded term. There are dependencies as in libraries or shared code, and then there are "dependencies" which are like assumptions about other parts of the system. Hickey also mentions this when he talks about interfaces. If you break a class into two classes, but they both make assumptions about the other, in effect they are still the same class.
Perhaps another way to think about complexity is the number of assumptions baked into a system?
When I think about a system that makes zero assumptions, I imagine it would have a large number of configuration points, where every single aspect of behavior and interaction must be specified explicitly instead of implicit and assumed. That sounds complex.
On the flip side, a counter-example comes to mind: automatic imports ("autoloading") in some languages, which makes things apparently simple but gets gnarly when things break unexpectedly. It makes a lot of assumptions about your intention, which is simpler when it works the way you expect. I'd prefer explicit imports every time, even if it's verbose (some might call "complex") because it makes no assumptions - every import is visible so it's actually simpler to understand.
When you see the words "complex", "simple", and "easy", keep this in mind: these are words that exist to help humans communicate their difficulty in interacting with the world.
This whole post is a discussion of philosophy. There are three different ways you can think about software:
- philosophy
- science
- function
The philosophy of software involves people trying to understand what software is. Humans have a desire for knowledge and understanding, and like to explain things they come into contact with and think about. A lot of the time there's no "objective" philosophical explanation, try as we might to find one. Despite that, many explanations in this realm end up being useful.
The science of software is computer science, which is more about math than anything else. This is the only place you're gonna find objectivity or consensus, because you can't really argue with a number. Discussions around CS are less poetic and more boring, and require a lot more knowledge, so you won't typically find these on HN.
The function of software is the day-to-day practice of writing and using software. This is the grunt work, the meat and potatoes. No need for philosophy or science. Just put the legos together and kick the tires. This is 99% of what 99% of software developers deal with. Most people don't think about the science or philosophy of the coffee they're ordering or the bike they're riding; they're just ordering it, riding it.
I read a research article long ago that said that most of the complexity measures investigated at the time were highly correlated with loc.
For example, it's nice to measure McCabe cyclomatic complexity, and it generally rings true, but if you can't be bothered - just look at LOC and you'll get pretty close
Yes, in the same way that large forces are highly correlated with bigger things. You don't have to know anything about design or engineering to know that an 18-wheeler will deal with larger forces than a sub-compact car. Similarly, a whole lotta software is gonna be more complex.
Enjoyed this, but looking at these from manager decision scenario is of course going to bias towards the more subjective.
For a different scenario, imagine you operate a large distributed system and have been paged at 3 am because there is a problem. Besides taking steps to contain the fallout, you want to quickly locate the error and take steps to prevent this stuff from ever happening again.
Unlike a hiring decision, you want to propose measures such that a large number of people get to agree that the state of affairs will improve. It is a truism that we don't want software to fail, so considering expectations may not necessarily help here, and rationality would suggest to strive to achieve an "objective" improvement - and one that does not make the system harder to understand or invite new, different failures.
So all in all, I enjoyed this advocacy of Tellman's perspective, but it does not always seem appropriate to apply it and more meta than the others.
I respect all three authors deeply but this is my first time reading Tellman's take. His idea that "simplicity is not intrinsic ... Simplicity is a fitness between software and our expectations" has a very nice ring to it.
Contrast that with Hickey's notion of simplicity as an objective count of interleaved concerns or "folds". The quibble with this is, how do you delineate the concerns? Depending on your style and knowledge of the system, you'll get a different number. So it's hard to call it objective.
Tellman's definition is nice because it acknowledges the subjectivity, and puts it front and center. IOW the "style and knowledge of the system" form a mental model of the software system. What's important is not the cardinality, OR the interleaving. It's the ability for that model to make good predictions about the software's behavior. Accurate model held in the minds of humans that operate it == simple software.
The hickey definition is from the POV of the engineer - the creation of software with simplicity. Code that is simple, doesn't necessarily result in a piece of software that is simple for the end-user.
The tellman's version is for the end user - simplicity of use, by the user, with their existing expectation, culture and pre-knowledge. It's basically describing skeuomorphism in software (but not limited to just UI). It might be enormously complicated to create for the engineer, while it remains simple for the end-user.
Show me a software developer who isn’t an end user for someone else’s code.
This feels like it missed the point.
Hickey's approach is relevant in how the software is constructed, and Tellman's is relevant to the user experience. Both approaches are useful for a single application.
My point is that the creator/user dichotomy exists at every level of software.
Quantifying software complexity is still largely an open problem. There are approaches that focus on quantifying but are arguably of limited use due to their disconnect with mental models, and there are approaches that focus on evaluating mental models but can't be objectively quantified. The best output from the latter group is that they can serve as guidelines on how to make simple software systems,and how to keep them simple.
I like Ousterhout's the best because I think it's the most concrete out of the three. The other two are more subjective imo, of course still very useful and important.
Although I think "dependency" is an overloaded term. There are dependencies as in libraries or shared code, and then there are "dependencies" which are like assumptions about other parts of the system. Hickey also mentions this when he talks about interfaces. If you break a class into two classes, but they both make assumptions about the other, in effect they are still the same class.
Perhaps another way to think about complexity is the number of assumptions baked into a system?
When I think about a system that makes zero assumptions, I imagine it would have a large number of configuration points, where every single aspect of behavior and interaction must be specified explicitly instead of implicit and assumed. That sounds complex.
On the flip side, a counter-example comes to mind: automatic imports ("autoloading") in some languages, which makes things apparently simple but gets gnarly when things break unexpectedly. It makes a lot of assumptions about your intention, which is simpler when it works the way you expect. I'd prefer explicit imports every time, even if it's verbose (some might call "complex") because it makes no assumptions - every import is visible so it's actually simpler to understand.
> I reached out to Tellman before writing this post for some clarifications.
Ironic!
When you see the words "complex", "simple", and "easy", keep this in mind: these are words that exist to help humans communicate their difficulty in interacting with the world.
This whole post is a discussion of philosophy. There are three different ways you can think about software:
The philosophy of software involves people trying to understand what software is. Humans have a desire for knowledge and understanding, and like to explain things they come into contact with and think about. A lot of the time there's no "objective" philosophical explanation, try as we might to find one. Despite that, many explanations in this realm end up being useful.The science of software is computer science, which is more about math than anything else. This is the only place you're gonna find objectivity or consensus, because you can't really argue with a number. Discussions around CS are less poetic and more boring, and require a lot more knowledge, so you won't typically find these on HN.
The function of software is the day-to-day practice of writing and using software. This is the grunt work, the meat and potatoes. No need for philosophy or science. Just put the legos together and kick the tires. This is 99% of what 99% of software developers deal with. Most people don't think about the science or philosophy of the coffee they're ordering or the bike they're riding; they're just ordering it, riding it.
I read a research article long ago that said that most of the complexity measures investigated at the time were highly correlated with loc.
For example, it's nice to measure McCabe cyclomatic complexity, and it generally rings true, but if you can't be bothered - just look at LOC and you'll get pretty close
Yes, in the same way that large forces are highly correlated with bigger things. You don't have to know anything about design or engineering to know that an 18-wheeler will deal with larger forces than a sub-compact car. Similarly, a whole lotta software is gonna be more complex.
For those who will stumble as me: Loc = lines of code. (He he, we were talking about complexity, weren't we?)