Is Typemock Isolator Evil - Round N+1

Every few months the argument for and against the advance abilities of the Isolator mocking framework burst again. This time it started with this post: Test driven design – Willed vs. Forced Designs

Disclaimer: I used to work for Typemock company and was in charge for a long time over the development of the framework. so I claim no kind of objectivity .

the argument for and against usually circle around the following:

on one side, people claim that Isolator "breaks" the language barriers and, by allowing any kind of design to be implemented will end up in helping to build a poorly designed system.

on the other side, by allowing the freedom to design at will Isolator shift the responsibility back to the developer allowing him to choose the "best" design as he sees fit.

here are some points I want to comment on:

If you need Isolator you have a bad design

Actually that one is in most cases true. However the following claim "you have bad design" also holds for too many cases as well. Yes I'm saying that most systems out there are poorly designed. I'm also saying that most software project out there will fail. What I don't like about the initial claim is the conclusion that usually follows:

If you need isolator when you have poor design, usage of isolator will end up with a poor design.

That statement is plain wrong, you will end up with poor design unless you learn how to design better. The effect Isolator (or any tool for that matter) will have on a team design skills is minimal at best. Pragmatically speaking if you are are working on a legacy system isolator is probably the better choice no matter what. If you are working on a newly project and you just start out TDD, most likely using isolator will increase the chances you'll be able to stick with it. (adding the need to relearn design at this stage is soo much harder), and if you're working on a new project and you do know how to TDD. Then you should just know better and be able to safely use the tool. If you don't then you really do have a problem.

Isolator breaks the natural barriers of the language

Yes it does, but the statement "Statics are the death of testability" which actually means "don't use static methods" adds barriers to the language which is not there. so what's the better approach? again I don't know. It really depends on your personal preferences and has nothing to do with what is the best design

Actually there's no such thing is the best design. Every design must evolve always to fit the system needs.

Show me a concrete example

example number 1:

many systems have a dependency on the time of day. the naive way to approach that is to use DateTime.Now. but oops that one cant be faked (its a static method) making it a real pain to test. so experienced programmer introduce the ITime interface wrapping the system time with an interface and then adding some concrete code to make it work, all for the sake of testability. here's an example taken from the testify project on how to implement this:

public static class SystemClock {

   private static DateTime? fixedTime;

   public static DateTime Now {
       get {
           if (fixedTime.HasValue)
               return fixedTime.Value;
           return DateTime.Now;
       }
   }

   internal static void Set(DateTime value) {
       fixedTime = value;
   }

   internal static void Reset() {
       fixedTime = null;
   }
}

Please enlighten me as why this is better/simpler as opposed to use of DateTime.Now.

example number 2:

I have a class A depends on Class B. Class B is the ONLY concrete class implementing the interface ISomeInterafce (and most likely this will hold true forever). Class A is the only place (for now and most likely forever) ISomeInterface is used. yes this is a simple example but since I'm inventing it, I get to set the rules.

and there are several ways to approach this:

