January 23, 2018

Learn TDD with Codemanship

Without Improving Code Craft, Your Agile Transformation Will Fail

"You must be really busy!" is what people tend to say when I tell them what I do.

It stands to reason. If software is "eating the world", then code craft skills must be highly in demand, and therefore training and coaching for developers in those skills must be selling like hotcakes.

Well, you'd think so, wouldn't you?

The reality, though, is that code craft is critically undervalued. The skills needed to deliver reliable, maintainable software at a sustainable pace - allowing businesses to maintain the pace of innovation - are not in high demand.

We can see this both in the quality of code being produced by the majority of teams, and in where organisations focus their attentions and where they choose to invest in developing skills and capabilities.

"Agile transformations" are common. Some huge organisations are attempting them on a grand scale, sending their people on high-priced training courses and drafting in hundreds of Agile coaches - mostly Scrum-certified - to assist, at great expense.

Only a small minority invest in code craft at the same time, and typically they invest a fraction of the time, effort and money they budget for Agile training and coaching.

The end result is software that's difficult to change, and an inability to respond to new and changing requirements. Which is kind of the whole point of Agile.

Let me spell it out in bold capital letters:

IF CODE CRAFT ISN'T A SIGNIFICANT PART OF YOUR AGILE TRANSFORMATION, YOU WILL NEVER ACHIEVE AGILITY.

You can't be responsive to change if your code is expensive to change. It's that simple.

While you build your capability in product management, agile planning and all that scrummy agile goodness, you also need to be addressing the factors that increase the cost of changing code. Skills like unit testing, TDD, refactoring, SOLID, CI/CD are a vital part of agility. They are hard skills to crack. A 3-day Certified Code Crafter course ain't gonna cut the mustard. Developers need ongoing learning and practice, with the guidance of experienced code crafters. I was lucky enough to get that early in my career. Many other developers are not so lucky.

That's why I built Codemanship; to help developers get to grips with the code-facing skills that few other training and coaching companies focus on.

But, I'll level with you: even though I love what I'm doing, commercially it's a struggle. The reason so few others offer this kind of training and coaching is because there's little money it. Decision makers don't have code craft on their radars. There's been many occasions when I've thought "May as well just get Scrum-certified". I'm not going to go down without a fight, but what I really need (apart from them to cancel Brexit) is for a shift in the priorities of business who are currently investing millions on Agile transformations that are all but ignoring this crucial area.

Of course, those are my problems, and I made my choices. I'm very happy doing what I'm doing. But it's indicative of a wider problem that affects us all. Getting from A to B is about more than just map reading and route planning. You need a well-oiled engine to get you there, and to get you wherever you want to go next. Too many Agile transformations end up broken down by the side of the road, unable to go anywhere.


January 15, 2018

Learn TDD with Codemanship

Refactoring to the xUnit Pattern

16 days left to get my spiffy on-site Unit Testing training workshop at half-price. It's jam-packed with unit testy goodness. Here's a little taste of the kind of stuff we cover.

In the introductory part of the workshop, we look at the anatomy of unit test suites and see how - from the most basic designs - we eventually arrive by refactoring at the xUnit design pattern for unit testing frameworks.

If you've been programming for a while, there's a good chance you've written test code in a Main() method, like this:



This saves us the bother of having to run an entire application to get quick feedback while we're adding or changing code in, say, a library.

Notice that there are three components to this test:

Arrange - we set up the object(s) we're going to use to be in the initial state we need for this particular test

Act - we invoke the method we want to test

Assert - We ask questions about the final state of our test object(s) to see if the action has had the desired effect

Simples!

Of course, a real-world application might need hundreds or even thousands of such tests. Our Main() method is going to get pretty big and unwieldy if we keep adding more and more test cases.

So we can break it down into multiple test methods, one for each test case. The name of each test method can clearly describe what the test is.



Our original Main() method just calls all of our test methods.

But still, when there are hundreds or thousands of test methods, we can end up with one ginormous class. That too can be broken down, grouping related test methods (e.g., all the tests for a bank account) into smaller test fixtures.



Note that each test fixture has a method that invokes all of its test methods, so our original main method doesn't need to invoke them all itself.

This is a final piece of the unit testing jigsaw: the class that tells all of our test fixtures to run their tests. We call this a test suite.



At the most basic level, this simple design gives us the ability to write, organise and run large numbers of tests quickly.

As time goes on, we may add a few bells and whistles to streamline the process and make it more useful and usable.

