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.
September 3, 2017
Iterating is THE Requirements DisciplineOK. Let's get serious about software requirements, shall we?
The part where we talk to the customer and write specifications and agree acceptance tests and so forth? That's the least important part of figuring out what software we need to build.
You heard me right. Requirements specification is the least important part of requirements analysis.
THE. LEAST. IMPORTANT. PART.
It's 2017, so I'm hoping you've heard of this thing they have nowadays (and since the 1970s) called iterative design. You have? Excellent.
Iterating is the most important part of requirements analysis.
When we iterate our designs faster, testing our theories about what will work in shorter feedback loops, we converge on a working solution sooner.
We learn our way to Building The Right ThingTM.
Here's the thing with iterative problem solving processes: the number of iterations matters more than the accuracy of the initial input.
We could agonise over taking our best first guess at the square root of a number, or we could just start with half the input number and let the feedback loop do the rest.
I don't know if you've been paying attention, but that's the whole bedrock of Agile Software Development. All the meetings and documents and standards in the world - the accoutrements of Big Process - don't mean a hill of beans if you're only allowing yourself feedback from real end users using real working software every, say, 2 years.
So ask your requirements analyst or product owner this question: "What's your plan for testing these theories?"
I'll wager a shiny penny they haven't got one.
August 29, 2017
Putting .NET Unit Tests In The Same Project As Source Code (?)Something's been bugging for me for quite some time. About 15 years, in fact.
The convention in .NET development has been to have separate source and test projects.
While this provides a clean separation when it comes to builds, that comes at a price. Any class or method I want to reference in a test has to be public.
So either we make a bunch of stuff public so we can test it, or we test through a teeny tiny public "keyhole", which leads to the code being tested often being many layers removed from its unit tests. This is not good for debuggability.
In Java, we don't really do this. There would typlically be one Eclipse or IntelliJ project with a folder for the source code and a folder for the test code. Classes that are only internally visible inside that project can be unit tested easily.
And I've been wondering why we don't also do this in .NET? What if I were to move the tests into a subfolder of the source project?
Then I could make the class under test internal, minimising visibility is that class doesn't need to be exposed in an API.
Ah, but - I hear you ask - what happens when we build the project? Do we really want to include all the public test classes and have a reference to the unit testing framework?
No problem. We can edit the .csproj file to only include the tests and associated DLL references in a debug build.
A next step might be to create a Visual Studio project template that's already set up with the Test subfolder and DLL reference for unit testing, with the build configurations tweaked appropriately.
Easy as peas. Now why weren't we doing this all along?
So this has turned out to be a little more controversial than I thought.
Firstly, thanks to @vgaltes for pointing me to this resource that says you can actually mark "friendly" assemblies that can see another assemblies internal features. I didn't know that.
That would be a clean way of achieving the goal of being able to unit test classes and methods without making them public.
Another school of thought is that you shouldn't have tests for internal details, and should only test through public APIs. This theoretically makes internal refactoring easier. Been there, done that, and got the "I Love My Debugger" t-shirt.
In practice, I've found that testing through a public "keyhole" can lead to unit tests that are often far-removed from the code they're testing. And to ease refactoring, I'd prefer better and more focused unit tests that are loosely coupled to the interfaces of the objects they're testing.
That's not to say, of course, that you shouldn't have API tests. I highly recommend them; partly because they're useful for figuring out what your API design needs (a client code perspective), partly because they can serve as a "user manual" for client developers, and partly for testing backwards compatibility by running old tests against new implementations.
Now it may be, of course, that your API is extensive and that many of the classes, interfaces and methods in your project are public anyway.
But the designs I tend to end up with often favour public interfaces implemented by non-public classes. The tests need to get a hold of the implementations.
Of course, you can skin this cat in many different ways, and a lot will depend on your build & config needs, your testing approach and your architecture.
The fact remains, though, that we put source and tests in the same projects in other languages without giving it a second thought. On larger solutions, I often find it cumbersome to have 2x projects for everything. Take a look at this Refactoring Golf solution, for example. Tied myself in knots with that one.
No doubt this debate will continue.
August 21, 2017
Codemanship Code Craft FxCop RulesSo, here they are. Hot from the oven, my FxCop code rules for the upcoming Codemanship Code Craft "Driving Test".
Some rubbish code, yesterday.
If you're signed up to be one of our valiant guinea pigs for the trail driving test on Sept 16th, I heartily recommend you download them and get a bit of practice. Try writing code that breaks each of the 11 rules, and then refactoring that code to make the nasty messages go away.
There's versions for Visual Studio 2013, 2015 and 2017, plus instructions on installing and suing the rules with your own projects.
And even if you're not doing the driving test on Sept 16th, have a go anyway. Your code may not be as clean as you think ;)
Any bugs or false positives, drop me a line.
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.
August 17, 2017
Your House, Your (Code Quality) Rules
Picking up where I left off on the custom FxCop rules for the Codemanship Code Craft "Driving Test" has reminded me of something that's vitally important.
This morning I wrote a class that enumerates a type's collaborators. The code currently looks like this:
Codified in this class is an understanding of what I mean by a "collaborator", for the purposes of the driving test.
First of all, I'm not including non-project types. This is a judgement call to keep design rules realistic. My rule will limit the number of collaborating types to 3. If that includes core library types etc, it's going to be really tough.
I'm including fields, parameters and local variables. I'm also including the declaring types of any bound members. So if I call a method that returns an object and then I call a method on that, it'll be included.
I'm also not counting base classes as collaborators. Again, it's a judgement call.
I'm working alone, so I get to make the rules. But in a team setting that absolutely should not happen. Don't send the "tools dev" away to work in isolation on quality gates for Continuous Inspection. Because what will happen is, when they return and unleash their rules on the rest of the team, there'll be tears before bedtime.
The whole team needs to be involved. This is a great candidate for mob programming, in my experience. While you're waiting for business requirements in the early stages of a project/product, here's what the team could be doing to get the delivery engine up and running.
It will require the team to have discussions about code quality with a level of precision they probably never have before. I think this is a good thing.
August 11, 2017
Update: Code Craft "Driving Test" FxCop Rules
I've been continuing work on a tool to automatically analyse .NET code submitted for the Code Craft "Driving Test".
Despite tying myself in knots for the first week trying to build a whole code analysis and reporting framework - when will I ever learn?! - I'm making good progress with Plan B this week.
Plan B is to go with the Visual Studio code analysis infrastructure (basically, FxCop). It's been more than a decade since I wrote FxCop rules, and it's been an uphill battle wrapping my head around it again (along with all the changes they've made since 2006).
But I now have 8 code quality rules that are kind of sort of working. Some work well. Some need more thought.
1. Methods can't be longer than 10 LOC
2. Methods can't have > 2 branches
3. Identifiers must be <= 20 characters. (Plan is to exempt test fixture/method names. TO-DO.)
4. Classes can't have > 8 methods (so max class size is 80 LOC)
5. Methods can't use more than one feature of another class. (My very basic interpretation of "Feature Envy". Again, TO-DO to improve that. Again, test code may be exempt.)
6. Boolean parameters are not allowed
7. Methods can't have > 3 parameters
8. Methods can't instantiate project types, unless they are factory or builder methods that return an abstract type. (The beginning of my Dependency Inversion "pincer movement". 2 more rules to come preventing invocation of static project methods, and methods that aren't virtual or abstract. Again, factories and builders will be exempt, as well as test code.)
What's been really fun about the last couple of weeks has been eating my own dog food. As each new rule emerges, I've been applying it frequently to my own code. I'm a great believer in the power of Continuous Inspection, and this has been a timely reminder of just how powerful it can be.
After passing every test, and performing every refactoring, I run a code analysis that will eventually systematically check all my code for 15 or so issues. I fix any problems it raises there and then. I don't commit or push code that fails code analysis.
In Continuous Inspection, this is the equivalent of all my tests being green. Of course, as with functional tests, the resulting code quality may only be as good as the code quality tests. And I'm refining them with more and more examples, and applying them to real code to see what designs they encourage. So far, not so shabby.
And for those inevitable occasions when blindly obeying the design rules would make our code worse, the tool will have a mechanism for opting out of a rule. (Probably a custom attribute that you can apply to classes and fields and methods etc, specifying which rule you're breaking and - most importantly - documenting why. Again, a TO-DO.) In the Driving Test, I'm thinking candidates will get 3 such "hall passes".
If you want to see the work so far, and try it out for yourself, the source code's at https://github.com/jasongorman/CodeCraft.FxCop
And I've made a handful more tickets available for the trial Code Craft "Driving Test" for C# developers on Sept 16th. It's free this time, in exchange for your adventerous and forgiving participation in this business experiment :)
August 9, 2017
Clean Code isn't a Programming Luxury. It's a Business NecessityI'm not going to call out the tweeter, to spare their blushes, but today I saw one of those regular tweets denigrating the business value of "clean code".
This is an all-too-common sentiment I see being expressed at all levels in our industry. Clean Code is a luxury. A nice-to-have. It's just prima donna programmers making their code pretty. Etc etc.
Nothing could be further from the truth. Just from direct personal experience, I've seen several major businesses brought to their knees by their inability to adapt and evolve their software.
There was the financial services company who struggled for nearly a year to produce a stable release of the new features their sales people desperately needed.
There was the mobile software giant who was burning $100 million a year just fixing bugs while the competition was racing ahead.
There was the online recruitment behemoth who rewrote their entire platform multiple times from scratch because the cost of changing it became too great. Every. Single. Time.
I see time and time again businesses being held back by delays to software releases. In an information economy - which is what we now find ourselves in (up to our necks) - the ability to change software and systems is a fundamental factor in a business's ability to compete.
Far from being a luxury, Clean Code - code that's easy to change - is a basic necessity. It is to the Information Age what coal was to the Industrial Age.
No FTSE500 CEO these days can hatch a plan to change their business that doesn't involve someone somewhere changing software. And the lack of responsiveness from IT is routinely cited as a major limiting factor on how their business performs.
Code craft is not about making our code pretty. It's about delivering value today without blocking more value tomorrow. It's that simple.
August 6, 2017
What *Exactly* Is "Feature Envy"?I'm currently writing some custom FxCop rules for the trial Codemanship Code Craft "driving test" on Sept 16th. The aim is that not only will I be able to automatically check candidate's code, but they will be able to while they're writing it, too. The power of Continuous Inspection!
One of the rules is that methods of one class must not display Feature Envy for another class. Typically, Feature Envy's defined as:
A method accesses the features of another class more than its own.
And this might seem trivial to check for using a tool like FxCop. Look at all the member bindings inside a method. If there are more bindings to members of other types then to members of the type on which this method's declared, then we've got Feature Envy. To fix it, we can just move the method to the focus of its envy.
But I'm not sure it's quite that simple. This example might be an open-and-shut case:
But how about this?
The majority of feature calls in this method are to methods of the same class. But that code smell we saw in the first example is still here, on lines 3 and 4. Proof? What if we extract those 2 lines into their own method?
The method obviousFeatureEnvy now completely satisfies our definition of Feature Envy and should be moved to the other class.
I think this leads me to a better definition of Feature Envy:
Feature Envy is when any unit of executable code - a method, a block, a statement or an expression - uses features of another class more than features of its own class
Basically, if you can extract any portion of code into a method that displays the original, "classic" definition of Feature Envy.
But wait; there's more. Take a look at this example:
Technically, only one of these methods satisfies our definition of Feature Envy, but if were to inline the call stack, we'd end up with one method with very obvious Feature Envy.
It's much more complex than I thought. But, for the driving test, I'll probably keep it simple and stick with the classic - and much easier - definition of Feature Envy.
But one day, when I've got time...
August 1, 2017
Codemanship Code Craft Driving Test - Trial Run
In my last blog post, I talked about the code quality criteria for our planned "driving test" for code crafters.
If you're interested in taking the test, I'm planning a trial run on Saturday Sept 16th. Initially, it will be just for C# programmers.
Entry is free (this time). You'll need a decent Internet connection, Visual Studio (2013 or later, Community is fine), and a GitHub account. Resharper is highly recommended (you can download a trial version from https://www.jetbrains.com/resharper/download/ - but don't do it now, because it will time out before the trial!) You'll be writing tests with NUnit 2.6.x. You can use whichever .NET mocking framework you desire. No other third-party libraries should be required.
The project we'll set you should take 4-8 hours, and you'll have 24 hours to submit your solution and your screencast link after we begin.
If you've been on Codemanship training courses, the quality criteria should make sense to you, and you'll know what we're looking for in your screencast.
If you haven't, then I recommend twisting the boss's arm and sending them a link to http://www.codemanship.com :)
You can register using the form below.