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
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!
October 12, 2016
Evil FizzBuzzThe major upgrade to the Codemanship TDD training workshop launched at the weekend, and - while much has changed - what would a TDD workshop be without FizzBuzz?
But the practical exercises in TDD 2.0 have been turbocharged...
Evil FizzBuzz (or "Continuous FizzBuzz") is my take on a Continuous Integration kata - we just don't do enough of those, right? - where each par of the FizzBuzz problem has been isolated in its own user story.
Teams must split up the work, with each developer (or pair of developers) picking up one user story at a time, test-driving the code just for that story, and continuously integrating with the other members of the team who are simultaneously working on other stories.
Committing to the same GitHub repository, with a cloud build pipeline set up to compile the code and run all the tests, this is a challenge in not tripping over each others' feet. It takes effective coordination and communication. Again, something we just don't practice enough.
The goal is to complete it quickly without breaking the build. To make it even more interesting, assign a single developer to take the challenge by themselves and see who finishes faster.
TDD 2.0 - London, Jan 11th
Here's an idea for what the boss could get your team for Christmas; the first full TDD 2.0 public workshop is happening in London on January 11-13.
There's a 1, 2 and 3-day option, and every attendee gets a copy of the exclusive new TDD book to take away and continue their TDD journey with.
October 9, 2016
TDD 2.0 LaunchesYesterday saw the launch of the new Codemanship TDD training workshop in London. Thirty keen code crafters joined in South Wimbledon to put themselves through their TDD paces, and get their hands on my new book, exclusive to workshop attendees.
It was a packed day - maybe a bit too packed, with everything we crammed in - and everyone rose to the challenge admirably. As always, it's enormously rewarding to spend a day with developers who care about their craft.
The full version of the workshop comes in 1, 2 and 3-day varieties, with more time to explore each exercise, and at a more leisurely pace. Every attendee gets a copy of the 200-page book, which covers everything from TDD basics (red-green-refactor) to advanced topics like property-based testing and non-functional TDD. Further reading's clearly signposted, making the book and the workshop a great gateway into a lifetime of TDD study and practice, as well as a pick-me-up for experienced TDD practitioners, with many ideas not usually covered in TDD books and courses.
You can find out more about the workshop, and download the first seven chapters of the book for free, by visiting http://www.codemanship.com/tdd.html
September 29, 2016
The Afternoon I Learned to Fly a PlaneWhen I was younger, my Dad was an amateur pilot. One time, he took us up for a flight, and when he'd got us up in the air and on our way - on a lovely calm and clear day - he let me take the controls for a little while. I remember after we landed being cockahoop that I'd learned how to "fly a plane".
Imagine, now, that I harboured ambitions to start my own airline. The only barrier to this plan is that I'm not a pilot, and hiring pilots is expensive. But, fear not, because - remember - on that calm and clear summer afternoon I learned how to "fly a plane".
Sure, I didn't learn how to take off. Or how to land. Or how to navigate. Or what to do when visibility is poor, or when the skies are choppy. And I didn't learn what all the knobs and dials and switches do, or what it means when that particular red light is blinking and what I should do in response. I didn't learn about basic aerodynamics, or how aeroplanes work or which bits of the plane do what, and how to check that everything's working before I take off. I didn't learn about the fuel the plane uses, where to get some, and how to calculate how much fuel I might need for my journey. I didn't learn how to land in an emergency. I didn't learn about speaking to air traffic control, nor how to use the radio for any purpose. I didn't learn about flight plans, or how to read aviation charts. I didn't learn about "air corridors", or about CAA rules.
But I had flown a plane, and was therefore surely only a couple more lessons away from being a pilot. I mean, it's easy. You just hold the steering wheel and keep the nose of the plane pointing to where you want to go. Right? What's that? It's called a "yoke"? Okay, I didn't learn that either.
This is all absurd, of course. It takes many hours of experience, and much study, before you're safe to be in charge of an aeroplane. There's so much that can go wrong, and you can't just pull over on to the hard shoulder when it does. when I had control, there was a qualified, experienced pilot sitting right next to me, and - in reality - he was in control. He talked me through it all the way, and if necessary could take over at a second's notice. I just did exactly what he told me to do.
But if I were a cynical opportunist, I might exploit this initial moment of euphoria that I experienced to make me believe that I can fly a plane. I can see the ads now: "Thinking of starting an airline? Why pay for expensive so-called 'pilots' when anyone can learn to fly on our 1-day course." This would be an exemplary commercialisation of the Dunning-Kruger effect: they don't know that they haven't learned to fly a plane, and we ain't about to tell them.
What that short flight with Dad did do, though, was get us excited about learning to fly. So much so, that for a good few years it was my brother's primary ambition to be a pilot.
A course claiming to teach you to fly in a day - or even an hour - would end up in court, of course. Grown-ups know it just isn't as simple as holding the stick and going in a straight line for 5 minutes.
So, why don't grown-ups know this about writing software?
September 24, 2016
10 Great Reasons to Learn TDD1. Rising Demand - Test-Driven Development has been growing in popularity over the last decade, with demand rising by a fairly steady 6% each year here in the UK. In 2016, roughly a quarter of all developer jobs advertised ask for TDD skills and experience. It's not unthinkable that within the next decade, TDD will become a mandatory skill for software developers.
2. Better Pay - according to data on itjobswatch.co.uk, the median salary for a software developer in the UK is £40,000. For devs with TDD skills, it rises a whopping 27.5% to £51,000. Overall, developer pay in Britain has been stagnating, with a real-terms fall in earnings over the last decade. Salaries for jobs requiring TDD skills have consistently outperformed inflation, rising about 4.5% every year for the last 3 years.
3. Better Software - the jury's not out on this one. Studies done into the effects of TDD show quite conclusively that test-driven code is less buggy - by as much as 90% less buggy. But that's not the only effect on code quality; studies done at the BBC and by Keith Braithwaite of Zuhlke Engineering show clear gains in code maintainability, with test-driven code being simpler and containing less duplication. Other studies show test-driven code tends to have lower class coupling and higher class cohesion.
4. Faster Cycle Times - the Holy Grail of Continuous Delivery is code that's always shippable, so when a feature's ready, the business can decide to release it straight away, instead of having to wait for a long and tortuous acceptance testing and stabilisation phase to make it fit for purpose. TDD, done well, delivers on this promise by continuously testing the code to ensure it always works. It's no coincidence that all the teams doing Continuous Delivery successfully are also doing TDD. TDD enables Continuous Delivery.
5. Sustainable Innovation - not only can TDD help teams deliver value sooner, it can also help them deliver value on the same code base for longer. I've seen some big organisations brought to their knees by the crippling cost of changing software products and systems, and having to rewrite software from scratch many times just to make small gains in new functionality. The technical benefits of TDD - continuous testing and cleaner code - tend to flatten out the cost of change over time, which typically rises exponentially otherwise.
6. It Doesn't Cost More - despite what some TDD naysayers claim, it actually doesn't cost significantly more to test-drive the design of your code, and in some cases improved productivity. Many teams report a slowdown when adopting TDD, and this is because of the not-inconsiderable learning curve. It takes 4-6 months to get the hang of TDD, and a lot of teams don't make it that far, which is why I strongly recommend adopting TDD "under the radar".
7. Puts The Problem Horse Before The Solution Cart - one of the biggest failings of software development teams is our tendency to be solution-driven and not problem-driven. TDD forces us to start by explicitly articulating the problem we want to solve, and then encourages us to find the simplest solution. As a result, test-driven code has a tendency to be more useful.
8. Free of Fear - I've seen first-hand the profound effect TDD can have on a developer's confidence. Firstly, using precise examples helps us to clear the fog that usually hangs over requirements, obscuring our view going forward. And continuous automated regression testing - a nifty side-effect of doing TDD - gives us confidence looking back that a change we make hasn't broken the software. The net effect is to make us more us more courageous as we work, more willing to try new ideas, less frightened of failing. Writing software is a learning process, and - to quote from Dune - "fear is the mind-killer".
9. Getting Everyone "On The Same Page" - exploring customer requirements using test examples is a very powerful way to clear up ambiguities and potential misunderstandings, by making everything clear and concrete. And not just for developers: testers, ops teams, UX designers, security experts, technical documentation writers, marketers... we can all benefit from these examples, getting the entire team on the same page.
10. A Gateway To High-Integrity Code - TDD, done well, can open the door to more advanced kinds of software testing at relatively low extra costs. For example, if you're in the habit of refactoring duplicate tests into parameterised tests, a few extra lines of code can add an exhaustive data-driven test. Increasingly, tools and techniques normally associated with high-integrity code (e.g., model checking) are being brought into the unit testing arena. NASA JPL's Pathfinder model checker, for example, can drive tests using JUnit Theories. And there are many versions of Haskell's QuickCheck being ported for other languages and xUnit implementations. Finally, after years of high-integrity software being a largely "academic" domain, we stand on the precipise of it going mainstream.
If you're interested in learning TDD, or are a TDD practitioner looking to distinguish yourself and advance your skills, visit www.codemanship.com