Agile Software Development In 5 Minutes

I have released a course on Pluralsight called Agile Fundamentals that talks about Agile Software Development in detail.

I have also written an article on Common Agile Misconceptions.

Recently, I have been doing lots of recruitment for .NET consultants. Each of the CV’s we receive all stress that they are experienced in working in agile development shops. This is great. We are an agile development company so these people sounds like a great fit.

Agile Software Development - Embracing Change
Agile Software Development – Embracing Change

So we get them into an interview and ask them, ‘What does agile mean?’, ‘How do you know if your team is truly agile?’ It’s at that point we get the standard list of responses:

  • We do Test Driven Development.
  • Daily stand-ups.
  • We pair program.
  • We use continuous integration.
  • We use SCRUM, KanBan, XP etc.
  • Use work in iterations.
  • We use story points.
  • We calculate team velocities.

These answers are all well and good, but they don’t describe what an agile team is. These are all just facilitators to being agile. What’s even worse is that these interviewees seem to have not heard of the agile manifesto.

Book Review : The Architecture of Open Source Applcations

I am a bit of a book worm, especially with technical books. I love nothing more than to extend my knowledge on my craft. I wanted to let you know about a book that I have been reading recently that is absolutely fascinating. The book is called, the Architecture of Open Source Applications.

The idea behind the book is simple. If you were an architect constructing buildings, you wouldn’t do so without studying how other buildings are constructed. The premise is the same for software. As a software developer / solutions architect, how can you design applications without first studying how other applications are designed and built? That is exactly what this book does.  This book covers 25 open source applications and discusses how they were built and designed.

Amazon.com Paperback | Kindle

Amazon.co.uk Paperback | Kindle

Architecture of Open Source Applications
Architecture of Open Source Applications

Unit Test Coverage, Code Metrics, and Static Code Analysis

Back in a previous article I discussed a process I now do with my team to conduct code reviews. The idea is to drive up code quality by better use of the tools available to developers. By focusing on the tools and process that we follow to develop code we can collectively drive up quality. The basic process was as follows:

  • Get the code out of source control fresh.
    • Does it build? Yes then continue, No then stop the code review.
  • Run the unit tests.
    • Do they run and all pass? Yes then continue, No then stop the code review.
  •  Check the unit test code coverage.
    • Is the coverage around >60%? Yes then continue, No then stop the code review unless there is a good excuse for the coverage that the review team are happy with.
  •  Check the code metrics (Cyclomatic Complexity and Maintainability Index)
    • Are the metrics within agreed boundaries? Yes then continue, No then stop the code review.
  •  Run the static code analysis against the agreed rule set?
    • Are there any warnings / errors? Yes then stop the code review, No then continue.
  • Once you get to this point, the development practices have been followed and you can proceed to review the actual code.

All of the tools I discussed above are available as standard to developers who use Visual Studio Enterprise Edition, except Resharper/CodeRush etc.

Unit Test Coverage

Whilst you are developing your software you should be writing tests to exercise that code. Whether you practice test driven development and write your tests first or write tests after the fact, you need a decent level of test coverage. This gives you a level of confidence that the code you are writing does what you expect it too. Also, it gives you a safety blanket when you need to refactor your code. If you make a change in one area, does it break something somewhere else? Unit tests should give you that answer.

The screen shot below, shows the Test Explorer view in Visual Studio 2012. From this view you can run all of your unit tests. As of Visual Studio 2012 Update 1, you can group you tests based on pass outcome, length of execution and project. Think of this view as your project health dashboard. If you have a good level of coverage and they are all green, then you can carry on developing. If you have any red tests then you need to work out why and fix them. Don’t let this view lead you into a false sense of security though. You still need to write tests to a decent level of coverage and ensure you are testing the right things.

Visual Studio 2012 - Test Explorer
Visual Studio 2012 – Test Explorer

You can check your test coverage very easily in Visual Studio. First you can click the little drop down ‘Run’ menu in the Test Explorer, or you can open the ‘Test’ menu in Visual Studio, and then open up the ‘Analyse Test Coverage’ and select ‘All Tests’. This will give you a view similar to below.

Booting Windows 8 Straight to the Desktop

I recently decided to give Windows 8 a try on a spare laptop as I was keen to see what Microsoft had done with it. I normally don’t jump on new versions of Windows straight away as I don’t really have a need with the sort of work that I do. But curiosity got the better of me this time.

My first impressions are generally very good. I found not having the traditional Start menu strange at first, but after a while I didn’t really miss it. What is useful is you can press ‘Windows Key + X’ and you get a stripped down version of the start menu with the important links like Control Panel, Run, Search etc.

The new Tiles screen (formally Metro) is quite nice, and I can certainly see how this would be great on a tablet or touch screen. When you work on a desktop machine or traditional laptop, I find it best to think of the Tiles screen as a fancy Start Menu that you can switch too with the Windows Key.

