Overcoming Code Paralysis…

Don’t take it sitting down…

Have you ever sat at the keyboard (or stood if you have one of those new fangled standy-up workstations) and not known where to begin on a new piece of code?

You know what you need to achieve, you know what the code has to do, you know how to code it, but the problem is where do you start?

What classes do you need? What should they be named? What folder should you put them in? What dependencies do they have? Etc… etc…

In the old days (before things like SOLID and TDD) it was straight forward. You would just place your cursor inside Main() and start coding. If Main() grew to more than a few hundred lines long you’d split some of the code out into functions, and resume typing.

Ok, that is a gross over-simplification and generally a lot more craftsmanship went into the proceedings than that. But the idea is the same, we didn’t fear knowing where to start, because it was OK to just start anywhere and crack on with it.

Through complexity comes slightly less complexity…

Now, with SOLID principles, every decision you make is governed by the fear of violating one of them. Am I breaking the Single Responsibility Principle? I really mustn’t new up a class within another class, I need to inject it as a dependency… Are my interfaces getting to big? Are my methods so well named that another coder could understand the intent of my code without requiring comments? Under TDD I need to start off with a failing test and I don’t even know what to name my first class, or what it should be responsible for…

The point is, paradigms like TDD and SOLID are awesome. They are the way to go (most of the time and depending on what you write). But they introduce an additional level of complexity (call it intellectual manageability if you like) that can very quickly induce code paralysis. You end up with so many rules governing how you should create your code that it can become difficult knowing where to start. And starting in Main() is generally not that place.

Q: So what can you do if you hit code paralysis?

A: Put your cursor on the screen and start typing.

It’s really that simple. Don’t just sit (stand) there, code something.

OK, I don’t know what my first class is even going to be called, how am I supposed to write a failing test for a class whose name I don’t yet know?

Don’t worry about it, you can get some code on the go and worry about all that later. Have a look at the following:

Assuming you’re using C# and MSTestV2, but the principles apply to any language and test suite…

Create a new file (anywhere in your project) and call it FooTests.cs

Create the FooTests test class in FooTests.cs.

Create your first test:

There you go, you have your first unit test written, and it will fail. The class Foo() does not exist so the test won’t compile, which is the same as a failing test.

So next you create the class Foo (do this in FooTests.cs – don’t worry about what the class will ultimately be named, or what file it should be in just yet). Remember, we’re just sketching at this point.

PS. In Visual Studio you just need to put the cursor on Foo and press Ctrl+. and select Create Type Foo to have the new class automatically created for you.

Your first unit test should now pass.

Time for the second test.

But what to test for, this is going to be a complex system with many moving parts…

Again, don’t get yourself bogged down with the details just yet. We need to chuck some clay on the wheel before we can make a beautiful vase.

We know our class needs to do something.

Write another test:

There you go, another failing test.

The test fails because the method DoSomething() doesn’t exist yet.

Put the cursor in DoSomething() and press Ctrl+. then select Create method ‘Foo.DoSomething’. This will add the missing method to your Foo class.

Your second test won’t pass because the auto-code completion adds code to throw a NotImplementedException. Whether this exception gets added to your code depends on your IDE settings. For now comment out the throw new NotImplementedException(); exception if one has been created and you’ve got another passing test.

Ok, we’ve got two passing tests. They don’t achieve a great deal in terms of functionality, but what they have achieved is to get us typing code.

You now have some clay on the wheel, a basic sketch on which you can build, and from here you can carry on with the red-green-re-factor approach of TDD as you continue to flesh out some structure and then move on to adding details.

As for the names Foo() and DoSomething(). Refactoring tools in modern IDEs are so good these days that you can easily rename these as you develop and re-factor the code.

When words fail you…

There are plenty of times when I find myself being bogged down with trying to think up a good name for a class or variable. When this happens it will either be because I am tired, or my code is heading in the wrong direction and the naming difficulty is a code smell that I might need to re-think part of the design.

In either case, don’t worry about it.

I just name the class BarrysFishAndChipShop, carry on developing the code, and before too long a better name for the class will present itself. In the case of BarrysFishAndChipShop a better class name will spring to mind quite quickly. But the point is it doesn’t matter what you call a class during the rapid development phase.

Remember that red-green-refactor cycles will usually be under a minute and often only a few seconds. I’m not talking about checking funny class names into source control for others to work on, remember that you are just sketching ideas at this phase and often after a bit of re-factoring the names of things will become very obvious.

The whole point is to snap your self out of code paralysis, and do something. Anything. Even BarrysFishAndChipShop.OrderMushyPeas() if you have to.