For example, in our current design, when an assertion fails (using .NET's built-in Debug.Assert() method), it will halt execution. If the first test fails in a suite of 1,000 tests, it won't run the other 999. So we might write our own assertion methods to check and report test failures without halting execution.

And we might want to make the output more user friendly and display more helpful results, so we may add a custom formatter/reporter to write out test results.

And - I can attest from personal experience - it can be a real pain the you-know-what to have to remember to write code to invoke every test method on every test fixture. So we might create a custom test runner - not just a Main() method - that automates the process of test discovery and execution.

We could, for example, invert the dependencies in our test suite on individual test fixtures by extracting a common interface that all fixtures must implement for running its tests. Then we could use reflection or search through the source code for all classes that implement that interface and build the suite automatically.

Likewise, we could specify that test methods must have a specific signature (e.g., start with "Test", a void return type, and have no parameters) and search for all test methods that match.

In my early career, I wrote several unit testing frameworks, and they tended to end up with a similar design. Thousands more had the same experience, and that commonality of experience is captured in the xUnit design pattern for unit testing frameworks.



The original implementation of this pattern was done in Smalltalk ("SUnit") by Kent Beck, and many more have followed in pretty much every programming language you can think of.

In the years since, some useful advanced features have been added, which we'll explore later in the workshop. But, under the hood, they're all pretty much along these lines.







January 1, 2018

Learn TDD with Codemanship

New Year 2018 Special Offer - 50% off Unit Testing training

A good suite of fast-running unit tests (tests that don't have external dependencies) is essential to our ability to sustain the pace of delivering clean, reliable code.

But unit testing practices are still not as widespread as they should be. Many development teams still relay on automated system/GUI testing, and far too many rely totally on expensive and slow manual testing. This is the most common cause of slow release cycles and major delays we see on a daily basis. If your team is stuck in "stabilisation phase hell", fast-running unit tests may very likely be part of the solution.

Unit tests are the foundation for code craft, and developers and teams looking for a place to start find my 1-day unit testing workshop very helpful.

To celebrate New Year 2018, we're offering a whopping 50% discount all the way through January. Confirm your booking by Jan 31st and get it half-price.

It comes in Java and .NET flavours, using the most popular unit testing tools, and covers everything you'll need to get started, plus more advanced techniques like mocking and stubbing, fluent assertions, parameterised and data-driven testing, as well as unit testing patterns and architectures you'll find useful as your test suites grow. We end by introducing you to foundational Test-Driven Development, opening the door to further code craft learning.

You can find out more at http://www.codemanship.com/unittesting.html


November 20, 2017

Learn TDD with Codemanship

10 Days Left to Book Half-Price TDD Training

A quick reminder about the special offer I'm running this month to help teams whose training budgets have been squeezed by Brexit uncertainty.



If you confirm your booking for a 1, 2 or 3-day TDD training workshop this month (for delivery before end of Feb 2018), you'll get a whopping 50% off.

This is our flagship course - refined through years delivering TDD training to thousands of developers - and is probably the most hands-on and comprehensive TDD and code craft training workshop you can get... well, pretty much anywhere. There are no PowerPoint presentations, just live demonstrations and practical exercises to get your teeth into.

As well as the basics, we cover BDD and Specification by Example, refactoring, software design principles, Continuous Integration and Continuous Delivery, end-to-end test-driven design, mocking, stubbing, data-driven and property-based unit testing, mutation testing and heap more besides. It's so much more than a TDD course!

And every attendee gets a copy of our exclusive 200-page TDD course book, rated 5 stars on goodreads.com, which goes into even more detail, with oodles of extra practical exercises to continue your journey with.

If you want to know more about the course, visit http://www.codemanship.com/tdd.html, or drop me a line.


November 6, 2017

Learn TDD with Codemanship

Half-Price TDD Training - Special Offer



Just a quick plug for a special offer Codemanship are doing for November. To help companies whose training budgets are being squeezed by Brexit uncertainty, if you confirm your booking for a 1, 2 or 3-day TDD training workshop this month (for delivery before end of Feb 2018), you'll get a whopping 50% off.

This is our flagship course - refined through years delivering TDD training to thousands of developers - and is probably the most hands-on and comprehensive TDD and code craft training workshop you can get... well, pretty much anywhere. There are no PowerPoint presentations, just live demonstrations and practical exercises to get your teeth into.

As well as the basics, we cover BDD and Specification by Example, refactoring, software design principles, Continuous Integration and Continuous Delivery, end-to-end test-driven design, mocking, stubbing, data-driven and property-based unit testing, mutation testing and heap more besides. It's so much more than a TDD course!

And every attendee gets a copy of our exclusive 200-page TDD course book, rated 5 stars on goodreads.com, which goes into even more detail, with oodles of extra practical exercises to continue your journey with.

If you want to know more about the course, visit http://www.codemanship.com/tdd.html, or drop me a line.


September 22, 2017

Learn TDD with Codemanship

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

Learn TDD with Codemanship

Time For Learning - An Inconvenient Truth

I'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

Learn TDD with Codemanship

Codemanship Code Craft "Driving Test" - Code Quality Critera

Much 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

Learn TDD with Codemanship

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.

Choose from:

  • 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

    • S.O.L.I.D.

    • Clean Code Metrics




To find out more, visit http://www.codemanship.co.uk/bitesized.html



July 9, 2017

Learn TDD with Codemanship

Why You Should Put Learning Opportunities Front-And-Centre In Dev Recruitment



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.

Funny, that...