CPPing in .NET

I've talked about the trend of developers to use ready made solutions.

The idea is simple enough. There is no need to reinvent the wheel. Almost every problem a developer encounters, someone else has already coded a solution.

When taken to the extreme, we end with a development technique which can be termed "Copy Paste Programming" (CPP in short).

Like anything in life there's a risk involved in this. In many cases code produced using this technique is less understood then code developed from scratch. And in most cases (I have seen) the ready made solution solves a slightly different problem then the one it is applied to. Which at the end leaves us with a piece of code that almost works but we don't know why.

Its not that I'm against using other people code. In many cases its the most effective and fastest to get the job done. However when doing so, I take the time to carefully understand the piece of code I'm CPPing into my .NET application.

Read more »

Posted in: Random Thoughts,Terminology,tips

Capability of a Developer

Sometimes in life you join a discussion expecting the least, but surprisingly enough profound wisdom can be found in the least expected places.

In a five minutes talk I heard a very wise man give a very good analysis of what is capability.

It translate to something like this:

Capability of a person is a combination of two elements

1. The "body", which dictates the true ability/talent of the person.
2. The "spirit", which dictates the will of the person.

Taken to our domain, a developer capability will be a combination of the his technical knowledge(talent) and his motivation (will). When I want to increase a developer capabilities, I can either try to help him increase his technical know how, or try to help him on his motivation side. For best effect I try them both.

Some coaches I have encountered are making the mistake to assume that will on its own is enough (did someone mentioned "The Secret"?). I'm sorry, but no matter how much I shall "will" it, I CANT write code with absolutely no bugs. Maybe its because they lack the capability to increase true ability in a person?

Read more »

Posted in: Coaches,Random Thoughts,Self Improvment

Outlook 2007 Hanging

Yesterday, I got into a battle with my outlook (2007). It all started after I received meeting invitation from a friend.

Harmless enough isnt it? WRONG!!!

When I first tried opening it, my outlook just froze on me. Being used to software crashes,  I terminated the program like I do every time. However for some reason, that stubborn message kept on freezing the outlook each time I tried to open it, and if that's not enough trying to delete it also made outlook freeze.

It took me a couple of hours to try various things, but every operation that I tried on that message froze up outlook. I got so desperate so I even tried looking on the net for PST manipulation tools, that will enable me to hack in and make the message go away. (BTW I didn't find any)

At the end however, I got lucky. From all things marking the message as junk got it moved to the junk folder and from there I could delete it once and for all.

So if you have outlook freeze on a specific message each time you try to open it and you cant delete it either, try marking it as junk first.

That's what I call annoying!

Read more »

Posted in: bugs,outlook,tips,tools

Documentation in an Agile Process

One of the more common misconception about agile is to think that it means no documentation. In the original Agile manifesto we can find that we value:

Working software over comprehensive documentation

For some reason people mistook this to mean that documentation has no place in an Agile process.

In my opinion this is very far from the truth. What I do agree is that the commonly form for documentation i.e. text files, that most people mean when they say documentation, is probably not the best way to get the job done.

Why do we write documents?

I recently had a nice discussion with Eyal Katz about the need for documents. Eyal listed the following three reasons:

1. To make the writer really think about what he is writing about. For example by writing a design document the designer is forced to think and formalize his design properly.
2. Documents can later on serve as a mean for sharing knowledge.
3. To store knowledge (so we wont forget)

Are documents cost effective?

well in my opinion the answer is clearly no (in most cases):

I myself think better against a white board. For me sitting against a computer screen is just not flexible enough. When I do a design session using a white board, I usually complete in an hour what can then takes me 3-4 days to write down. So clearly, for me, writing a text file is not the most efficient way to think and I'm sure other people have even better ways.

But how can other people read/understand what I sketched on the white board? Well they cant. But generally it doesn't take me more then a 20-30 minutes to explain it. So instead of spending 3-4 days writing it down, I can personally teach it (and trust me its much more effective that way) to 60-80 peoples in a 1 on sessions. So how many people are really reading most of the documents we write?

but what will happen in a year from now if I don't write it down? Well, the real problem is that without maintenance documents gets outdated. Wherever I go, I see that knowledge stored in text files is almost always either partial, old or just plain wrong. For some reason software companies don't do a good enough job in making sure that their text files reflect reality.

No documentation in an Agile process?

on the contrary  a lot of documentation, just not a lot of the regular kind (i.e. text files). Some examples:

• Product & Iteration backlogs serves as a good place to specify requirements.
• Unit tests serves as good low level design documents
• Burn down charts serves as great progress reports.

When taking into account all forms of documentation an agile project will usually have a lot more documentation then seems at first sight and in most cases that documentation will be more accurate and effective.

Uninstall Word?

All this does not mean that good old text file don't have their place. Just to say that from my experience they are widely misused. Knowledge stored on paper (or in files) is far less important then knowledge stored where it counts in people heads. A true Agile project will first make sure that it gets to there before it goes into a text file, and not vice versa.

Read more »

Posted in: Agile practices.,Documentation,Random Thoughts

Cost of Change – The Fear Factor

Oren has blogged on how to reduce the cost of change. He claims and I agree that

Beyond anything else, it is the will of the team to accept the pain of making the change and actually doing this

When accepting this mind set its usually a lot easier to find ways of reduce the change cost . i.e. make it easier to change.

However I feel there’s another factor in equation, and that is the developer’s inherent fear of the unknown. Time and time again I’ve seen (and did that myself) programmers start implementing a change by attacking its easier parts first, leaving the real hard unknown issues to the end.

When adding a new functionality to an existing system for example, there are two main steps:

1. Implementing the new functionality.
2. Integrating it into the given system.

In most cases the harder part will be the second part, however 90% of the times a programmer natural instinct would be to start out with coding the new functionality.

As far as I could tell, the reason is that in most cases the new functionality is kind of a well defined problem, while the effect of the integration part is a big unknown, and most people will shy away from uncertainties leaving it to the end. and if we add to this the general “embedded”dislike of changing existing code (if it works don’t fix it) and we get the natural tendency to start with the well understood isolated new piece of code.

The problem is that in most cases the hard parts are, well, hard. They are the parts that will lead to the real problems which will take time to solve. Starting out with the easier parts of a problem leads to a false sense of progress which later on may bite when facing the real difficulties in the implementation.

Here's an example of such  a thing happening, in this case we have worked on a feature for quite some time, but were only able to complete it after starting all over again by attacking the hard integration issues first.

So don’t make the natural Mistake of letting fear of the unknown take over. Accept the fact that the hard problems are there and must be solved. and start by solving them first. When that’s done the easier parts will easily fall into place.

Read more »

Posted in: Development Practices,Random Thoughts

Test Types – Are we confused yet?

Recently I’ve encountered several places which discussed the different type of tests. Here are some terms I’ve seen:

1) Unit tests – the most widely used term, which still I’m afraid is open to interpretation. Up until now I haven't seen a good definition of what is a “unit”. Is it a single class? Is it a single component? where lies the line between different units?

