The Source Code IS the Design, not documents


#1

I recently started a lunch and learn series based on Uncle Bob’s Clean Coders videos. We are watching one video a week starting with his series on SOLID principles as that’s something I’m trying to coach here. In this first episode I really liked the way he described how software development is the complete opposite of all other engineering types.

Here is the episode we watched: https://cleancoders.com/episode/clean-code-episode-8/show

When building a house, the cost of actually building it is very high as well as the cost of changing it. So it makes sense to put a lot of time in effort up front because designing it costs the least. In this case the architect / engineer produces a document which is the design. If it only costed 100 dollars and 1 hour to make a change to a house, you would build it incrementally as it makes the most sense because the cost of building it is less than designing it. Plus you would probably get a house you are more satisfied with.

An electrical engineer produces documents as the design, and it’s much cheaper to design circuitry than actually build it and change it later. There are many more examples of this.

In software all it takes to actually build it is to compile it. It’s by far the cheapest aspect of software engineering. The thing that takes the most time and cost is the design. Any documents that are produced prior to the code being developed is NOT the design. It’s a guide to help with the design. Ultimately the code itself is the design, when it’s compiled it’s built. Your software design is only as good as the quality of the code as it is one in the same. This is why continuous attention and investment in good software design is paramount to a successful product as actually doing this work is what costs the most and changes in the future will be even more costly if the source code isn’t following XP practices like TDD and OO design principles like SOLID so the code doesn’t become Rigid, fragile, needless complexity, and viscous.

Also the way Uncle Bob explains OO programming in a nutshell is really about dependency inversion and not just about Encapsulation and polymorphism as most people thing. You can use the concepts of OO but still make rigid and fragile code. This is why thinking about it as dependency inversion is key.