September 22, 2017
Evil FizzBuzz (or "So you think you're a team?")Among the advanced topics we cover on the third day of the Codemanship TDD course, Continuous Integration presents some of the biggest challenges for dev teams.
Participants are subjected to an exercise called Evil FizzBuzz, which you might like to try on your team (or at your coding event).
Based on the drinking game, FizzBuzz is a very simple algorithm.
1. Generate a sequence of integers from 1 to 100.
2. Any integers that are divisible by 3, replace with "Fizz".
3. Any that are divisible by 5, replace with "Buzz".
4. Any that are divisible by 3 and 5, "FizzBuzz".
5. And, for a bit of extra spice, any that are prime numbers, replace with - or concatenate if already "Fizz" or "Buzz" - "Wizz".
6. Output as a comma-delimited string.
So the first 15 in the sequence would go:
1, Wizz, FizzWizz, 4, BuzzWizz, Fizz, Wizz, 8, Fizz, Buzz, Wizz, Fizz, Wizz, 14, FizzBuzz
This is pretty straightforward for a programmer to code a solution to, and makes a spiffy exercise for learning about triangulation in TDD.
Now to make it evil...
* Split the group up into 6 pairs (or threes, or ones, depending on how many people you've got).
* Assign each part of FizzBuzz above (1-6) to a pair. They can only work on code for that part of the whole.
* Task them to work together - but only coding/TDD-ing their individual parts - to deliver a complete solution that produce the desired output.
Give them about an hour. And stand back and enjoy the train wreck.
To achieve this, they need distributed version control. So someone in the group needs to create, say, a GitHub repository that they can all contribute to. Then someone needs to put the skeleton of a source code project in that repository for pairs to work in. Then someone needs to set up Continuous Integration for that source code project so that merges can be built and tested.
All of this typically takes up more than half the time allotted. And until they have a green build to merge into, everybody's blocked from pushing. The yak shaving's what trips up half the groups I've seen attempt Evil FizzBuzz. DevOps is not commonly our strong suit.
And, of course, they have to agree on stuff. They have to agree on what language they're going to use. They have to agree on a basic design for how all the parts will fit together. They have to agree on how the process of collaboration's going to work if they're not going to end up tripping over each other's feet.
This is where the other half usually come unstuck. Most developers and dev orgs just aren't used to this level of collaboration. It's intense. Really intense. What usually happens is they either spend 50 minutes out of their hour arguing and getting nowhere, or they just go off into their separate corners and do their own thing. Both lead to failure.
And then there's the whole lesson behind the exercise: if the group isn't disciplined about CI, they will fail to deliver Evil FizzBuzz. Guaranteed.
What I mean by that is that the protocols of CI need to be keenly observed to prevent pairs merging conflicting changes on top of each other. And the feedback CI gives us about where the code's going must not be ignored. Every pair should be keeping one eye on the build. When they see a new build succeed, it's time to get the latest changes and see how it fits in with what you're doing.
Agreeing on things. DevOps. Constant communication. Situational awareness. Coordinating. All things dev teams tend to suck at.
And that's why I love this exercise. Especially on the rare occasions that you see a group ace it, like my training client this week. It speaks volumes about them as a team, and it's a joy to watch it unfold as each build goes green and you see the solution taking shape in front of your eyes.
The purpose of Evil FizzBuzz is to (hopefully) open dev teams' eyes to CI as a means of communication in collaborative design, and in particular to just how intense that collaboration often needs to be, and how disciplined about CI they need to be for it to work.
I'll bet you a shiny penny your team can't do it. Most can't.
Now prove me wrong.
August 19, 2017
Time For Learning - An Inconvenient TruthI've watched many tweet debates ("twebates"?) recently on the subject of finding time for learning in software development.
In the culture of the code craft movement, the consensus has been that you have to put in the hours. And by that, they tend to mean your own hours, outside of the day job. I've seen many job ads stipulating that candidates would need to show evidence of this extra-curricular commitment: blogs, speaking at conferences, OSS contributions, personal projects and all that.
The counter argument comes chiefly from people advocating greater diversity in software. Single parents, for example, have a lot on their plate that makes popping along to the Extreme Tuesday Club or speaking at a conference in, say, Norway, logistically difficult. Where's the time in their day/week/year to read all three volumes of the Art of Computer Programming?
My perspective on all this, I'm afraid, is cold and sobering. It takes a lot of reading and talking and sharing and experimentation (also known as "trying new stuff") to get good at writing software - and to stay good at it.
That's an inescapable reality. It's an inconvenient truth about software development. Everyone wants those skills, but nobody's willing to pay to develop them. Cui bono? Demonstrably, the employer benefits from more skilled developers. So they should make a contribution to bulding those skills. Simples.
What we're really debating is where does that time come from? Most employers aren't willing to support learning out of their own budgets. They expect developers to arrive fully formed, and that means that anything aside from direct on-the-job experience is down to us to learn in our own time. It's wholly inadequate to the task because we can only learn things that have immediate relevance to what we're doing.
Imagine if doctors had to learn everything that way. "Well, Mr Gorman, I'm afraid you have a burst appendix. This hasn't come up before, so I'm going on a course to learn how to treat it. See you in 2 weeks."
This also excludes people whose backgrounds and situations make finding those extra hours every week very difficult. This is why I believe offering developers "10% time" or "20% time" is really very necessary if we want a more diverse profession. This is another inconvenient truth about software development. Job ads that demand large amounts of extra hours of "elective" work are effectively restricting applications to people with not a lot else going on in their lives.
In practice, the code crafter landscape is still pretty homogenous. When I run public events, we still get about 85% men, and most of those are white. Very occasionally, someone with a disability comes along - and I always try to make sure the event's accessible, and advertise that fact.
But the fact remains that there are a lot of potentially great developers out there who, much as they'd like to, can't get along to a Saturday workshop, and whose employers won't let them take time out for learning during the working week.
Those are the people we in the dev community rarely see. But we shouldn't assume that they're not there because they don't want to learn.
If your job ads say you're committed to increasing diversity, and then demand a large portfolio of extra-curricular activities, you have a cognitive dissonance.
So, my question is this: how do we square this circle? My current belief is that we must adapt the very nature of our jobs so that time for learning and deliberate practice is built into the working week. I believe that this should become the norm, whereas today it's very much the exception.
I come from the school of "if this needs to happen, then let's just do it". We made the mistake, as professionals, of letting other people manage our time. If we're to move forward then that needs to stop. As "prima donna" as this sounds, we should take that time, and not ask for permission.
Because if we ask for permission, we know what the answer will be.
July 31, 2017
Codemanship Code Craft "Driving Test" - Code Quality CriteraMuch pondering today about the code quality standards that should be applied in the Codemanship Code Craft Driving Test we'll be trialling at the end of the summer.
Since it's a test, I think it's fair to apply more rigorous and unyielding standards, provided that these are laid out unambiguously in advanced.
We can divide it up into 7 key areas, with some slightly different criteria for test code to allow for more verbose method names and a bit more code duplication:
1. It Works
* Your solution passes all of the customer tests we'll give you
* Your solution also survives a more exhaustive suite of tests to hunt for any lurking bugs
2. It's Readable
* The Conceptual Correlation between your code and the requirements is > 80%
* Non of your identifiers contain > 20 characters (except for test method names)
* No line of your code contains > 100 characters
3. It's Low in Duplication
* A check using Simian will reveal no more than 15% code duplication (We'll give you the precise Simian options so you can check for yourself)
4. It's Made of Simple Parts
* No method will contain > 10 LOC
* No method will have > 2 branches
* No method will have > 3 parameters
* No method will have Boolean parameters
* No class will have > 6 methods
5. It's Made of Swappable Parts
* Excluding in your tests, all dependencies on other classes in your solution will be swappable by dependency injection. Use of DI frameworks will also be forbidden. (Dependency Inversion)
* No non-test class will invoke any method on an instance of another class in the solution that can't be easily extended or swapped (e.g., in C#, only methods on interfaces or virtual methods can be invoked)
6. The Parts Are Loosely Coupled
* No class will depend on > 3 other classes in your solution
* No method will exhibit Feature Envy (when a method of one class uses more than one method of another) for other classes in your solution (Tell, Don't Ask)
* No class or interface will expose features to another class that it doesn't use (Interface Segregation)
* No class will invoke methods on solution classes which are not direct collaborators (i.e., fields or parameters) (Law of Demeter)
7. Test Code Quality
* No unit test will make more than one assertion (or mock object equivalent)
* There will be exactly one unit test method per requirements rule, the name of the test will clearly describe the rule
* All of the unit tests will pass without any external dependencies
* There will be a maximum of 10% integration test code, packaged separately
* The tests will run in < 10 seconds
* Tests will contain < 25% code duplication
Now, even though there's quite a lot of meat on these bones, these criteria may change, of course. But probably not much.
In the trial, I'll be verifying many of them by hand. This will give ma chance to validate them and iron out any conceptual kinks.
The long-term intention is that most - if not all - of these checks will be automated. Initially, I'm working on doing that in C# for the .NET developer community.
The code quality criteria will form half the score for the driving test. To pass it, you'll also need to demonstrate your practices and habits, and explain why you're doing them, so we can evaluate how much insight you have into code craft and the reasons for it. This will be done by recording a 30-minute screencast at some point during the test that we can assess.
More news soon.
July 10, 2017
Codemanship Bite-Sized - 2-Hour Trainng Workshops for Busy Teams
One thing that clients mention often is just how difficult it is to make time for team training. A 2 or 3-day course takes your team out of action for a big chunk of time, during which nothing's getting delivered.
For those teams that struggle to find time for training, I've created a spiffing menu of action-packed 2-hour code craft workshops that can be delivered any time from 8am to 8pm.
- Test-Driven Development workshops
- Introduction to TDD
- Specification By Example/BDD
- Stubs, Mocks & Dummies
- Outside-In TDD
- Refactoring workshops
- Refactoring 101
- Refactoring To Patterns
- Design Principles workshops
- Simple Design & Tell, Don’t Ask
- Clean Code Metrics
To find out more, visit http://www.codemanship.co.uk/bitesized.html
July 9, 2017
Why You Should Put Learning Opportunities Front-And-Centre In Dev Recruitment
Devs: what would lure you away from your current job?— Codemanship (@codemanship) July 6, 2017
A little Twitter poll I ran under the Codemanship acccount seems to confirm something that many of us have been saying for years. 41% of those polled said they could be lured from their current job by greater opportunities to learn.
Software development is a career that involves lifelong learning, and lot's of it. That's how we progress. So it doesn't come as a surprise that it was ranked significantly higher than "More money".
It's surprising, then, that learning opportunities don't figure higher in dev recruitment campaigns. I've banged this drum with clients many, many times. Want to attract and retain great developers? Make learning - mentoring, conferences, training, time to read, time to share - a greater part of the job. No, scratch that. Accept that learning is the job, and build your team culture around that inescapable fact.
When you're hiring, don't just look for what they know now. Look for their potential to learn. And their potential to teach (e.g. by example) the stuff they know so others can learn from them. And clear the way for that to happen. A lot.
Sadly, such employers are too few and far between. The unreasonable and unrealistic attitude that developers should arrive knowing everything they need to know, and no learning should go on on company time, is a leading cause of developer attrition.
It's also the reason why you've been searching in vain these last 6 months for a fluent Mandarin and Dutch-speaking full-stack JS/Node/Java/Clojure/Ruby/NoSQL/SQL/Docker/COBOL/Eiffel/Vim/Linux/Windows developer who has an HGV license and is licensed to practice medicine (salary: market rate).
Software developers tend to be highly educated, but the most important thing we learn is how to learn and it's one of the most important skills your money can buy. In return, one of the most valuable perks you can offer them is more opportunities to learn.
As a professional trainer and mentor, I am of course biased. I tell devs what I do, and they say "Wow, you must be really busy!" and I say "You'd think so, wouldn't you?" But the reality is that the majority of employers don't offer their devs any training at all, let alone time to, say, read a book.
The kind of bosses I run training for are unfortunately very much in the minority. Although, interestingly, they seem to have a lot less trouble hiring good developers.
June 10, 2017
Could You Be A Mentor To An Aspiring Software Developer?I've been beavering away these last few weeks putting together the basis for an initiative that will enable experienced software developers to mentor new programmers looking to become developers one day.
It'll take the form of a Software Developers' Guild - a sort of clearing house that helps talented new programmers find old hands who can provide "light-touch" guidance over the long-term (4-6 years).
I see it working along similar lines to what I've been doing with my "apprentice" Will Price (who's just finished his final exams for his CS degree, and has turned out pretty spiffy as a developer, too). I've been pairing with Will regularly for a couple of hours every fortnight or so, working on the skills formal education tends to leave out (using version control, test automation, TDD< refactoring, design principles and other practical aspects of code craft).
I've also been nudging him towards certain sources of information: books, blogs, conferences, and so forth, and generally giving him a steer on what he would find most useful to know as a software developer.
Reflecting on how it's gone, both Will and I feel it's been of immense value - and not just for Will. Mentoring someone new to this field has spurred me to learn new things, too (like Python, for example) and reinvigorated my enthusiasm for learning. So, after twelvety-stupid years as a developer, I feel renewed. And looking forward to doing it again.
The industry is also up on the deal by one potentially great developer.
My thinking of late has been that this could be a workable route to avoiding the Groundhog Day that our profession seems stuck in, where new developers have to go through the same long process of rediscovery, with all the false leads and dead ends I wasted years on.
And so, this year, I tentatively begin the process of trying to scale this approach up. You can find out a bit more by visiting the Software Developers' Guild holding page. And, maybe, you'd be interested in becoming a mentor?
I'm looking for experienced developers who've "been around the block at least twice" ( call it my Rule of Two), and who'd be willing and able to provide a similar kind of light-touch guidance to someone at university, or from a code club, or returning to work after raising children or caring for a relative, or retraining for a career change, etc.
Could that be you?
June 5, 2017
The Codemanship TDD "Driving Test" - Initial UpdateA question that gets asked increasingly frequently by folk who've been on a Codemanship TDD workshop is "Do we get a certificate?"
Now, I'm not a great believer in certification, especially when the certificates are essentially just for turning up. For example, a certificate that says you're an "agile developer", based on sitting an exam at the end of a 2-3 day training course, really doesn't say anything meaningful about your actual abilities.
Having said all that, I have pioneered programs in the past that did seem to be a decent indicator of TDD skills and habits. First of all, to know if a juggler can juggle, we've got to see them juggle.
A TDD exam is meaningless in most respects, except perhaps to show that someone understands why they're doing what they're doing. Someone may be in the habit of writing tests that only ask one question, but I see developers doing things all the time that they "read in a book" or "saw their team doing" and all they're really doing is parroting it.
Conversely, someone may understand that tests should ideally have only one reason to fail so that when they do fail, it's much easier to pinpoint the cause of the problem, but never put that into practice. I also see a lot of developers who can talk the talk but don't walk the walk.
So, the top item on my TDD certification wish-list would be that it has to demonstrate both practical ability and insight.
In this respect, the best analogy I can think of is a driving test; learner drivers have to demonstrate a practical grasp of the mechanics of safe driving as well as a theoretical grasp of motoring and the highway code. In a TDD "driving test", people would need to succeed at both a practical and a theoretical component.
The practical element would need to be challenging enough - but not too challenging - to get a real feel for whether they're good enough at TDD to scale it to non-trivial problems. FizzBuzz just won't vut it, in my experience. (Although you can weed out theose who obviously can't even do the basics in a few minutes.)
The Team Dojo I created for the Software Craftsmanship conference seems like a viable candidate. Except it would be tackled by you alone (which you may actually find easier!) In the original dojo, developers had to tackle requirements for a fictional social network for programmers. There were a handful of user stories, accompanied by some acceptance tests that the solution had to pass to score points.
In a TDD driving test, I might ask developers to tackle a similar scale of problem (roughly 4-8 hours for an individual to complete). There would be some automated acceptance tests that your solution would need to pass before you can complete the driving test.
Once you've committed your finished solution, a much more exhaustive suite of tests would then be run against it (you'd be asked to implement a specific API to enable this). I'm currently pondering and consulting on how many bugs I might allow. My instinct is to say that if any of these tests fail, you've failed your TDD driving test. A solution of maybe 1,000 lines of code should have no bugs in it if the goal is to achieve a defect density of < 0.1/KLOC. I am, of course, from the "code should be of high integrity" school of development. We'll see how that pans out after I trial the driving test.
So, we have two bars that your solution would have to clear so far: acceptance tests, and exhaustive testing.
Provided you successfully jump those hurdles, your code would then be inspected or analysed for key aspects of maintainability: readability, simplicity, and lack of duplication. (The other 3 goals of Simple Design, basically.)
As an indicator, I'd also measure your code coverage (probably using mutation testing). If you really did TDD it rigorously, I'd expect the level of test assurance to be very high. Again, a trial will help set a realistic quality bar for this, but I'm guessing it will be about 90%, depending on which mutation testing I use and which mutations are switched on/off.
Finally, I'd be interested in the "testability" of your design. That's usually a euphamism for whether or not dependencies betwreen your modules are easily swappable (by dependency injection). The problem would also be designed to require the use of some test doubles, and I'd check that they were used appropriately.
So, you'd have to pass the acceptance tests to complete the test. Then your solution would be exhaustively tested to see if any bugs slipped through. If no bugs are found, the code will be inspected for basic cleanliness. I may also check the execution time of the tests and set an upper limit for that.
First and foremost, TDD is about getting shit done - and getting it done right. Any certification that doesn't test this is not worth the paper it's printed on.
And last, but not least, someone - initially me, probably - will pair with you remotely for half an hour at some random time during the test to:
1. Confirm that it really is you who's doing it, and...
2. See if you apply good TDD habits, of which you'd have been given a list well in advance to help you practice. If you've been on a Codemanship TDD course, or seen lists of "good TDD habits" in conference talks and blog posts (most of which originated from Codemanship, BTW), then you'll already know what many of these habits are
During that half hour of pairing, your insights into TDD will also be randomly tested. Do you understand why you're running the test to see it fail first? Do you know the difference between a mock and stub and a dummy?
Naturally, people will complain that "this isn't how we do TDD", and that's fair comment. But you could argue the same thing in a real driving test: "that's not how I'm gonna drive."
The Codemanship TDD driving test would be aimed at people who've been on a Codemanship TDD workshop in the last 8 years and have learned to do TDD the Codemanship way. It would demonstrate not only that you attended the workshop, but that you understood it, and then went away and practiced until you could apply the ideas on something resembling a real-world problem.
Based on experience, I'd expect developers to need 4-6 months of regular practice at TDD after a training workshop before they'd be ready to take the driving test.
Still much thinking and work to be done. Will keep you posted.
May 9, 2017
What Makes a Software Developer? The Rule of TwoI've been thinking a lot recently about what might qualify someone as a "software developer". For sure, it's not just someone who can code. (Any more than a builder is just someone who can lay bricks.)
One rule of thumb I've used with some success over the years is a rule of two: a software developer, in my experience, is someone who has practical hands-on skills in at least two of everything.
* 2 different programming paradigms (e.g., structured & OO)
* 2 different technology stacks (e.g., LAMP and .NET)
* 2 different kinds of application (e.g., desktop and mobile)
* 2 different problem domains (e.g., banking and medicine)
* 2 different approaches to development (e.g., Extreme Programming & RUP)
Essentially, someone who's been around the block at least twice in their careers.
The reason why I think this matters is that folk tend to need to see multiple examples of something before they can start to draw some key underlying insights. If you've only ever done BDD, you may not be aware that almost all approaches to requirements specification are example- or scenario-driven. If you've only ever worked in, say, Java, you may miss the fact that encapsulation isn't exclusively an OO concept. (Yes, you can have loosely coupled modules in Pascal, C, etc, too).
I'd also be interested in the responsibilities a developer has taken on in their careers. I've been a programmer, a tech lead, an architect, a requirements analyst, a methodologist, a strategist, a coach, a conference speaker, a conference organiser, an author, a business owner, and a trainer in my twelvety five years in this career. Wearing multiple hats - like working in multiple languages - can bring insights that decades working exclusively at the code face would probably miss.
So now, as my attentions turn to focus on the whole question of long-term mentoring for would-be software developers, the >rule of two may well be a key part of the process of identifying who might make good mentors, as well as potentially provide a roadmap for mentoring itself. Essentially, we'd be looking to guide rookies at least twice around the block, allowing them a chance to build those insights for themselves.
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 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