Link: https://www.youtube.com/watch?v=bmSAYlu0NcY
The secrets to good software design:
Deep classes provide a minimal interface to the world that is the entrypoint to rich/complex functionality.
Shallow classes by comparison, provide a complex/maximal interface to the world that is the entrypoint to functionality not much more complex than the interface already is, or in some worst cases even less complex than the interface.
This would be an example of an interface that provides a net negative in terms of abstraction: that is, the interface is actually more complex than the behaviour it provides.
We’ve been taugh that classes and methods should be small. See Clean Code. Taken to the extreme this results in “classitis”, someone heard “classes are good”, and what they thought they heard was “more classes are better”. Java’s core library is a particularly bad offender.
In the case above, the less common scenario would be to want to read a file without buffering, and yet we have to specify “yes I want buffering”.
Method and class length is not the most important thing, it’s abstraction. Deep abstractions should be the goal.
A good example of a deep abstraction is the Unix file I/O interface. 5 functions provide access to hundreds of thousands of lines of code.
We are taught to code defensively. People follow this train of logic to come to the conclusion that they should be throwing more exceptions.
We should minimise the number of places we have to handle exceptions. Or better yet redefine the semantics so that there is no error.
For the 3 example mistakes above he says:
- Tcl unset throws exception if variable doesn’t exist
- Redefine semantics of the method to “make the variable not exist”. If the variable doesn’t exist at the the time the method is called, job done, no exception needed.
- Windows can’t delete a file if it’s open
- Unix has an elegant solution to this problem, it deletes the file from the directory of the file system so that it no longer appears, but the contents of the file remain. This lets any process that was using the file continue to completion, at which point the contents is cleaned up.
- Substring range exceptions e.g. if one or both indices is outside of the length of the string
- He suggests to just return the overlap between the indices you’ve specified and the available contents of the string, e.g. if both indices are outside the range of the string, return an empty string. If the indices are in reverse order return an empty string.
Tactical tornadoes churn out enormous amounts of low quality code that kind of works, and they leave a trail of destruction in their wake. Often these people are considered heroes, they are the people that “get stuff done”. Sometimes management even rewards tactical tornadoes.
We can perhaps say that we can aim for a good design, rather than a great design, as long as the design is flexible enough that we can change it as requirements change.
The investment of taking the time to produce a good design in fact starts paying off quite soon, see:
Is High Quality Software Worth the Cost?
I think this is a really interesting point. He talks about how a lot of startups go the 100% tactical route and are much more concerned with entering the market with a low quality product. There is certainly some logic to this, and there are successful companies that made their start with this approach. I think there is some survivorship bias going on here though, there are a lot of startups that fail, orders of magnitude more than those that succeed. It would be really interesting to see how many of those failed because of the tech for one reason or another, as opposed to any market related reason or anything else. There is a very real cost to poor software, not just limited to slowed pace of delivery. Things like:
- Poor UX as a result of badly optimised code
- Higher running costs due to again badly optimised code, or poorly conceived architecture
Interesting insights from John after teaching this class a few times:
- Making classes just slightly general purpose, even if they’re only going to be used in one place makes them simpler and deeper.