1. Use some IOC container to instantiate B and send it to A. a valid OO way with many benefits however in my concrete example (and yes I'm the one setting the rules). I don't have a true need for a full pledged IOC yet, and this very simple scenario wont be the one causing me to start using an such a big hammer

2. Use a factory - a simpler version of the IOC container idea, much more light weight. but still at this point of time (and yes I get to make the rules) under the specified circumstance it falls under the YAGNI directive. If the situation changes (i.e. more places will use ISomeInterafce or more "kinds" of ISomeInterafce will evolve) a factory will be used but for now I don't really need that.

3. Instantiate B somewhere and pass it into A (the simplest form of DI) - a very simple solution which is valid under this scenario. the down side for it are , that it exposes some inner working details of A which may not be a good idea AND most likely it only shifts the problem to someplace else.

4. Just use a new statement somewhere inside A (lets say constructor) - I like this way. Its the simplest thing that can possibly work, and I'm not tied to the "design for testability" chains, so I can do that. and just before I get chopped, yes taken outside this context of this simple concrete example is most likely not a good strategy.

I want to make the Choices. I'm the professional trained to do them. I wont stand being TOLD how to do my job, not by a person, and especially not by a tool.

Read more »

Posted in: Design,Engineering Practices,Scrum. Random Thoughts,tools,Typemock

Opening talk – Alistair Cockburn

The opening talk title was “Effective software development in the 21st century”. As promised by the title this session was packed with so many great insights, advices and ideas for me to be able to repeat them all. But some stuff did stick and I thought i should share.

Agile has grown beyond small organizations

Yes, this simple fact still comes as a surprise for people outside agile circles. However one must remember that originally Agile methodologies (mainly XP and Scrum) were created for such teams. A fact that some Agilists tend to forget. What is important that current methodologies, as used today, have grown, changed and adopted to all kind of projects and they are still growing. For example the trend in which more engineering practices are picked by organization doing Scrum might soon force the powers to be to finally include some of them in the “book of Scrum”. Yes who knows what the future of Scrum might be.

Software development as a cooperative game

A great metaphor the full details can be found here. In short, when looking at development as such a game we can say that:

1. Writing code can be viewed as a finite cooperative game with set targets, goals and an end.
2. Developing a product can be viewed as an infinite game in which the only true goal is to actually play the game hopefully as long as possible.
3. The process that we choose is the actual “Strategy” by which we choose to play the game.

so where that leaves us?

With two (actually more) important observations. First, like any other complex game you don’t find yourself in the same state twice,and a single winning strategy does not exists. In fact, when talking about strategies, the terms right or wrong does not apply, strategies are either weak or strong. What’s more important is that one can and should pick different strategies for different situation. A process which works for a startup company probably wont work as well for a big team. Second, the different in nature between writing code and developing a product might explain a very basic developing dilemma. On one end we want to ‘win’ the game of writing code, which has specific goals and a known end date. On the other side we must remember that from a product POV the game is infinite (hopefully) and we always want to be prepared fro the next “round’. Meaning that its not enough to write working software satisfying current needs. The quality of the written code must be kept good enough to support future development. And those two needs sometimes pull us in different directions

Developing Software is a Craft

its not the first time i hear this, there’s an ongoing growing movement of developers calling all to start treating writing software as a “profession”. Alistair however summed it up quite well

“A developer must relearn how to program every few years”

and indeed software development techniques are continuously changing. When I started out my first programming job involved writing code in C/functional C++ for an embedded system. A couple of years later I had to relearn how to program when i switched to develop using object oriented C++. A few year passed and I was introduce to Agile, which came with practices like TDD, pair programming. So again I had to relearn the skills of writing software, and last a couple of years ago, I started to developing under .NET which again made me relearn much of my skills. Bottom line I feel all these relearning is the only way to keep up with the profession of writing software.

Decisions as unit of inventory

The last part of the session discussed the idea that actually software development is mostly about making decisions, and that the speed by which we transfer those ideas between minds is what actually dictates the productivity of a development team. The best way to speed up development is by locating and removing all barriers which slows down this flow of ideas. For example the reason why distributed team are less efficient than collocated teams are that they communicate using inferior channels which of course reduce the efficiency in which we can transfer ideas.

The nice thing about using this analogy, is that the entire development cycle can now be reduced to a manufacturing line and all the appropriate theoretical knowledge can now be drawn upon. Specifically by using decisions as unit of inventory we can now map the stations along the development “line” and try to locate bottlenecks by recognizing the places in which decision are being delayed.

Summary

There was much more going in the session, in fact I’m sure that in order to grock it all ill need to listen to it at least a few more times. I do hope however that I managed to convey at least some of that knowledge.

Next post ScrumBan (how to use Kanban in Scrum)

Read more »

Posted in: Events,Scrum. Random Thoughts