Living in the Tech Avalanche Generation

As a software development manager and now CTO, I spend a fair amount of my time thinking about how to converge two very important ideas and blend them harmoniously. The ideas:

• create a great place for developers to work, one where they maintain a keen and genuine excitement about their profession and look forward to the daily challenges and comradery that great success stories in software delivery can produce.
• Build a vibrant software development consultancy that offers it’s clients great commercial options and results; and help drive great concepts into great business outcomes.

Can these ideas co-exist successfully? Absolutely they can and what’s more they are mutually enabling. Over the years I have held positions as a senior developer, Software Development Manager and CTO, and I always try to take the attitude of developing an environment that I would have liked to work in as a developer myself. Three main things I have found to make for great developer working environments are:

• A commitment to developer career growth through training.
  • This does not have to be via third party training providers. With the right investment of time and good technical leaders and teachers, it is very possible to implement valuable training programs internally.
  • ITR have just recently committed to a training program modelled around the ‘code camp’ style of training becoming so popular today.
• Team Development Projects.
  • Encouraging an environment where even the smallest projects are attended by more than a single developer. This isn’t always possible, however setting it as a goal can help under circumstances where your team is very small.
  • Developers (good ones IMHO) are attracted to the idea of working in teams and not silos.
• Expose your team to best practices, good design principles and tools & exciting new technologies.
  • Developers love to use new tech! Just make sure it doesn’t come to the detriment of your clients / projects.
  • Developers also love to know that they are using tools, methodologies and practices that have value in the community and that their career opportunities are improving with ever developing new found skills. Trying to trap developers into an environment where they become pigeon holed and get no opportunity to grow doesn’t help you retain good people; good environments retains and breeds good people.

All this can lead to happy developer employees who stay and grow with your business and afford you the ability to attract some talented people via recruitment into the bargain.

For those of you who are struggling with the idea or even still the practice of applying Domain Driven Design and using Microsoft Technology in the process, there is some very good news (potentially). Danny Simmons (noted Microsoft ADO.Net / Entity Framework team member) announced the advisory council for Data Programmability. This council is a who’s who of the DDD world and so it should provide some great real world commercial & practical requirements to the team in driving forward the next versions of products such as LINQ to SQL and the Entity Framework and making these tools more effortlessly support the practice of DDD. Now having said all that, you can get some part of the way their now and Ian Cooper has produced some good work in that area. I must admit that I have avoided taking a really serious look at the EF because persistence ignorance isn’t possible in the first release, however I am starting to feel a bit more positive about about subsequent releases given this latest announcement and Danny Simmons previous announcements that PI supporting infrastructure would be baked into V 1.0 making it’s inclusion in subsequent versions more likely without breaking changes being required.

Firstly let me say that I love LINQ. However like any technology stack there are always some gotcha’s that you need to watch out for. Deferred execution is one of LINQ’s great features, however if your not thinking clearly when you use LINQ you could be writing some really poorly performing code.

Consider the following code:

[Test]
public void AbstractFactoryAssertions()
{
     ////mock the factory
     var mock = new Mock<Soccer>();
     //setup a shape
     BallShape shape = BallShape.Round;
     BallType style = new BallType(shape, “Synthetic Fibres”);
     //assert correct state
     Assert.AreEqual(mock.Object.GetBallType().Style.
                     ExternalMaterial, “Synthetic Fibres”);
     Assert.AreEqual(mock.Object.GetBallType().Style.Shape, shape);
     Assert.IsTrue(mock.Object.IsPlayedInternationally);

     //***********************
     //THIS IS THE SMELLY CODE
     Assert.AreEqual(mock.Object.ToString().“Proxy”),
                    mock.Object.ToString().Length -
                    “Proxy”)),
                   “Australia England France Poland” +
                   “UnitedStates all play Soccer”);
                   Assert.IsTrue(mock.Object.GetType().BaseType ==
                   typeof(Soccer));
     //END OF THE SMELLY CODE
     //**********************
}

The smelly code above (see code comments), force three calls to the ToString() method of the Soccer class and this method is defined in the Abstract Factory class of FootballCode, which the Soccer class inherits from. It is the code in the ToString() method of FootballCode base class where we strike problems.

public override string ToString()
{
    var exp = from c in PlayedIn
              select c;
    StringBuilder _tostring = new StringBuilder();
    string myname = this.GetType().Name;
    foreach (Country c in exp)
    {
        _tostring.Append(c.GetType().Name + “|”);
    }
    return _tostring.ToString().Replace(‘|’, ‘ ‘) +
                “all play “ + myname;
}

Three calls to the ToString() method in our test will force the LINQ query to execute three times when we only needed to do so once. It’s an obvious mistake but you need to make sure that wherever you have code that will execute a LINQ query, you remain alert as to how you use or call on it. Lets fix the offending code:

//********************************************
//            Fixed Smelly Code

string soccerToString = mock.Object.ToString();
int idxProxy = soccerToString.LastIndexOf(“Proxy”);
int soccerLength = soccerToString.Length;
Assert.AreEqual(mock.Object.ToString().
                Remove(idxProxy, soccerLength - idxProxy),
                “Australia England France Poland” +
                “UnitedStates all play Soccer”);

//            Fixed Smelly Code
//********************************************

By averting the repeated calls to the ToString() method we bypass the redundant execution of the LINQ query. Actually this is a pretty obvious thing to avoid, but developers need to be vigilant as they TDD there way through the design of the object or domain models. For example, I actually should have refactored the code above in the ToString() method and probably moved it into my constructor and stored the result in a private member and continually referenced it’s value from the ToString() method, making the entire process of getting the data static by nature post object creation.

Another thing to pay attention to is awareness of how deferred execution works and staying clear of nested filtering and setting parameters in variables at the correct juncture. For example if we take the following method:

public void ExampleOfLinqBehaviour()
{
    List<Country> engspeakCountries = new List<Country>();

    string _name = “UnitedStates”;

    var query = from c in PlayedIn
                where c.GetType().Name == _name
                select c;

    //the query will use this as
    //the parameter to the where
    //clause and NOT the value
    //of UnitedStates
    _name = “Australia”;

    //query gets executed here in the 
    //foreach loop and therefore the
    //_name parameter is only used once
    //in the case where its value is
    //equal to Austral and NOT UnitedStates.
    foreach (Country c in query)
    {
        engspeakCountries.Add(c);
    }

    var queryFilter = from c in query
                      where c.Region == “Asia Pacific”
                      select c;

    //this will force both linq queries to
    //execute like nested loops. The first query
    //should already probably have executed rather
    //than executing a second time redundantly
    foreach (Country c in queryFilter)
    {
        Console.WriteLine(c.Region);
    }

    //sometimes you will improve performance by
    //forcing the LINQ query to execute
    var queryForced = (from c in PlayedIn
                where c.GetType().Name == _name
                select c).ToList();

    //iterate the list once only
    queryForced.ForEach(c => Console.WriteLine(c.Region));
}

The mistake above lies in the intention to query with a ‘where’ filter that matches on the initial value of the “UnitedStates”, which is subsequently overwritten prematurely with the value of ‘Australia’ and due to the nature of deferred executing, the query will not execute until the first foreach() statement is executed.

The Debugger & Tracing LINQ To SQL

A final cautionary note: if your tracing SQL queries that are being executed by LINQ To SQL and you use the debugger to expand the results view before a query has executed, it will in fact force the query to execute, producing the harvested results and by sending the appropriate TSQL command to the Server.