Short: An example of learning as the result of rotating; using techniques learnt from working with testability in new (TDD/BDD) development.

On the microlevel, we learn from inspecting the code we are creating. On the macro- or project level, we learn skills in one type of project that we can use in a project of another type. Essentially, the difference between legacy and greenfield. Working with many legacy projects, we can see the results of our mistakes, and we can see how we can work around them.

This turbocharges our learning, since the issues are magnified.

I've experienced a useful example are TDD/BDD techniques. BDD gives us insight into our software designs, it illuminates values of our designs that are very hard to find otherwise.

I think it was Pete McBreen (or maybe Alistair Cockburn) that drew the parallell to how many martial arts methods are taught, usually in several levels - the masters have apprentices that teach the novices. The novices magnify the mistakes of the apprentices. The mistakes become easy to see, the feedback is clear.

 We get this magnification when we look at code a little further on the timeline, when it has been in production for a while. The problems caused by any design decisions we made when developing make it easier to see how design affects maintainability.

For most of 2006 I have been working with projects where the challenge was in making the code testable and then adding tests. I have discovered that when I return to new development projects, many of the techniques I learned while working with existing code have helped my understanding of the BDD issues.

So for this example, if you haven't done any "refactoring old code" project, and haven't read the WELC book - I recommend doing it. There are many things you will learn from it, testability techniques not the least.

Rotation is good, both in the small and in the large.

Testability has been (for 30 years=forever in software development terms) and always will be a large factor in measuring quality in software. Bad testability = bad design. Functional requirements are definitely not the end of story on software quality (for a deeper discussion, google for software quality, McCall, Boehm, ISO 9126, etc).

 

That seemingly simple relationship is hard earned knowledge, especially among application developers. Countless comments and thoughts are a testament to that fact.

 

However, testability is not defined by if and how you use a mocking framework, or other tools. Since testability is slowly gaining more and more exposure, the way it is being exposed seems to confuse.

 

It is in the nature of many computer enthusiasts to reduce skills and knowledge to tools in the form of software.

 

Need a great picture? Easy, get photoshop. Need a better personal economy? Quicken is the answer. Want to compose music? Cubase & Co will turn you into Mozart. Right? 

 

And of course, if you need to improve quality via TDD - just get xUnit, a mock framework and you'll be a test development wizard in no time! Right?

 

Well, no. Neither testing nor BDD/TDD is not about using rhinomocks ("sorry" Ayende), just as creating music is not about Cubase ("sorry" Steinberg). Testability certainly has been around longer than NUnit...

 

In contrast, design issues such as coupling and other forms of bad dependencies are inherently bad things for testability (herr Jungmayrs dissertation puts it forward in a great way). Even more so, it is bad for software quality in general, not just testability. Again, it is something that we have "known" for decades. Even object orientation has little to do with it. Testability in the mainstream goes even further back than OO in the mainstream ("sorry" Bjarne). It has nothing to do with things like "OO purity".

 

Still, developers like shortcuts and some will fight these things every step of the way.

 

I think that the additional knowledge and competence required can be daunting, and that is why "highly OO" designs often are as bad and complex as "spaghetti code". Admittedly, even a well designed application can be hard to understand.

 

I am sorry to have to break it to some people, but whoever told you developing software would be easy, wasn't really being honest with you.

 

Seriously, "complex OO designs" are not necessary, nor required to support any xUnit framework. In some instances, you don't even have access to a framework - be it xUnit or any mock - and you just (lo and behold!) write tests as a normal app, to test your code. Which works. That means we're still not off the hook! Shucks! You still must provide decent testability and low coupling, in order to create unit tests, even though you're not using xUnit or any testing tool at all. Shoot!

 

On the use of Typemock, Lenny is right in that it is a wonderful tool for addressing the testing needs of legacy code, and that you naturally wouldn't create unit tests for a large existing codebase. NUnit provides a great testrunner. Neither requires testability to use. Neither guides us when creating code.

 

What I feel is very wrong, however, is using the capabilities provided by Typemock as an excuse to create bad quality, highly coupled and unmaintainable code. When you are starting anew, seize the opportunity! Do it right! If you've worked with getting quality up in existing code, introducing unit tests, and so on - you will appreciate the opportunity. If not, you need to rotate so that you do.

 

Typemock is a great tool and gives you alot of power. I think one should consider disallowing it in new projects, atleast until people start to get the mechanics of testing.

 

What are the downsides of Typemock? Oh, where to begin... To be continued... (picture "How the west was won" text on a grim James Arness face)

Short: If we do not inspect our code we do not learn from our mistakes. Improving at anything in life depends on to what extent and how we reflect on what we are doing it, and how we are doing it.

Development activities are full of switches between development and maintenance, between creation and modification. (This is something very positive, and something we in software development can enjoy without many of the costs present in other development disciplines.)

 

At the micro- or coding level, the software development activity consists of constantly switching between two modes and mindsets: Developing new code and maintaining the developed code.

 

Broadly speaking, developing new code is the creative activity where you run many ideas through your brain, quickly invalidating and validating them, finally arriving at a solution choice. After choosing the solution, you create a model of it (using the tool of your choice, usually a high level programming language, as far as developers are concerned). At this point, we are prototyping and molding the solution, learning at each step of the way. We are in the create mindset.

 

