Coding forward: the opposite of coding backward

I am a big advocate of coding forward.  Coding forward is the style of coding used in Test-driven development.  In TDD, we write a test as we would like the code to work.  We even allow compile errors because we are modeling the API of the code the way we would like it to read – even before it exists.  Then, we begin to fill in the holes, creating the methods that didn’t exist yet, and making them work right.

I like to carry that into all coding, not just test-first coding.  For instance, if I am in an MVC controller and I need to call a new method that I am imagining in my head, I like to just write the call to that method that doesn’t yet exist.  For instance:


Here, I know I need to make my domain model to a strongly-typed view model for use in an MVC view.  The method to do it doesn’t exist. 

A common style is to stop coding and then go create the mapping method and then come back.  I find this to be cognitively disjointed and prone to the loss of train of thought.  When I stop coding and jump down into the stack of methods & classes that need to exists for a top-level solution to work, I have to make sure I keep track of my own “call stack” or development stack of items to come back to.  If, instead, I continue coding forward to the end of the scenario, the compiler will remind me of the missing pieces because it won’t compile – or the page/function won’t run.  Automated tests do this also because the test won’t pass until all necessary code is in place.

I have noticed myself doing this, and I realized that it was distinctly a different style than many programmers.  JetBrains ReSharper does help tremendously with this style because of the navigation features and code generation features.  I’m not sure it would be as convenient without R#.  Creating a new class and then flicking it to a new code file is just a couple of shortcut keys with R#, so it’s pretty frictionless to code forward.

Happy coding (forward)


Coding forward ???? ?????????? coding backward ???? TDD Posted on 5.15.2014 at 6:26 PM

Pingback from Coding forward ???? ?????????? coding backward ???? TDD


Gregory A. Beamer said on 5.13.2014 at 9:35 AM

Jeffrey, most .NET programmers (probably Java too) think procedural: Break a problem down into steps (start with line 1 of the report, then line 2) rather than objects (the entire report has a header and a footer, with individual encapsulated lines), so it is no surprise they try to think about completing dependencies (next step) rather than focusing on the problem.

I think the code forward style works great, but would add to this post that when you have resharper create a new method on a new class, immediately extract an interface to create a contract. You then increase the testability of the solution.

Cory House said on 5.13.2014 at 10:22 AM

Great post Jeffrey. I really like the term code forward. I find myself doing the same but didn't have a term for it. I've thought of it as "write the call I wish I had". I enjoy the way I coding forward allows me to stay in flow by initially ignoring lower level details. It helps focus the initial code on API design rather than implementation details.

Peter Ritchie said on 5.13.2014 at 10:50 AM

Gregory, are you increasing the testability or are you simply maintaining a single type of coupling that may or may not be the best coupling for every circumstance? Would it not be better to have automated testing without mocking, where you can? I'd prefer people *think* before arbitrarily inflicting accidental complexity on a project. I think that's really part the purpose of TDD.

Chuck Conway said on 5.13.2014 at 11:36 AM


I hear what you are saying. I often do something similar. I’ll create a method that I need. If it’s too much at the moment to implement I’ll stub it out and have test data returned.

Where you and I part ways is if a method needs to be implemented, I’ll change gears and implemented it. The reason is if I stay on track and complete my current code, I cannot test it and it will not compile, until I implement the missing method(s). I think of this as work-in-progress so the more work-in-progress (untested) code that I have, the more code I have where bugs and design flaws can hide.

Brian Brewder said on 5.14.2014 at 9:09 PM

Visual Studio provides this feature out-of-the-box. Just type the method you want and when you want to create it, press Ctrl+. (dot) then Enter. I've used this technique for years. I tend not to create classes this way (due to organization issues), but I believe vanilla VS can do that as well.