2) Integration tests – again kind of vague, but mostly it means a test which encompass several “units” sometime the entire system.

3) Developer tests – this is a more broader term which means test written by developers. I myself don’t see much value in using it since it doesn’t give any indication to the tests nature . (also what are none developer tests? how to refer to manual tests done by developers? how to refer to UAT written by a developer? )

4) Manual/Automated tests - Distinguish how the test are executed.

5) User Acceptance tests(UAT) (also referred to as Verification tests) - tests whose main goal is to “convince” the user that the system behaves as it should.

Are we confused yet? here’s a little something I found on the net.

The point is, that such a wide terminology, tend to lead to much confusion and misunderstanding. Before starting any sort of discussion, my advice would be to make sure that the all parties share the same meaning and terminology. I’ve spend too much time argueing only to find that the person I was arguing with just used a different meaning than myself.

Read more »

Posted in: AUT,Integration Tests,Terminology,Unit Tests

The Future of Unit testing

I’ve recently watched the PDC 2008 panel Session on the future of unit testing. The feeling I took from this session is that Automated testing is here to stay.

What gave me the indication that this is true is the fact that although the panel tried to focus on unit level testing, the audience tended to shift the discussion into other zones.Most of the audience questions were dealing with more complex scenarios, going beyond the unit level, that they encounter in real life.

For me this gives a good indication that automated unit testing has taken its hold. I’m not sure if my interpretation is not Mistaken, but it seems to me that the available tooling solutions for writing unit tests has matured enough (yes even if you don’t like using mock frameworks) to the point where people are now trying to  leverage them into other testing areas.

As the panel mostly agreed, there is still a shortage of good tools for doing integration/User acceptance testing, and if one listened closely enough it looks like at least some progress is being made on those areas.

Another fact, that most of the of the panel agreed upon, is that unit testing is not enough, at then end there’s still a gap between the user requirements level and the unit level that must be bridged by other sort of testing (integration tests/UAT).

If you want to get some more info on the session but don’t have the time to watch it fully try reading this post by Eli or this one by Andrew

Read more »

Posted in: AUT,Integration Tests,PDC,UAT

How to know which unit test calls a specific method

From time to time one faces the situation that one of the unit tests written fails inconsistently. The usual scenario is that when run alone the test passes, but when run as part of the entre suite the test blows up.

In a lot of cases this results from some left over from previous tests. Here is an example of such a case (taken from Typemock-Isolator support forums - AAA tests pass individually, fail in suite). The reported error in this case indicates that for a mock setup in a given test was accessed in some other test which kind of confused the given test.

Solving such an issue usually involves a lengthy Search&Destroy in which most of the work involves finding out which of the test is the one which is interfering with the given test.

So here’s some code that should save most of the leg work. I’m using one of the more powerful features of the Isolator framework – Custom Decorator, which allows adding interception points before and after a given method call.

Here’s the code:

