Building simple, usable interfaces, architectures and products

I've recently finished reading a fantastic book: Simple and Usable. It's best read as a physical book, due to the stylish, magazine layout of text and full-page pictures. It's easy to read, but thought provoking. Concrete steps describe how to improve a user interface. These steps are easy to understand, but will no doubt require discipline to apply correctly.

Although each page offers a tasty morsel to digest, one page (76), entitled Solutions, not processes, jumped out at me. It asked the question: is there another way to solve this problem? I had recently read the very same words, in this architecture check-list, and they were then echoed again by Michael Dubakov's insightful article on Product Owners as a SPOF.

So often we rush to produce a solution, without considering the alternatives. Our team is currently trying to scale out and speed up in a big way, so we're focussing hard on optimising cycle-time. Despite the diversity of these articles, they all provide a clear reminder to not rush the creative process that leads to the best solutions. Don't rush it, but still optimise it - that's the challenge.

If you're a skilled User Interface Specialist that would like to be part of this challenge, please get in touch - we'd love you to join our team!

Calling one WCF service from another

Over a year ago I hit this problem, and no amount of work would fix it. A year later, having found myself facing it again, I finally found the solution, thanks to this post.

Whilst the solution was simple, I've written my services so they can be unit-tested. Hence references to instances that require the presence of an HttpRequest are not allowed.

The picture below shows my eventual solution. Whilst it has a large number of classes/interfaces, they are each very small and focussed. They combine together extremely well to allow one service to call another, using Inversion of Control to access the child-service's client.

From Tiny drops of knowledge

Deciding between ref and out

C# defines two keywords for parameter passing modes: ref and out. For a full discussion of why this is, see this msdn article, from where the below examples are taken. This is a summary of which to choose and why.

When to use neither

ref and out are used for methods that pass back two or more values to the caller. This is often a code smell indicative of the need for a new encapsulating struct or class. As a rule of thumb, where three or more ref’s or out’s are required, use a struct or class to encapsulate them into a single parameter instead.

When to use 'out'

Use out when the method’s focus is to provide two or more new return values, some of which may be null/empty.

In the following example, the firstName and lastName parameter values are only of interest after the call to SplitName. Neither the callee nor the caller require knowledge of their initial value, and its valid that either or both remain null/empty.

class OutExample
{
   static void SplitName(string fullName, out string firstName, out string lastName)
   {
      // NOTE: firstName and lastName have not been assigned to yet.  Their values cannot be used.
      int spaceIndex = fullName.IndexOf(' ');
      firstName = fullName.Substring(0, spaceIndex).Trim();
      lastName = fullName.Substring(spaceIndex).Trim();
   }

   static void Main()
   {
      string fullName = "Yuan Sha";
      string firstName;
      string lastName;

      // NOTE: firstName and lastName have not been assigned yet.  Their values may not be used.
      SplitName(fullName, out firstName, out lastName);
      // NOTE: firstName and lastName have been assigned, because the out parameter passing mode guarantees it.

      System.Console.WriteLine("First Name '{0}'. Last Name '{1}'", firstName, lastName);
   }
}

When to use 'ref'

Use ref when the method’s focus is to return a value and make use of and potentially update a second value.

In the following example, the index parameter’s value is of interest before and after the call to FindNext. Both the callee and the caller require knowledge of its initial value, and its valid that it may be modified by the call to FindNext.

class RefExample
{
   static object FindNext(object value, object[] data, ref int index)
   {
      // NOTE: index can be used here because it is a ref parameter
      while (index < data.Length)
      {
         if (data[index].Equals(value))
         {
           return data[index];
         }
         index += 1;
      }
      return null;
   }

   static void Main()
   {
      object[] data = new object[] {1,2,3,4,2,3,4,5,3};

      int index = 0;
      // NOTE: must assign to index before passing it as a ref parameter
      while (FindNext(3, data, ref index) != null)
      {
         // NOTE: that FindNext may have modified the value of index
         System.Console.WriteLine("Found at index {0}", index);
         index += 1;
      }

      System.Console.WriteLine("Done Find");
   }
}

How long to change a culture?

A current project I have on the go is writing a C# console app to replace an ageing VB5 application.

For many on the project, this is the first time writing production C# instead of VB. In addition we're aiming at a SOLID design, aided by NUnit, Spring.Net and of course Cruise Control.Net.

A reoccurring challenge we've faced on this project is re-learning how to write software. Its more than just learning a new language, tool or framework, its more like loosing the shackles of apartheid. This analogy may seem a little strong, but it was quite clear to me after discussing with an Afrikaans South African (in his 20's) just how long it would take for his country to be free of apartheid's effects: we concluded at least three more generations.

Whilst I know that the team won't have to be great-great-great-grandparents before we loose the shackles of VB and procedural programming, I need to remember that cultural of change of any sort doesn't just happen overnight!

This was further driven home to me today when ThoughtWorks met with us to discuss an upcoming project. They shared how to aid culture change, they send newbies on a boot-camp that lasts 6-8 weeks!

QCon 2007 - What I learnt about architecture

This is the first post in a series that summarises what I learnt at QCon 2007.

This post focuses on solution architectures.

For a mind map version, click here

Inspiration came from the following excellent sessions:

• Amazon Technology Platform - Werner Vogels (CTO)
• Putting qualities into architecture - Kevlin Henney
• Modifiability - Martin Fowler
• Operational Manageability - Dan Prichett, ebay Technical Fellow
• Agile Architecture is not Fragile Architecture - Kevlin Henney and James Coplien

Replacing Amazon's architecture

• Monolithic application to SOA
• Took 6 years
• Cost $2 billion
• Only 30% of cost delivered visible business value
• 70% was on the "heavy-lifting"

Architecture relates to

• how it runs
• how it fails
• how its developed
• how it changes during
• development time
• run-time

Architecture is interwoven with the development process

Operational manageability

• Design for
• operational configuration
• operational monitoring
• failure (no SPOF's)
• Maintain clear dependencies
  

Design up-front the parts that are costly to change

• Reduce the significance of remaining decisions
• Defer decisions to the last responsible moment
• Metric is cost of reversing decision
• e.g.

• testability
• security
• maintainability
  
• performance
• Its like putting stones in a bucket.

How much up front design (UFD)?

• BUFD - Big
• RUFD - Rough
• NUFD - None
• Time spent should be inversely proportional to
• Knowledge of domain
• Experience in design

Quotes

• "A stable architecure is not the same as a frozen architecture"
• "Doing the simplest thing that works is not same as doing the easiest thing"

Principles of software development

My blog reading (Jeff Atwood, Scott hanselman) the past few weeks has turned up some excellent articles on principles of software development. For ease of reference, I've grouped them together here:

• The DRY principle (Don't Repeat Yourself). Published originally in The Pragmatic Programmer, an abbreviated version is available in this pdf.
• Robert Martin's SOLID principles:
• Single Responsibility Principle (SRP) - pdf.
• Open Closed Principle (OCP) - pdf.
• Liskov Substitution Principle - pdf.
• Inversion of Control - martin fowler's article, msdn article.
• Dependency Inversion Principle - pdf.
• Principles of package design - an excellent pdf that covers:
• Principles of package cohesion:
• Reuse-release Equivalence Principle
• Common Reuse Principle
• Common Closure Principle
• Principles of package couping:
• Acyclic Dependencies Principle
• Stable Dependencies Principle
• Stable Abstractions Principle

The next thing I need to mull over is how best to learn, apply and pass on these principles. Watch this space.