You’re lucky you know, said the developer to the consultant. You get to come and save the day and leave before all hell breaks loose.

You got it all wrong said the consultant to the developer. I solve problems, teach best practices and explain what should be done and then they change and twist everything I said and done 5 seconds after I’m gone.

 

I wanted to share part of a conversation I had with a consultant I know.

Today I attended a meeting of the Software Craftsmanship in Israel group with Corey Haines.

Corey gave a talk about agile practices and how to decide which to choose.

The talk went something like this:

Our objective is to reduce the time between doing something and doing the right thing and the time between doing one thing and starting the next one. And thus the goal of every single methodology is to make the feedback loop smaller – at all levels.

The main reason we want to reduce the feedback loop and provide value as soon as possible is that we want to minimize the cost of change. The cost of adding feature decrease over time – the promise of agile/code craftsmanship is that that time would not be exponentially – it would still be fairly easy to add a new feature a year from now.

Usually systems begin simple and beautiful and over time as the features accumulate it becomes more and more complicated. This can be handled by using evolution design/Iterative design which means that you take the time to clean your work after adding a feature instead of rushing to the next task on your to do list.

Early feedback by giving product early. Because it’s much nicer to change a system when its small. Thus reducing the time between doing something and finding out what you should have done.

The second part of the session was about testing and on how to reduce the Dev-QA feedback cycle which is why too long. In essence the objective is to know if the code today works as well as our code yesterday or even if our code work as well as 5 min. ago. Corey has talked a while about testing and automation and how to reduce the time to deployment.

One of the key points I liked was that we shouldn’t discuss whether or not a methodology A is better than methodology B we should discuss the value we’ll receive from using that methodology.

And finally a simple rule: If you choose not to use a practice, you must replace it with another of equal value.

Corey has answered a few questions from the audience about how to evaluate the cost of certain practices, mocking and working with legacy code followed by a short exercise – we had to parse Piet code by hand – namely the following “program”:

I caught two of Typemock’s finest – Gil Z. and Elisha writing a parser using unit tests and what looks to be a new soon to be released tool.

All in all an evening well…

Just a quick reminder

 

I’ll be presenting at the Agile Practitioners conference next week – so don’t forget to come and say hi. And incase you’ve missed Corey’s session or want to hear more of what he has to say about agile and software development in general – come to the Agile Practitioners conference next week.

Didn’t sign up yet – don’t worry because registration is still open. Just tell them I’ve sent you or better yet use this link.

See you there!

I’d like to tell you a story about how we manage tasks in my team…

Once upon a time (about a year and a half ago) I’ve started working in a new place. Since I’ve came from a company with very strong agile practice I wanted my new work place to be as agile as possible – and one of my first “missions” was to improve the way the team’s task tracking.

Task Board #1 – Sticky notes

I’ve convinced my manager to start using a “task board” which consisted of using sticky notes and one of the walls of the office. And as simple of that we had all of the team’s tasks in a simple, easy to read (and understand) display for the entire world to see. And the improvement was felt immediately. The team members could tell what are the priorities and their current and future work. And the team’s manager was happy because now it was clear what each of us were doing.

Some of the team liked the idea, some not so much… And over time it was clear who was updating his current progress and who’s tasks didn’t change on the board for the last two iterations.

Task board #2 – Distributed

I’ve done a quick check with the team to understand how we can improve the task board and one of the problem raised was that because the tasks were displayed on a wall that was less accessible to some of the team members they didn’t update their tasks as often as possible – instead of moving tasks from To-do to In progress and then Done they waited until several such “updates” were accumulated (or until they happen to pass by the wall) before moving the tasks on the board.

And so we’ve found a solution – each developer had his own task board right above his head. I know it’s not SCRUM but it worked for us.

And so we’ve continued working this way for a few months until another challenge presented itself…