public class TraceTestAttribute : DecoratorAttribute
{
  //I'm using a dictionary of lists to store for
 //each method all the tests in which the code
 //was called
  static IDictionary<MethodBase,List<String>> _TestNames
  = new Dictionary<MethodBase, List<string>>();

  public static string GetData()
 {
     StringBuilder output = new StringBuilder();
     foreach(KeyValuePair<MethodBase,List<string>> entry in _TestNames)
   {
     output.Append(entry.Key.Name + ": ");
     foreach (string testName in entry.Value)
     {
       output.Append(testName + " ");
     }
     output.Append(Environment.NewLine);
   }
     return output.ToString();
 }

  //this is where all the works get done
  public override object Execute()
 {
    List<string> data;
    if (!_TestNames.TryGetValue(OriginalMethod,out data) )
  {
    data = new List<string>();
    _TestNames[OriginalMethod] = data;
  }
  data.Add(GetTestName());
    return null;
}

  //going over the stack to locate the test name
 //we use reflection to find the method decorated
 //with some sort of [Test*]
  private string GetTestName()
 {
     StackTrace trace = new StackTrace();
     foreach (StackFrame frame in trace.GetFrames())
   {
     foreach(object attribute in frame.GetMethod().GetCustomAttributes(false))
     {
       if (attribute.GetType().Name.StartsWith("Test"))
       {
         return frame.GetMethod().Name;
       }
     }
   }
     return "not from test";
}

  //this instructs the framework to apply
//the attibute ALL methods (and not just tests)
  protected override bool DecorateMethodWhenAttributeIsClass(MethodBase methodBase)
{
    return true;
}
}

As you can see this is quite trivial, when applied to a given method at time the method get calls the attribute Execute method is invoked before the call. In that call I’m going over the stack searching for the test method in which we are running and storing it in a big dictionary keyed by the method we are tracking.

At the end this gives me the ability to stop the execution at each point and easily see the table of all the tests that during their execution a specific method was called (directly or indirectly).

(For good measure I’ve added a GetData method which build a string of the entire dictionary)

I hope you find this one useful, leave a comment if you do or if you have related question.

A warning: currently the isolator contains a defect that will cause an exception to be thrown when the method with this attribute is mocked. I’m sure that this problem will be fixed very shortly by the Isolator team.

Read more »

Posted in: Isolator,tips,tools,Unit Tests

The Fifth Value – Respect

There’s a lot to be said about respect but for some reason this value is not stressed enough. I think that much of what troubling the software development world today can be traced back to this value. Lets face it most developers are arrogant bastards(and yes I’m a developer too).

Taken from Kent book:

Every person whose life is touched by software development has equal value as a human being. No one is intrinsically worth more than anyone else. For software development to simultaneously improve in humanity and productivity, the contributions of each person on the team need to be respected. I am important and so are you.

lets take a few examples I’ve encountered (ok, ok I’ve said those):

• “our customers does not know what they want. Ill tell you what they want”
• “our test team don’t have a clue on what they are doing and how to test the system”
• “I don’t trust our system deployment team to properly configure the system in at the customer site”

and the list goes on.

The problem is that this kind of attitude, even if its backed up with real hard facts, leads to a basic lack of respect, and this will effect the project outcome.

I try to treat everyone the same (with partial success I admit), when facing incompetency, I first try to see if this can be fixed (in many cases what looks like incompetency is a result of a simple lack of knowledge) and if it cant, I will look for a replacement. Most project I’ve worked on don’t have the luxury with the less capable.

Read more »

Posted in: Agile practices.,Random Thoughts

The Funny side of Metrics

From time to time I do stumble upon some great post. The following post (yes its an old one):

Is it Wise To Aim for 100% NTF?

did not only made me laugh it really made me think.

Lesson learnt – Using humor to mask Wisdom is really effective.

Read more »

Posted in: Metrics,Random Thoughts

The power of combining Unit tests with Integration Tests (conclusion)

Here and Here I explained why I think that unit tests alone or integration tests alone does not do a good enough job at assuring the quality of the product. However, that combining the two test  levels, i.e. investing some of the effort in integration tests and in unit tests is what I call a winning solution.

Investing effort on both levels allow one to benefit from both worlds

on one side integration test will help in:

• formulizing the user requirements.
• make sure that system is working end to end.
• test non functional requirements

on the other side unit tests will help in:

• driving the design of the system to a better one.
• give a good coverage of all parts of the system
• eliminating defects that get shipped with the system.

I have been suing this approach in a TDD style in which the development process of a new feature(user story) started out by writing a few (failing) integration tests then followed by writing some more (failing) unit tests and only then starting to implement. this kind of process has worked for us.

The million dollar question is of course “how much do invest at each level?”, and the real answer is I don’t know. I think that it really depends on the specifics of the project and the system under test. In some cases it makes more sense to invest more time on the unit level while in other its better to spend more effort on the integration level. I really think that the best guide to that will be to use common sense and see how things works out.

Read more »

Posted in: Agile practices.,Integration Tests,TDD,UAT,Unit Tests