February 19, 2019
When Should New Programmers Be Introduced To Code Craft?When I look back at my journey to becoming a software developer, and talk to many others who have made similar journeys, it strikes me that there was a point fairly early on when I could really have benefitted from a bit of code craft.
Programs of a few dozen lines like I used to cobble together on my Mattel Aquarius and Commodore 64 probably don't need automated tests or refactoring or a CI server.
But as I grew more confident with code, and the amount of main memory and disk space grew from kilobytes to megabytes, my hobby projects grew too from dozens of lines to hundreds to thousands.
During my coding adolescence I really could have used some automated unit tests. My code really would have benefitted from being simpler and clearer. It really would have helped to break things down into smaller, more modular chunks. It really would have made a difference if my code hadn't repeated itself quite so much. (When I discovered Copy & Paste in Turbo Pascal, I was like a kid who'd found his Dad's gun.) And it would have really, really helped if I'd used version control.
Without those foundational things, my programs experienced growing pains. As with all adolescents, there ought to be a time to take programmers aside and explain the Facts of Code:
1. You'll be spending most of your time trying to understand code, and that includes code you wrote.
2. Code gets real complicated real fast. All the "moving parts" are interconnected. You'd be surprised how many ways just a few lines of code can be broken.
3. Code will need to change many times, mostly because it takes many tries to build something good. It's all one big experiment.
4. Changing code often breaks code, including code you didn't even touch. Like I said, it's all interconnected.
5. The longer our code is broken, the longer it takes to fix. So much so that, after a while, all we seem to be doing is fixing code. That's no fun.
6. There'll be many times you're going to want to go back: to the last time your code worked, to the last time you were happy with the design, to see what was in the code in that version that the user reported a bug in, etc
7. Just because it worked on your computer doesn't mean it'll work on someone else's
8. Just because you think it's good, it doesn't mean end users will
Whether you're coding for fun or for money - above a basic level of complexity - these things are almost always true of the code we write.
Writing computer programs can be fun and rewarding. Burning the midnight oil banging your head against the wall and crying "Why isn't it working?!" or having to write reams of code all over again because you totally borked it and your last back-up was 24 hours ago... not so much.
I would have had more fun and got more done if I'd kept my code clean, if I'd beeen able to re-test it speedily, and if I'd beeen able to go back to any point in its evolution easily. And when I started my professional career, I have no doubt at all that I would have written better software, and got more done. I'm 100% sure of that.
So, with the twin aims of enabling hobbyists to have more fun and waste less time on not-fun activities like debugging and fixing code that didn't need to be broken in the first place, and to produce a new generation of more confident and more capable software developers for those who "go career" (including the millions of people who write code as part of their job but don't consider themselves "software developers" - e.g., scientists and engineers), I still firmly believe that code craft should be introduced once programmers have progressed beyond small and simple programs of < 100 lines of code.
And I would introduce code craft in this order:
1. Version Control. This is seatbelts for programmers. If you're planning to take the car out of the drive, it's time to put them on. The ability to go back to any working version of your code is the ultimate Undoability.
2. Unit Tests. Knowing if your code works is really, really useful. The sooner you know you broke the code, the sooner you can fix it, and the easier it is to keep it working. It turns out working code is a good thing. You'd be surprised just how profound an impact fast-running automated tests can have on everything else. Programmers can experiment with the confidence that if their experiment broke the code, they'd know straight away. Fast-running automated tests make us brave. Programming without fear is way more fun. I know this from 13 years programming without unit tests, and 24 years with them. Night and day.
3. Writing Readable Code. And, no, teachers: I don't mean writing more comments in your code. I mean writing code that clearly communicates what it's doing. If you're looking at a block of code and wondering "what does this do?", maybe it should be in a function with a name that tells that story.
4. Refactoring Code. The ability to make code easier to understand and easier to change without breaking it is super, super useful. Refactoring is arguably one of the most undervalued skills in programming. A woefully small percentage of professional software developers can do it, and the alarming cost of changing commercial software is the result. I've seen multi-billion dollar businesses brought to their knees by their inability to change their code. Buy me a beer and I might even name some of them.
4. Part II. Basic Principles for Writing Code That's Easy To Change. Hand-in-hand with refactoring is knowing what to refactor, and why. What makes code harder to change?
a. Code that's hard to understand is more likely to get broken by programmers who don't understand it
b. Duplicated code may need the same change made in multiple places, multiplying the cost (and risk) of making that change
c. Complex code is more likely to break because there are more ways for it to be broken
d. Changing one line of code might break other code that's connected to it (and, in turn, code that's connected to that code). We have to manage the connections in our code to localise the impact of making changes. This means our code needs to be effectively modular, built out of parts that:
i. Do one job
ii. Know as little about each other as possible
iii. Can be easily changed or swapped without effecting the rest of the code
5. Making It Easy To Get Your Working Code Out Into The World. They say "there's many a slip 'twixt cup and lip", and so many times as a hobbyist programmer (and an early professional developer) I fell at the final hurdle of getting the code I slaved over for hours on my computer to work on other people's computers.
This was because it was a manual process that involved me compiling my code, gathering together all the files my program needed, zipping it all up onto floppy disks (or copying it all across the network), unpacking all that on the target machine, changing some settings on that machine, starting some background programs and services that my program needed, and so on.
As artisanal and cool as "hand-deployed software" might sound, aside from the time this took, installs would often go wrong, and I often found myself saying those immortal words "Well, it worked on my machine!"
The whole process of going from my machine to potentially thousands of target machines needs to be speedy and reliable and - very importantly - reversible. Like all information processes that need to be speedy, reliable and reversible, that means it needs to be completely automated.
Programmers would benefit greatly from automating the building, testing (to make sure it really does work on other machines) and deployment of their programs to whatever target platforms they need them to work on. This will enable them to release their code often, which means they can get useful updates and fixes to their end users sooner and they can learn from the feedback faster. This is the secret sauce of software development. It's a learning process. Most of the value in code is added as a result of user feedback. More feedback, more often, means our programs improve faster, and we mature as programmers sooner.
It also helps us to engage with the people who use our programs more frequently and build those communities more effectively. This is the final way in which code craft adds to the fun...
Another hobby I had as a kid that followed me into adult life is playing the guitar. Playing the guitar in your bedroom is fun. Playing guitar in a band in front of real audiences is really fun. And a little scary, of course. But until you do it in front of other people, it's very hard to know if you're doing something good. The Beatles didn't get great in their bedrooms. They got great by playing hundreds and hundreds of gigs. They'd probably played thousands before their first single was released.
Now, please remember: I'm not suggesting that all people who try programming must learn code craft. Most people will give it a try, maybe get something out of it, but then leave it there. Just as most people who try the guitar learn a few chords and are perfectly happy leaving it at that.
But a proportion who try coding will really enjoy it, and they'll naturally get more ambitious with their projects. These are the people who need a bit of code craft to make that journey easier and utlinately more rewarding. Fun requires the fundamentals.
Teachers and code club organisers and should be looking for the signs, identifying who these people are, and encouraging them to learn about code craft. As a profession, we should be ready to help in any way we can.
February 8, 2019
10 Years of Codemanship2019 marks the 10th anniversary since I started my training an coaching company for developers, Codemanship.
Since 2009, I've trained more than 3,000 developers on public coourses and client-site workshops, and hundreds of thousands more have downloaded the free tutorials, watched the free screencasts and read the TDD course book online.
I've been lucky enough to work with some great clients, including the BBC, Sage, UBS, Elsevier, John Lewis, Samsung, ASOS, Ordnance Survey and many more great companies, and worked all over the UK, as well as in Ireland, France, Germany, Spain, Portugal, the Netherlands, Norway, Sweden, Finland, Romania and Poland.
I'm also proud to have started the original Software Craftsmanship conference that inspired many more, to have - with your help - raised tens of thousands of pounds for Bletchley Park, and for maths and coding clubs. I've produced a sell-out West End comedy show, and even collaborated on an album that made it into Amazon's dance top 20!
In this time of rapid change and uncertainty, who knows what the next 10 years of Codemanship may bring. One thing's for sure: it won't be dull!
To celebrate 10 years of Codemanship, I'm offering 10 exclusive 1-day code craft training workshops to be run on client sites.
You can choose from:
- Software Design Principles
- Unit Testing
And any one of 10 Tuesdays or Thursdays coming up between now and Brexit (if you're in the EU, get 'em while you can!!!)
Just pick your date, and choose your course, whip out the company credit card, and Bob's your uncle. (Payment by invoice is also available.)
Each 1-day workshop costs £1,795 for up to 20 people - that's as little as £90 per person. (Normal price for a 1-day code craft workshop is £3,995.)
January 9, 2019
Team Craft - New Codemanship Workshop for 2019I'm delighted to announce the launch of a new Codemanship workshop for 2019. Team Craft is a one-day workshop for 6-12 people that's stretches your skills in collaborative design and continuous delivery.
It's the product of 10 years running team exercises as part of Codemanship training workshops, as well as at conferences and meet-ups around the world. These experiences have been consolidated and refined into an action-packed day that will turbo-charge the Team Fu of new and established teams alike.
It promotes technical team skills like:
- Collaborative Design
- Mob Programming
- Trunk-based Development
- Continuous Integration and Continuous Delivery
Team Craft is a completely hands-on workshop that reaches the parts other workshops don't.
Over the course of the day, participants will design and deliver a working solution to a realistic real-world problem as a team.
From a standing start, they will:
- Break down the requirements
- Assign work to individuals and/or pairs
- Choose the technology stack
- Set up version control
- Set up a CI server to build and test the solution as it takes shape
- Agree on a high-level design and establish the interfaces and contracts between components/services
- Test-drive the implementation of the components
- Demonstrate a working end product to their "customer" (the trainer)
The emphasis is on learning by doing, with a 45-minute introduction with key tips on how to succeed as a team, and ending with a 45-minute retrospective where we will draw out lessons learned in the 5-hour practical exercise.
To find out more, visit http://codemanship.co.uk/teamcraft.html
October 12, 2018
TDD Training - Part I (Classic TDD), London, Sat Dec 1stMy flagship Codemanship TDD training course returns in a series of 3 standalone Saturday workshops aimed at self-funding learners.
It's the exact same highly popular training we've delivered to more than 2,000 developers since 2009, with 100% hands-on learning reinforced by our jam-packed 200-page TDD course book.
Part 1 is on Saturday Dec 1st in central London, and it's amazingly good value at just £99.
Part I goes in-depth on "classic" TDD, the super-important refactoring discipline, and software design principles that you can apply to your code as it grows and evolves to keep it easy to change so you can maintain the pace of development.
- Why do TDD?
- An introduction to TDD
- Red, Green, Refactor
- The Golden Rule
- Working backwards from assertions
- Testing your tests
- One reason to fail
- Writing self-explanatory tests
- Speaking the customer's language
- Triangulating designs
- The Refactoring discipline
- Software Design Principles
- Simple Design
- Tell, Don’t Ask
The average price of a public 1-day dev training course, per person, is around £600-800. This is fine if your company is picking up the tab.
But we've learned over the years that many devs get no training paid for by their employer, so we appreciate that many of you are self-funding your professional development. Our Saturday workshops are priced to be accessible to professional developers.
In return, developers who've attended our weekend workshops have recommended us to employers and colleagues, and most of the full-price client-site training and coaching we do comes via these referrals.
Please be advised that we do not allow corporate bookings on our workshops for self-funders. Group bookings are limited to a maximum of 4 people. If you would like TDD training for your team(s), please contact me at firstname.lastname@example.org to discuss on-site training.
Find out more at the Eventbrite course page
October 1, 2018
50% Off Codemanship Training for Start-ups and CharitiesOne of the most fun aspects of running a dev training company is watching start-ups I helped a few years ago go from strength to strength.
The best part is seeing how some customers are transforming their markets (I don't use the "d" word), and reaping the long-term benefits of being able to better sustain the pace of innovation through good code craft.
I want to do more to help new businesses, so I've decided that - as of today - start-ups less than 5 years old, with less than 50 employees, will be able to buy Codemanship code craft training half-price.
I'm also extending that offer to non-profits. Registered charities will also be able to buy Codemanship training for just 50% of the normal price.
September 25, 2018
Third-Generation Testing - Øredev 2018, Malmö, November 22ndIf you're planning on coming to Øredev in Sweden this November, I'm running a brand new training workshop on the final day about Third-Generation Software Testing.
First-generation testing was manual: running the program and clicking the buttons ourselves. We quickly learned that this was slow and often patchy, creating a severe bottleneck in development cycles.
Second-generation testing removed that bottleneck by writing code to test our code.
But what about the tests we didn't think of?
Exploratory testing brought us back to a manual process of exploring what else might be possible - what combinations of inputs, user actions and pathways - using the code we delivered, outside of the behaviours encoded in our automated tests.
Manual exploratory testing suffers from the same setbacks as any kind of manual testing, though. It's slow, and can miss heaps of cases in complex logic.
Third-generation testing automates the generation of the test cases themselves, enabling us to explore much wider state spaces than a manual process could ever hope to achieve. With a little extra test code, and a bit of ingenuity, you can explore thousands, tens of thousands, hundreds of thousands and even millions of extra test cases - combinations, paths, random inputs and ranges - using tools you already know.
In this workshop, we'll explore some simple techniques for adapting and reusing our existing unit tests to exhaustively test our critical code. We'll also look at techniques for identifying what code might need us to go further, and how we can use Cloud technology to execute millions of extra tests in minutes.
You can find out more and book your place at http://oredev.org/2018/sessions/third-generation-software-testing
June 21, 2018
Adopting TDD - The Codemanship RoadmapI've been doing Test-Driven Development for 20 years, and helping dev teams to do it for almost as long. Over that time I've seen thousands of developers and hundreds of teams try to adopt this crucial enabling practice. So I've built a pretty clear picture of what works and what doesn't when you're adopting TDD.
TDD has a steep learning curve. It fundamentally changes the way you approach code, putting the "what" before the "how" and making us work backwards from the question. The most experienced developers, with years of test-after, find it especially difficult to rewrite their internal code to make it comfortable. It's like learning to write with your other hand.
I've seen teams charge at the edifice of this learning curve, trying to test-drive everything from Day #1. That rarely works. Productivity nosedives, and TDD gets jettisoned at the next urgent deadline.
The way to climb this mountain is to ascend via a much shallower route, with a more gentle and realistic gradient. You will most probably not be test-driving all your code in the first week. Or the first month. typically, I find it takes 4-6 months for teams to get the hang of TDD, with regular practice.
So, I have a recommended Codemanship Route To TDD which has worked for many individuals and teams over the last decade.
Week #1: For teams, an orientaton in TDD is a really good idea. It kickstarts the process, and gets everyone talking about TDD in practical detail. My 3-day TDD workshop is designed specifically with this in mind. It shortcuts a lot of conversations, clears up a bunch of misconceptions, and puts a rocket under the team's ambitions to succeed with TDD.
Week #2-#6: Find a couple of hours a week, or 20 minutes a day, to do simple TDD "katas", and focus on the basic Red-Green-Refactor cycle, doing as many micro-iterations as you can to reinforce the habits
Week #7-#11: Progress onto TDD-ing real code for 1 day a week. This could be production code you're working on, or a side project. The goal for that day is to focus on doing it right. The other 4 days of the week, you can focus on getting stuff done. So, overall, your productivity maybe only dips a bit each week. As you gain confidence, widen this "doing it right" time.
Week #12-#16: By this time, you should find TDD more comfortable, and don't struggle to remember what you're supposed to do and when. Your mind is freed up to focus on solving the problem, and TDD is becoming your default way of working. You'll be no less productive TDD-ing than you were befpre (maybe even more productive), and the code you produce will be more reliable and easier to change.
The Team Dojo: Some teams are keen to put their new TDD skills to the test. An exercise I've seen work well for this is my Team Dojo. It's a sufficiently challenging problem, and really works on those individual skills as well as collaborative skills. Afterwards, you can have a retrospective on how the team did, examining their progress (customer tests passed), code quality and the disciplie that was applied to it. Even in the most experienced experienced teams, the doj will reveal gaps that need addressing.
Graduation: TDD is hard. Learning to test-drive code involves all sorts of dev skills, and teams that succeed tell me they feel a real sense of achievement. It can be good to celebrate that achievement. Whether it's a party, or a little ceremony or presentation, when organisations celebrate the achievement with their dev teams, it shows reall commitment to them and to their craft.
Of course, you don't have to do it my way. What's important is that you start slow and burn your pancakes away from the spotlight of real projects with real deadlines. Give yourself the space and the safety to get it wrong, and over time you'll get it less and less wrong.
If you want to talk about adopting TDD on your team, drop me a line.
June 10, 2018
Only This Week - Save Up To 65% On Codemanship Training
For one week only, we’re offering a veritable picnic of on-site code craft training at never-to-be repeated prices.
Save up to 65%, and train your developers in key skills like TDD, refactoring and OO design for as little as £40 per person per day. That’s full, action-packed hands-on days of code craft training.
Book any Codemanship training course before June 17th and save a whopping 50%. Book all four of our courses and save 65%. That’s a massive £12,000.
Find out more by visiting www.codemanship.com
June 8, 2018
The Entire Codemanship TDD Course Book - Absolutely FreeChanges are afoot with my code craft training and coaching company, Codemanship, and as part of that, I'm making my 222-page TDD course book available to download as a spiffy full-colour PDF for free.
It covers everything from the basics of Red-Green-Refactor, through software design principles to apply to your growing code, all the way up to advanced topics other TDD books and courses don't reach, like mutation testing, property-based and data-driven testing and Continuous Inspection. Many people who've read the book have commented on how straightforward and to-the-point it is. Shorter than most TDD/code craft books, but covers more, all in practical detail.
Of course, to get the best from the book, you should try the exercises.
Better still, try the exercises with the guy who wrote the book in the room to guide you.
March 9, 2018
S.O.L.I.D. C# - Online Training Event, Sat Apr 14thDetails of another upcoming 1-day live interactive training workshop for C# developers looking to take their design skills to the next level.
I'll be helping you get to grips with S.O.L.I.D. and much more besides with practical hands-on tutorials and exercises.
Places are limited. You can find out more and grab your place at https://www.eventbrite.co.uk/e/solid-c-tickets-44018827498