Living in the Tech Avalanche Generation

I had the pleasure of recently listening to one of the most entertaining podcasts I have heard in a while where Scott Bellware was the guest in question. Scott is a captivating speaker and always prompts you to challenge your own beliefs and ideas as a developer. The podcast was intended to be centred around a discussion on BDD however Scott points out that he practices “Context Specification” and that it differs somewhat to BDD.

Something that has stayed with me in the weeks passed since listening the to discussion, is Scott’s description of developers as ‘high functioning autistics’. The context in which Scott makes the observation is one where he expresses a desire for developers to speak more fluently in the language of the business and desist in articulating implementation details or information of no business value. I’m sure that most people will find that idea logical and reasonable (as I do) however I feel that it’s worth throwing some attention onto the business and how it communicates in the reverse direction.

Any relationships success relies on the mutual respect and determination of all parties to participate in functioning cohesively to achieve a common goal. Yes developers should aim to achieve communicating more effectively with the business but it should be said that business people must take an equal position of responsibility for the success of communication between the parties. I’m pretty sure that most developers have worked in environments with little structure or discipline, where ad-hoc is the methodology of the day and expectations are generally unreasonable. I am sorry to say that I have seen developers purposefully communicate in an abstract way with business people, in an attempt to shield themselves from the kind of environment I just described.

I find it curious that we even speak of ‘developers’ and the ‘business’ as separate entities almost as though they exist in different dimensions; surely we developers work for the very same business as do those in HR, Sales or Warehousing? By definition we must also be considered part of the business. Seriously though, I understand the distinction when we speak about ‘software’ and the ‘business’ in terms that express a notion of separation, but I guess I am starting to think that it’s a consequence of the inadequacy of language that helps in promoting exactly some of the problems that Scott wants to see eradicated.

I think it’s worth making the observation that whilst developers should take responsibility for themselves in communicating more effectively across the organisation they serve, it’s incumbent on all parties to create environments designed for successful communication that travels in all directions. There have been plenty of occasions where I have seen ‘business people’ behave in a fashion that demonstrated a lack of respect and understanding of those sitting on the IT side of the fence. Respect is a two way street.

The question as to what the differences between Use Cases and User Stories is something that comes up quite often and some people will argue that they both help to achieve the same thing. Further discussion on that I will defer to debate elsewhere.

Over the last few years I have been using what I feel is a combination of the two elements rolled into one. One of the common held notions about User Stories is that they consist of written text that describes a functional unit of the system. Use Cases also describe functional units of work, semantically expressed through the use of the UML. My personal experience has been that the functional requirements can be well captured, represented, worked from and estimated using both approaches combined into one single method. Let me explain by way of example, where a single use case is catalogued using the following templated documents.

Figure 1.0 – User Story

What figure 1.0 shows is that we have combined the concept of several different approaches to suit. The UML for me has always been a great visual way of describing a system to both business stakeholders and developers, the BDD story title mirrors the Use Case name (UML) and the BDD story maps nicely to the Agile concept of the paragraph of text that describes a User Story. Added to that I can include scenarios to test if I am using BDD and further to that we include the document shown here as figure 2.0, the stories ‘Detail Table’.

Figure 2.0 – User Story Detail Table

The detail table I found some time ago somewhere on the web and I cant remember exactly where so my deepest apologies to the author (if you recognize it please let me know and I will update this post). Again some more context here but mainly for the developer however it’s certainly within the grasp of a business analyst. As far as estimation goes, I am an advocate of first up estimation using Case Points Estimation techniques and then factoring in subsequent estimation off velocity and burn down rates.

I recently posted on how to do state based testing with Repositories and the Entity Framework but failed to mention that if you are using a mocking framework like MOQ, that enforces that Mocked behaviours are required to be virtual, then that’s fine, but it’s bad practice (IMO) to leave the after effect of that lying around in the release versions of your code. Here’s an example:

var mock_repo =
    new Mock<EntitiesRepository<Customer, NorthwindEntities>>
    (fake_entity_model);

mock_repo
    .Expect(repo => repo.AllToIList<ICustomerMakePrefered>())
    .Returns(new List<Customer>()
    {
        new Customer()
        {
            CustomerID = “ALFKI”,
            Country = “Germany”,
            Orders = orders
        },
        new Customer()
        {
            CustomerID = “SIMSE”, Country = “Australia”
        }
    });

When using MOQ, this requires the Repository to have it’s AllToIList method marked with the virtual access modifier but that isn’t necessarily my intent. One way of approaching it is conditional compilation.

#if(DEBUG)
public virtual IList<TEntity> AllToIList()
#else
public IList<TEntity> AllToIList()
#endif
{
    var entity_set_name = FindEntitySetName();

    var qry = _ctx.CreateQuery<TEntity>(“[" + entity_set_name + "]“);
    return qry.ToList();
}

So conditional complication directives help clean up our code and make sure that any requirement in mocking is not overriding our object design intentions.