April 23, 2017
The Win-Win-Win of Clean CodeA conversation I had with a development team last week has inspired me to write a short post about the Win-Win-Win that Clean Code can offer us.
Code that is easier to understand, made of simpler parts, low in duplication and supported by good, fast-running automated tests tends to be easier to change and cheaper to evolve.
Code that is easier to understand, made of simpler parts, low in duplication and supported by good, fast-running automated tests also tends to be more reliable.
And code that is easier to understand, made of simpler parts, low in duplication and supported by good, fast-running automated tests - it turns out - tends to require less effort to get working.
It's a tried-and-tested marketing tagline for many products in software development - better, faster, cheaper. But in the case of Clean Code, it's actually true.
It's politically expedient to talk in terms of "trade-offs" when discussing code quality. But, in reality, show me the team who made their code too good. With very few niche exceptions - e.g., safety-critical code - teams discover that when they take more care over code quality, they don't pay a penalty for it in terms of productivity.
Unless, of course, they're new to the practices and techniques that improve code quality, like unit testing, TDD, refactoring, and all that lovely stuff. Then they have to sacrifice some productivity to the learning curve.
Good. I'm glad we had this little chat.
April 20, 2017
Still Time to Grab Your TDD 2.0 TicketsJust a quick reminder about my upcoming Codemanship TDD training workshop in London on May 10-13. It's quite possibly the most hands-on TDD training out there, and great value at half the price of competing TDD courses.
March 6, 2017
Start With A Goal. The Backlog Will Follow.The little pairing project I'm doing with my 'apprentice' Will at the moment started with a useful reminder of just how powerful it can be to start development with goals, instead of asking for a list of features.
As usual, it was going to be some kind of community video library (it's always a community video library, when will you learn!!!), and - with my customer role-playing hat on - I envisaged the usual video library-ish features: borrowing videos, returning videos, donating videos, and so on.
But, at this point in my mentoring, I'm keen for Will to get some experience working in a wider perspective, so I insisted we started with a business goal.
I stipulated that the aim of the video library was to enable cash-strapped movie lovers to watch a different movie every day for a total cost of less than £100 a year. We fired up Excel and ran some numbers, and figured out that - in a group with similar tastes (e.g,, sci-fi, romantic comedies, etc) - you might need only 40 people to club together to achieve this.
This reframed the whole exercise. A movie club with 40 members could run their library out of a garden shed, using pencil and paper to keep basic records of who has what on loan. They could run an online poll to decide what titles to buy each month. They didn't really need software tools for managing their library.
The hard part, it seemed to us, would be finding people in your local area with similar tastes in movies. So the focus of our project shifted from managing a collection of DVDs to connecting with other movie lovers to form local clubs.
Out of that goal, a small feature list almost wrote itself. This is how planning should work; not with backlogs of feature requests, but with customers and developers closely collaborating to achieve goals.
It's similar in many ways to how TDD should work - in fact, arguably, it is TDD (except we start with business tests). When I'm showing teams how to do TDD, I advise them not to think of a design and then start writing unit tests for all the classes and methods and getters and setters they think they're gloing to need. Start with a customer test, and drive your internal design directly from that. Classes and methods and getters and setters will naturally emerge as and when they're needed.
When I run the Codemanship Agile Software Development workshop, we do it backwards to illustrate this point. Teams are tasked with coming up with internal designs, and then I ask them to write some customer tests afterwards. Inevitably, they realise their internal design isn't what they really needed. Stepping further back, I ask them to describe the business goals of their software, and at least half the teams realise they're building the wrong thing.
So, my advice... Ditch the backlog and start with a goal. The rest will follow.
March 2, 2017
101 TDD Tips - Complete SeriesFor the last 3 months, I've been posting tips for doing Test-Driven Development for effectively and sustainably to the Codemanship Twitter feed.
The series is now complete, and you can read all 101 TDD tips in this handy PDF
February 2, 2017
101 TDD Tips - #1-#80
We're now up to number 81 in my 101 TDD Tips series on Twitter, and I've pasted numbers 1-80 into a handy PDF for your convenience.
January 20, 2017
TDD 2.0 - London, May 10thAfter the success of last week's TDD 2.0 training workshop, I've immediately scheduled another one for the Spring.
It's 3-days jam-packed with hands-on learning and practice, covering everything from TDD basics and customer-driven TDD/BDD, all the way to advanced topics other courses and books don't touch on like mutation testing and non-functional TDD.
And it comes with my new TDD book, exclusive to attendees.
If you fancy a code craft skills boost, twist the boss's arm and join us on May 10th.
January 14, 2017
Codemanship Alumni - LinkedIn Group
Just a quick note to mention that there's a special LinkedIn group for folk who've attended Codemanship training workshops*.
With demand for skills like TDD and refactoring rising rapidly, membership is something you can display proudly for interested hirers.
* You'll need to list details of Codemanship training courses you've attended (what, when, where) on your LinkedIn profile so I can check against our training records.
January 9, 2017
Last Call for TDD 2.0 - London, Wed-FriJust a quick note to mention I've got a bit of space of available for this week's jam-packed TDD 2.0 training workshop in London.
January can be a quiet period for dev teams, so twist the boss's arm and take advantage of some slow time.
December 19, 2016
Start The New Year With A TDD Skills BoostJust a quick reminder about the next public TDD training workshop I'm running in London on Jan 11-13. It's the most hands-on and practical workshop I've ever done, and at about half the price of the competition, it's great value. And, of course, you get the exclusive TDD book. Not available in any shops!
November 23, 2016
101 TDD Tips - #1 - #40We're now up to #40 of my 101 TDD Tips (follow https://twitter.com/search?q=%23101TddTips for daily additions).
And you can get a monthly digest of all the tips posted so far from http://www.codemanship.co.uk/files/101TddTips.pdf