My Journey into Software Craftsmanship
My journey started in 1991 as a student in further education. I had no knowledge of software development at all, but I chose a course in computing while I worked out what I wanted to do in life. I started learning a programming language called Pascal, which was procedural and didn’t provide an elegant way of writing clean code. I found myself writing lengthy functions which, even then, I could see were not maintainable or easy to debug. The following year I came across C++ for the first time. I could see the objects being created were separated in a meaningful way and organised in a logical structure. It just seemed to be a natural approach to writing code; a process existed in run time, representing a piece of program flow. While becoming a C++ programmer over the next 6 years, through further education and employment, my appreciation of quality code became utmost in my mind.
The business model centralised around a call centre and website. The call centre software was a FoxPro app, and my role was to maintain the customer voucher and call centre booking systems. A new contractor had joined us and brought with him a great deal of knowledge and new tech. I knew of .Net, but had not had the opportunity to begin developing with it. It was very new at that time, and his task was to bring development up to date and modernise our approach.
Combined with some staff changes and a new office, we began a new green field project that would challenge my entire thinking towards my job, and allow me to step up a gear in getting work done. This project quickly gathered pace, and we were excited about what we could achieve and learn. In preparation, each of the development team was given a book to read called ‘Extreme Programming Explained’ by Kent Beck. This book presented a shift in thinking about our approach and for the first time we were using Test Driven Development (TDD) and Pair Programming. Ok, I admit it, I was sold. TDD was awesome!! We were writing tests to drive out each of our new classes, and we reran the tests time and time again. We discussed at length the best naming conventions for our tests and classes, and I could see straight away the value this brought. The tests were meaningful in naming and exercised the code we wrote. Refactoring was productive and code quality significantly improved. Although mainly unit tests, the ability to retest all of our code at a press of a button was a breakthrough. We were delivering in iterations and committed to a daily release into UAT for business users to test and provide feedback to our business analyst.
In the last 5 years, working at comparethemarket.com, greater emphasis has been placed on Behavioural Driven Development (BDD), focusing on the exercising of software through its public interfaces. This has provoked healthy discussion within teams about the value of tests at class/unit level and whether those tests should remain present after development is complete. Are those unit tests continuing to provide value, given BDD tests are exercising the API of the software? This is something that all teams should discuss and review on a regular basis, because it drives confidence in the software solution by creating tests that validate the business rules the software was created for. This is extremely valuable, to both software developers, and the people who ask for or use the software solution. Software Craftsmanship is a path of continuous improvement within teams, exploring the domain of the problem with a mind-set of writing tests to drive the design of quality code. My journey continues…