After a chunk of a solution has been created, you instantly turn into "maintaining mode" - where you critically inspect it, change it and redo some parts.

 

I view this as maintaining since we are focused on issues other than fulfilling the basic functional requirements, namely maintenance. At the simple end of things, we may just look at the code quickly to revise variables. Getting a little bit more involved, we may look after refactorings within the class we just created. On the more thorough end, we may also scrutinize the broader design, looking for ways to make it clearer and cleaner. All of these tasks, whether large or small, address the maintainability aspect of the code. We are in the "maintenance" mindset.

 

All of these tasks obviously depend on the switch. Of course, there has to be code to inspect, but beyond that there is learning going on during development, that is necessary in order to inspect fruitfully.

 

Switching mindset the other way is even more important, I think. While inspecting our code in the maintenance mindset, we come to look at the design differently and learn from it. The next time we create our solution, we benefit from what we have learned.

 

So simple I almost don't know why I wrote it. Yet, somehow some developers seem intent on only developing. Or maintaining. Or testing. Doing a  little bit of each is better.

I've been educating and coaching a fair share of projects in TDD and agile practices now, and in one there was a developer that decided against the harsh discipline of TDD/BDD and agile. The reason was his love for coding away at a solution, going as far with it as he could envision (which he was very good at btw).

The principle of YAGNI has to do with focusing on current needs and satisfying only them, as prioritized by the customer and/or as is evident from the backlog (xp and scrum). It's related to the well known issue of design partitioning.

On this project, we used the term or token "golden future" to claim that we were reasoning about issues that were far from where the project was. Another term that made an entrance was "deep" coding. This is used in many places to mean locking yourself up and focusing on a problem, usually also a problem that requires the dev to go deep into the underlying technology to find a solution.

Here we meant something similar, but referred to the solution space (rather than the technology/system space): To code "deep" was to take a task / user story and develop it as far as the dev could at that point in time. A spike, if you will.

My point here is that the term has a positive ring to it, in the ears of the engineer/developer. To go deep and solve something hard requires skill and means that you are doing hard and complex work.

We would probably have been better off to choose the term to code "far" or code "away". Coding far means to wander off in one direction, hoping that it is the right one. It means to never check the map or the compass until you are feel "done" and have exhausted your vision knowledge. By then you are far out in the forest, all alone.

Are you close to your destination? Or did you just spend alot of time wandering?

At the rails workshop yesterday, we got into a code readability discussion (one of programming "holy wars", i e endless debates). One thing that remains subjective is the use of comments. Since compiler optimizations give us great flexibility in how we code, I refactor intensely towards readability: Extracting helper methods, logic tests, etc - all in order to make the code almost as readable as normal english.

My take is that comments are almost a last resort, something you do when there is information that the reader needs, that the code cannot convey in a smooth manner. Essentially, I focus on making the code speak for itself, as much as I can.

Here are some articles that I liked, and a couple on c2 that are nice.

Comments are for communicating to other developers what the code does. The compiler eats simple text, yet other humans are often well served by images, and colors - hence we get color coding in our editors. Why hasn't this gotten further? I envision colorizing and straight out drawing beside the code, to augment it:

Drawing lines instead of making them with equal signs.

Custom color coding, where types can be assigned colors (I think layers) and use would show up easily as a background color, or the like.

Today, we create regions around code and insert a comment for them, why not pick a color as well? We will even more easily remember and browse the code.

Of course, I often create ad-hoc diagrams. Some I like to keep. These are for coders only - why not keep them with the code? Small diagrams, sitting right there in a comment. If word can do it, so can any modern editor, right?

Lutz Roeder (author of the .NET Reflector tool) had some thoughts in this direction, apparent from the presentations you can check on his page here.

I will be speaking at the Øredev conference in November. The conference is in Malmö and is probably the largest software developement conference in Sweden geared at professional software developers.

The session topic is modifying existing code in a reliable way by using tests to verify your work. If you are anxious about doing such work and/or are facing such work in the near future, come and get some practical ideas for how to proceed.

On the other hand, if you have already started doing such work, come along and share your experiences and tips! I (and presumably many others) will be most interested in hearing them!

The lineup at Øredev is pretty awesome this year, so if you are in the area, you really should clear out those three days in your calendar and listen in on great software development guys such as Martin Fowler, Jim Coplien, Don Syme, and a whole host of others!

A little on the level and prerequisites for my session: The topic is pretty advanced, so a fair chunk of development experience is best in order to understand the issues and solutions presented. The code will be .NET C#, and some specifics for .NET will be discussed, but the general strategies and ideas are applicable to most OO environments. My idea is not to cover TDD and/or basic testing mechanics, so an understanding of writing tests is strongly recommended. One excellent way of getting such knowledge is to attend the TDD workshop held by Martin Fowler and Erik Doernenburg on the workshop day (the day before the session).

In case you've missed it and live in the Copenhagen-Malmö area, there is a free Ruby On Rails workshop in Malmö on Sunday arranged by the cool company polarrose. Speaker is guru and rails book author David Black. Check the polarrose site for info and registration.