From time to time a developer had to work on site which meant that he was out of the office and could not update his backlog another problem was that as the project progressed more and more top managers needed to know what the team is doing and whether or not we were reaching our goals. At about the same time the team has grown and we now were filling two rooms and looking to hire more developers and my manager had problems tracking the team’s goals.

Task board #3 – Excel spreadsheet in shared folder

Building upon past experience my manager came up with a simple Excel spreadsheet that was placed in a network share and that the team could update. The advantage was that Excel files can be copied, sent on email and shown at meetings a fact that helped explain what we were doing and how much time it would take to project managers, product owners and top management of our company.

We worked with the excel for a few iterations and it worked for us – we could move tasks between the team and everyone knew what everyone did. But the more we’ve used it the more it became clear that this “Excel task board” was holding us back. Since only one user is allowed to update the file – whenever two developers needed to update their progress it caused us grief – especially before start/end of iteration when all of us needed to update the file at once. Another problem was that once an iteration ended another file/book was created and the old iteration data was “archived” never to be seen again.

We knew we needed a better solution and we’ve found one just under our nose – TFS. We were already using TFS for source control and continuous integration (CI) server so why not use it to track our tasks as well.

Task board #4 – TFS + Work Item Manager

I was able to update the TFS Task using Visual Studio and we had a simple SCRUM workflow:

Using this task we were now able to use TFS as our backlog and task board. Another added bonus is that using Telerik’s TFS Work Item Manager we were able to see the old task board we were used to see on the office wall:

Now we had it all:

System that we can update easily – from the comfort of our Visual Studio

Easy to understand visualization

Statistics on iteration, remaining tasks and team progress

Project dashboard

And this is how we work today.

Conclusion

The lesson of this tale is that you should not be afraid to change. Just because we were using a tool that worked for us in the past didn’t mean that that tool cannot be changed if a better alternative is available, or if he required functionality changes. Because being agile is embracing change not just in the product you’re delivering but also the way you deliver it.

One final note

Using a task board is a simple practice and yet many teams just don’t track their tasks properly. Showing my team to use a task board is only one of the ways I’ve used to make them more “Agile”. If you’d want to learn more about how to make your team more agile or looking for tips and tricks that I found useful – I’ll be talking about it on my session at the Agile Practitioners Conference at the end of this month.

 

Happy Coding…

I was listening to another good Hanselminuets podcast - Understanding BDD and NSpec with Matt Florence and Amir Rajan. As always it was a good an informative show. Towards the end of the show one of the interviewees (I think it was Amir) explained why BDD is much better than TDD…

 

For those of you who does not know what I’m talking about – TDD is Test Driven Development (or design) and BDD is Behavior Driven Development. TDD is more “low level” talking about unit tests and integration tests and how to write code that test code while BDD is about specifications and behaviors.

In TDD we talk about Arrange Act Assert while in BDD we have Given When Then

Each methodology has its own frameworks that help write and run tests (or specifications) that make sure our code does what it meant to do.

Am I the only one that see a resemblance?

You might argue that one is better than the other till you blue in the face it does not change the fact that they are two sides of the same coin.

There are differences – BDD is more “high level” dealing with specifications and was intended to be used by domain experts as well as developers – although I’m yet to find the product manager that would write specifications. On the other side TDD is developer oriented and intended to be used by people who write and read code daily.

But regardless of these differences I don’t really see a reason why you should choose one over the other. I confess I use TDD and unit/integration tests in most of my projects but I do have several projects where I use both. I like the fact that I can write unit tests as well as specifications – because I need to test both. I also find myself using unit testing framework (i.e. NUnit) to write more “BDD’ish” kind of tests.

And so I don’t really understand why one is better than the other. Mainly because I prefer to use both – when possible.

And if you never tried BDD (or TDD) before I suggest you do and see for yourself.

 

Happy Coding…

Have you ever seen code that look like this:

public string GetStatusDescription(Model model)
{
    if(model.HasProblemReports)
    {
        return "Errors";
    }

    if(model.SystemState.WorkingMode == WorkingMode.NotManaged)
    {
        return "Manual";
    }

    if(model.SystemState.IsInitializing)
    {
        return "Initialize";
    }

    if(!model.SystemState.InService)
    {
        return "Not in service";
    }

    if(model.SystemState.WorkingMode == WorkingMode.Paused)
    {
        return "Paused";
    }

    if(model.Storage.Objects.Any(obj => obj.IsMoving))
    {
       return "Movement in storage";
    }

    return string.Empty;
}

I know I have – yesterday, I’ve changed the variable names and removed a bit of plumbing code but in essence this is a real function I had to work with.

The problem with this kind of code that it start out simple but quickly becomes hard to read and maintain. Because the ordering of the “if” statements matters as much as the condition itself.

One solution is to use the well known Chain of Responsibility pattern. although it would probably work in this case, I’ve noticed that developers shy from using it in code similar to this example. It’s as if they feel that they “waste” good code by creating a”whole class for two lines of code”. Another reason not to use CoR is that in this case I don’t want to encapsulate the logic of this method in a lot of classes – I just want to be able to easily understand what the method does and add/remove/update it easily.

I literally felt pain writing each new “if” statement until I could take it no more and so I’ve decided to refactor it.

First I’ve created a class to hold each condition:

class ModelToMessage
{
    private Func<Model, bool> _predicate;

    public ModelToMessage(Func<model ,="" bool=""> predicate, string message)
    {
        _predicate = predicate;

        Message = message;
    }

    public bool IsValid(Model model)
    {
        return _predicate(model);
    }

    public string Message{get; private set;}
}

Using this new class I was able to declare the following list and refactor my method:

private List<modeltomessage> _messageCreators = new List<modeltomessage>
    {
        new ModelToMessage(model => model.HasProblemReports, "Errors"),
        new ModelToMessage(model => model.SystemState.WorkingMode == WorkingMode.NotManaged, "Manual"),
        new ModelToMessage(model => model.SystemState.IsInitializing, "Initialize"),
        new ModelToMessage(model => !model.SystemState.InService, "Not in service"),
        new ModelToMessage(model => model.SystemState.WorkingMode == WorkingMode.Paused, "Paused"),
        new ModelToMessage(model => model.Storage.Objects.Any(obj => obj.IsMoving), "Movement in storage"),
        new ModelToMessage(model => true, string.Empty),
    };

public string GetStatusDescription(Model model)
{
   var messageCreator = _messageCreators.First(mc => mc.IsValid(model));

    return messageCreator.Message;
}

The last item on the list is the “default” item that is always true and return an empty string.

I really like the fact that it’s easy to understand which message comes before which message and it’s easy to add new conditions and change their priority.


Happy coding…

This post was created to answer a question by Laimonas Simutis on the ALT.NET mailing list – how to list all executed code…
There where many good ideas and your truly suggested using PostSharp – mainly because this is one of the examples I use in my AOP and PostSharp presentation. And so without further ado here is my solution for your consideration:

The “tracing” attribute

For this purpose I choose to use OnMethodBoundaryAspect which enable me to add hooks on method’s enter and exit:

[Serializable]
[MulticastAttributeUsage(MulticastTargets.Method, AllowMultiple = true)]
public class TraceMethodCallsAttribute : OnMethodBoundaryAspect
{
    private string _methodName;

    public override void CompileTimeInitialize(System.Reflection.MethodBase method, AspectInfo aspectInfo)
    {
        _methodName = method.DeclaringType.Name + "." + method.Name;
    }
    

    public override void OnEntry(MethodExecutionArgs args)
    {
        Console.WriteLine(">> {0}", _methodName);
    }

    public override void OnExit(MethodExecutionArgs args)
    {
        Console.WriteLine("<< {0}", _methodName);
    }
}