But being as picky as I am, I wanted Windows 8 to boot straight to the desktop. This is possible, but there is a little setup which is very easy to do.

Just follow the next few steps and you will have Windows 8 booting straight to the desktop.

  • First load up the Windows Task Scheduler. The easiest way to do this is to go to the Windows 8 search bar and type ‘Task’.
Boot Windows 8 to Desktop : Task Scheduler
Boot Windows 8 to Desktop : Task Scheduler

Softening the Blow of the Visual Studio 2012 User Interface

I really like Microsoft’s new version of Visual Studio. I even like where they are going with the user interface, but out of the box, I don’t think it is perfect. I really don’t like the SHOUTY uppercase menus, and whilst I don’t mind the default colour theme too much, it isn’t great for staring at on a long coding session.

In this post, I will cover 2 very easy tweaks that you can do to Visual Studio 2012 to make the user interface much better (in my opinion of course). I have recently been getting my team to update parts of our code base to the new tool set  and most people had the same feelings about the user interface as me, but most of the team have now done these tweaks.

Turn Off Upper Case Menus

Visual Studio Upper Case Menus
Visual Studio Upper Case Menus

I don’t know why Microsoft decided to go with the Upper Case menus, but it is really easy to disable them. Just follow these basic steps.

Simple Dependency Injection

When you are working in the real world (especially on enterprise software) you will find yourself having to support and enhance an older code base. These code bases can vary quite considerably in quality. In the worst case you have legacy code that contains no unit tests. When you need to maintain and enhance this code you really should try to get some tests wrapped around the code, but this is easier said than done.

The code may contain lots of hard coded dependencies to objects that makes adding in clean, isolated unit tests difficult. These hard coded dependencies may access the file system, make database calls or access any other external resources making writing isolated tests difficult.

What do I mean by a hard coded dependency? Well, take a look at the following simple example.

using System;

namespace HardDependency
{
    public class ExampleClass
    {
        public string GetText
        {
            get
            {
                return "Hello, I am a hard dependency.";
            }
        }
    }

    public class MyProgram
    {
        public void DoSomething()
        {
            ExampleClass example = new ExampleClass();
            Console.WriteLine(example.GetText);
        }
    }

    class Program
    {
        static void Main()
        {
            MyProgram program = new MyProgram();
            program.DoSomething();
            Console.ReadLine();
        }
    }
}

In this simple example we have a class called ExampleClass. This class has a property that returns a string. The class MyProgram has a method called DoSomething() that creates an instance of ExampleClass and calls the property to display the returned string. You may be thinking that nothing untoward is happening here, but what you see here is an example of a hard dependency, or coupling, between MyProgram and ExampleClass. Lets imagine ExampleClass is doing something much more complicated like reading data from a database. If you try to write a unit test to cover the functionality  of the DoSomething() method in MyProgram then that unit test will be making a database call. This is not a unit test. It may run fine on your development PC, but when you try to run these unit tests on your build server, it will also try to make a call to the database. A build server shouldn’t have access to an applications database. Also, what if that call to the database changes the state of the data, so that the next time you run the test, the data has changed, so the test fails. This is not a good situation as you now not only have tight coupling in your code, but you are also coupled to the state of the data in your database.

Structured Code Reviews and Code Quality

I was reading an interesting article on The Register today called “What Compsci textbooks don’t tell you: Real world code sucks”. Whilst the title of the post is quite brash, I did find myself nodding my head at pretty much everything in the post. As a Lead Developer at a financial services company, code quality is something that bothers me constantly, both in the legacy systems I have inherited and the new systems we are developing. I thought I would add comment to one of the points in the original post.

“A tremendous amount of source code written for real applications is not merely less perfect than the simple examples seen in school — it’s outright terrible by any number of measures. Due to bad design, sloppy or opaque coding practices, non-scalability, and layers of ugly “temporary” patches, it’s often difficult to maintain, harder still to modify or upgrade, painful or impossible for a new person joining the dev team to understand, or (a different kind of problem) slow and inefficient. In short, a mess.

Of course there are many exceptions, but they’re just that: exceptions. In my experience, software is, almost as a rule, bad in one way or another.”

I feel like I have been living this every day over the past 18 months. I have inherited some systems that are very challenging to work with. They contain code that is very hard to maintain, doesn’t scale and has virtually no unit test coverage. Pretty much all of the original authors have now all moved on, but that still leaves a waste ground of code for my team to maintain.

Structured Code Review and Code Quality
taken by Marc Amos

I now have a decent team working under me, and they are trying as best as they can to tame this huge legacy beast, and they are doing a pretty good job with what they have got, but we still find ourselves having to make compromises that make us uneasy due to time pressures, shifting priorities and lots more reason.