The mis-education and re-education of Ismail Mayat
By Ismail Mayat
Almost a year ago I attended a 3-day course ‘Clean Code’ at Code Node with the one and only ‘Uncle Bob Martin’. The course was a real eye opener and has totally changed the way I approach coding.
After attending that course I have spoken about ‘clean code’ at the following events: Umbraco PL festival, DDDNorth, DDD Scotland, DDDSouthWest, Leeds Sharp and at Umbraco Meetup London, Umbraco Meetup Manchester is due sometime in July.
One of the things I mention when speaking about what I learned from the Clean code course is how I wish I had attended something like that course at the start of my programming career as it would have saved me a whole world of pain.
I came to the wonderful world of code by a circuitous route. My first degree was in Chemistry, and after working building PCs circa 1995-1996 I studied for my masters in computing. This was effectively 2 years of a computing degree course condensed into one year. Straight after that I moved into the world of work.
Although my master’s course covered all the fundamentals of database theory, programming etc, we did not cover ‘clean code’. I have asked this question many times to audiences attending my clean code sessions, particularly those with a degree, "did you cover clean code on your course?" The answer has always been an emphatic "no".
Recently a friend of the family was visiting my wife with her nephew, he happened to see my copy of ‘Clean Code’ by Bob Martin and he was intrigued. As a recent IT graduate from UCLAN (University of Central Lancaster), and again, he had covered the basics, but was not aware of things like optimal function lengths or naming or how to structure code.
‘Clean Code’ course
The clean code course has made me re-evaluate my own IT education. With this in mind, I have been reading classic IT texts which I feel should be essential reading for every developer. Many times while reading these books I have been asking the question: "Why have I not read these books before?" Again, this would have made my life a lot easier.
So what follows is a list of books that have been fixing and closing the gap of the mis-education of Ismail Mayat!
The first two books are Clean Code by Bob Martin (no surprise there) and Code Complete by Steve Mcconnell (note to self: get my copy back that has been lent to a friend circa 2015!). Both are excellent primers on how to write and organise code. These books also capture knowledge available from research, academia, and everyday commercial practice. Many of the principles are back to basics but its these lack of back to basics principles that lead to bad and unmaintainable code.
Sticking with code but from a structural perspective is Bob Martin's recent book Clean Architecture, the content of this book can be defined by this extract from page 5:
“The goal of software architecture is to minimise the human resources required to build and maintain the required system. The measure of design quality is simply the measure of the effort required to meet the needs of the customer.”
The book goes into detail about how we can exert less effort to meet clients’ changing requirements. The book draws on Bob’s 53-years worth of development experience. He has been there, done that and felt the pain. He describes his experiences so well that you shouldn’t make the same mistakes he made!
Next up is Test Driven Development by Example, by Kent Beck. I read this book in the space of a week! What blew my mind was the fact that it was written back in 2002. It is a must-read for those just starting out or wanting to start doing TDD. Ian Cooper did a talk at NDC 13 entitled TDD where did it all go wrong, he makes a few references to Kent Beck’s seminal book, and how we have misunderstood what Kent was saying all those years ago.
Sticking with TDD for those of us in the .net ecosphere, there is Art of Unit Testing by Roy Oshergrove. The book covers TDD with .net developers in mind and a specific emphasis on tooling that is available like NUnit, Rhino Mocks etc. I really enjoyed the final chapters which illustrate how to introduce tests into a legacy codebase by finding seams and by creating a test feasibility table to determine what to attack first, the hard stuff or the easy stuff.
Also on my to read list is Growing Object-Oriented Software, Guided by Tests. This book deals more with outside of TDD also known as the ‘London school of TDD,’ which begins with writing an acceptance test for a feature, and test driving the code out to implement that feature by concentrating on collaborating objects and behaviours.
(Update: Book arrived from library read it, really enjoyed the last few chapters, it's a must read to get a better handle on TDD).
Currently I’m reading Refactoring: Improving the design of existing code by Martin Fowler. This is not really a cover-to-cover read, but something you can dip into as the need arises. It was great to see names being given to refactoring patterns that I apply on a regular basis to existing code. This book was first published in 1999 but again, there is so much relevant stuff in there. To be fair, we now have much better tooling to help with refactoring i.e. Jetbrains resharper. There is a second edition of the book coming soon with an updated catalogue of refactoring patterns. Martin Fowler has blogged about it on his website.
Some books I am waiting to source from my local library include, Working effectively with legacy code by Micheal Feathers and Refactoring to Patterns by Joshua Kerievsky. Both of these come highly recommended. I am really looking forward to reading Refactoring to Patterns as an alternative to Design Patterns (my copy is propping up my laptop, gasp!) by the gang of four which I found to be too academic in nature whereas Refactoring to Patterns looks more practical. I feel as though I have not truly grokked patterns yet.
SOLID, TDD, what’s next?!
At the end of the ‘Clean Code’ course someone asked Uncle Bob, what should be their next step now that they understand SOLID, TDD and have completed the ‘Clean Code’ course. He replied they should learn a functional language.
So I had a go at learning Clojure (Clojure for the brave and true) which is a Lisp derivative, however coming from a Microsoft stack I recently picked up a few books on FSharp (Domain Modeling Made Functional and Get Programming with F#) and have been following some courses on Pluralsight. I will probably never get to do anything practical with it, but the concepts are good to know as many functional elements are slowly creeping into C#, pattern matching anyone?
The thing with a functional language is that it is a very different way of thinking. Imperative OO languages deal with the how to solve a problem, whereas with a functional language you are coming at the problem from the what, namely what you are trying to achieve. Bob Martin on his clean coders’ blog wrote a very good article on FP vs OO the bottom line being there is no FP vs OO:
“FP and OO work nicely together. Both attributes are desirable as part of modern systems. A system that is built on both OO and FP principles will maximize flexibility, maintainability, testability, simplicity, and robustness. Excluding one in favor of the other can only weaken the structure of a system.” Bob Martin
After speaking at the Umbraco London Meetup I was approached by a recent Umbraco MVP, Emma Burstow. Emma works as a junior developer at Crumpled Dog and said she really liked my talk and was looking to get some of the books I mentioned and catching up on some the videos linked in my slides. What impressed me was her desire to learn and left me wishing I had the same zeal when I was starting out in my career, but as the saying goes "better late than never"!