This is your simple method boundary aspect which is good to add custom functionality before and after method call as well as on exception and/or successful completion. This time I only needed the enter and exit functionality.
My attribute has several attribute of it’s own, one simple for serialization and the other is where the magic happens – the MulticastAttributeUsage that tells PostSharp that this attribute should be automatically applied to every method in the class or assembly.
Other than that I’ve also used CompileTimeInitialize in order to save some cycles by “calculating” the method name only once (at compile time) instead of each time the method is called.

Using the attribute

Now all I have to do is add this line to the AsseblyInfo.cs file:

[assembly: TraceMethodCalls]

And that’s it – running the following program:

class Program
{
    static void Main(string[] args)
    {
        var a = new A();
        for (int i = 0; i < 3; i++)
        {
            a.MethodOne();
            a.MethodTwo();
        }
    }
}

public class A
{
    public void MethodOne()
    {
        Console.WriteLine("I am in method one");
    }

    public void MethodTwo()
    {
        Console.WriteLine("I am in method two");
    }
}

Provides the desired result

Happy coding…

Time is a very limited and expensive resource. As a software developer I feel more often than not that I just don’t have enough of it…

That’s why whenever I find a new library or tool that save me time I embrace it with both hands, especially if they preform tasks that I find boring and tedious.

the following is a short list of three such tools that I find myself using daily because using them means that instead of writing the same code over and over again I get to focus on more interesting aspects of my job.

Configuration Section Designer

What is it: Visual Studio (2008/2010) add-in

License: Microsoft Public License (Ms-PL)

Website: http://csd.codeplex.com

Most project I know have some form of configuration, in the .NET world it usually means one or more XML files that have various key-value pairs that are used to store “configurable” application settings. The problem is that if you want to harness the full power of configuration that is available you have to learn quite a lot about configuration sections and/or write quite a lot of boilerplate code to serialize and de-serialize the configuration files properly.

Enter Configuration section designer – a visual studio add-in that help create and edit configuration sections (structure) visually. It’s really simple to use and about after 5 minuets you’ll be able to use it to create the configuration files you’ve always wanted.

After visually creating your configuration design you get the following:

1. XSD schema that you can use to add intelligence to your configuration files creation process
2. A config fie with simple outline that you can fill.
3. C# serialize/de-serialize file that is simple and easy to use to load/save the files from your application

CSD saves me hours each week - It slices, it dices and it verifies that your configuration is valid. I can created custom types and converters and it manages to stay simple and easy to use.

This open source project was dormant for quite some time and I’ve started to think its development was stopped, but I’m glad I was wrong with the new version that supports VS2010 CSD seems more alive than ever!

AutoMapper

What is it: .NET library

License: MIT license

Website: https://github.com/AutoMapper/AutoMapper

 

I hate writing conversion code. Converting one class to another class is tedious, error prone and it feels just “wrong”.

The problem is that there are quite a lot of architecture solutions that requires converting object from system A to a different object in system B. Luckily with AutoMapper all of the A.X = B.Y code just go away.

Mapping from the application’s internal object mode to DTO (Data Transfer Objects) or view model has never been easier. With a plethora of conversion abilities from simple property to property mapping up to custom converters. And if you build your classes the right way most of the conversion is done automatically.

It’s well documented and has a very good getting started guide that would get you up and running in no time. Using it at work was a simple matter of Add reference and I was ready to go. Since then AutoMapper has helped me rid of quite a lot of hard to read, error prone lines of code.

PostSharp

What is it: .NET library

License: Commercial (has free edition)

Website: http://www.sharpcrafters.com/

I’ve started been using PostSharp extensively and never looked back. I keep finding new ways to harness its power and I’m happy to see that more and more of my co-workers are solving problems easily using AOP (Aspect Oriented Programming).

Using PostSharp I’m able to create “attributes” that encapsulate cross-application concerns and I’ve stopped counting the times that my logging attribute has helped us track a bug in one of our servers.

Conclusion

With each new tool under my belt I become better at my job. The examples above are only three such tools and I’m always happy to learn about a new one I can use.

So if you enjoy learning new tricks - try them for size and decide if they’re good for you.

 

Happy coding…