What's a tractor for

Imagine that you teach someone how to drive a tractor, how to hook up a plough, and you send them out into the field.

At no point do you mention crops, seeds, harvesting, food, or seasons. You don't speak of fertiliser nor crop rotation.

When you come back the field is full of staggering, incredibly complex and mostly useless furrows.

In the same way we seem to teach people how to use polymorphism, lambda functions, inheritance, iterators, and other tools.

But somewhere along the way no one has pointed out the fact that what we are doing is trying to make it easier to write and maintain code. In addition, it would be nice if we could also make it easier to be sure the code is correct. 

It seems that we have taught the how, not the why.

In the good old days of C++ the general comment was that in your first program you learn how to overload the operators, in your second program, you learn not to.

Design V Hack

Implementing a feature can be done quick and dirty, or you can spend time and do it right.

Sometimes, it makes sense to do it quick and dirty. If you need a demo by Tuesday to get a foot in the door, or if you're not even sure what you are doing. Bang something together figure it out, write it properly later.


The cost of banging it out any old way that works is simply deferred. Later you pay the cost, either in a re-write or in maintenance nightmares.

If your "feature" has infected a lot of the rest of the code base, then a rewrite is expensive. If it's in structural code, which everyone depends on, then that nasty interface is already in use, and now, not only do you pay back the work you saved, you also pay back the interest and penalties. (You may have thought that credit cards were harsh). There's even a term for this :- Technical Debt

As you add hack after hack to a project, or even just messy code that's difficult to follow, the savings start to disappear. Now to change something, you need to spend more time understanding difficult code. Now it takes more time to change anything. The process continues until the code becomes intractable. Then each bug fix introduces new problems. Each change takes longer and longer.

People say they have no time for refactoring, automated testing, and just plain writing better code. I'd argue, you don't have time not to.

The Architectural IF

"IF" is one of the fundamental constructs of programming languages. (Yes, I know someone will know at least 3 languages without "IF", but I know a lot more which have "IF").

"IF", like a Biro is so ubiquitous that it's pretty much impossible to imagine life without it.

But as the Biro has been superseded by the Computer for works of any length, "IF" has been superseded in many ways by better ways of doing things.

If makes a nice living dealing with details. But often we can avoid it by simple design

 var myClientList = GetClientList();  
   
 if (myClientList != null)  
 {  
   sendAnnoyingEmailsTo(myClientList);  
 }  

What if GetClientList() never returned a Null. If something goes wrong, it throws and exception, if there's no clients, it returns an empty list. Now my Code looks like

 var myClientList = GetClientList();  
 sendAnnoyingEmailsTo(myClientList);  
   

This is a flavour of the null object pattern. There is no decision to make. There is no spoon "IF".
But that's a detail, it's the The Architectural "IF" that 'causes me to occasionally consider inventive and infantile revenges on both other programmers, and in fairness, on my past self. If you find a comment like this..

 } // closing if (clientObject is typeof(MajorClient))  
   

The comment indicates there is so much code dependent on the "IF" that you cannot see the other brace on screen. It also darkly hints at a programmer cheerfully ignoring virtual functions.

So why is the programmer doing this?
Surely (s)he:

•  cannot be ignorant of virtual functions? 
•  cannot fail to realise that a new dependency is being propagated throughout the code?
•  must know that now every new Client Sub Class will need to be weaved in through every file that uses the "construct"?

The answer is almost certainly in the class hierarchy. It's broken. It's wrong. Something in there does not fit in well. The base class is OK for most of the sub classes, except for just this one case, and well maybe the case here too. So instead of fixing the problem, the The Architectural "IF" is brought to bear. Flick quickly to the matching brace, and you will almost certainly find something like this...

It may even be an "else if".

If your Architecture is creaking, "IF" can fix it for a while, but like using sticky-tape, the repair is at best temporary.

Write it Right

Shakespeare's Casear siad "cowards die many times before their deaths, the valiant never taste of death but once."


Write code badly and you will taste it again and again and again. (and it does not improve with subsequent re-heatings)


"Write It Right" and you only need to see it again when something relevant changes.


It may take twice as long to "Write It Right", but if you figure out how much time gets spent fixing bad broken code one "stoopid" at a time, twice as long seems like a bargain.


Add in secondary costs, Building Releases, Damage to Customer Confidence, Direct Cost of Bugs, and WIR seems so obvious it hardly needs to be said.


Yet, it would appear, it needs to be said again and again and again.


WIR

Know what is executing when and where...

If we run this test, it throws an uncaught exception from the thread pool. Uncaught exceptions from the thread pool will crash your app.

The key to this is that the lambda is not executed here and now. The Lambda is passed to the thread pool.
The thread pool executes it, but only after we have set our classWithFunction member variable to null.

 class ClassWithFunction  
 {  
   public void fn()  
   {  
     System.Console.WriteLine("Hello World");  
   }  
 }  
   
 ClassWithFunction classWithFunction = new ClassWithFunction();  
   
   
 [Test]  
 public void testThreadPool()  
 {  
   ThreadPool.QueueUserWorkItem(state => classWithFunction.fn());  
   
   classWithFunction = null;  
   
   Thread.Sleep(2000);  
 }  
   

If you consider the Lambda in terms of a function, it all becomes a whole lot clearer. By the time ThreadPoolFunction is called, classWithFunction is null.
This is referred to as a modified closure. The Lambda does not get a copy of our variable, it actually uses our variable in place.

 class ClassWithFunction  
 {  
   public void fn()  
   {  
     System.Console.WriteLine("Hello World");  
   }  
 }  
   
 ClassWithFunction classWithFunction = new ClassWithFunction();  
   
 [Test]  
 public void testThreadPool()  
 {  
   ThreadPool.QueueUserWorkItem(ThreadPoolFunction);  
   
   classWithFunction = null;  
   
   Thread.Sleep(2000);  
 }  
   
 private void ThreadPoolFunction(object state)  
 {  
    classWithFunction.fn();  
 }  

And if you look closely, you will see that this IS different and it works quite nicely. Of course, the downside of this as a solution is that someone will surely come along and remove the "unnecessary" temporary variable.

 [Test]  
 public void testThreadPool()  
 {  
   ClassWithFunction tempClassWithFunction = classWithFunction;  
   ThreadPool.QueueUserWorkItem(state => tempClassWithFunction.fn());  
   
   classWithFunction = null;  
   
   Thread.Sleep(2000);  
 }  

Perhaps it would be better to move up to .net 4 and use the Parallel Task Library instead.

Important / Urgent

From the good old Important / Urgent time management graph, we can see how Code Quality is not "Urgent" but the fallout of poor code, Bugs, are both Important and Urgent.

If we ignore Code Quality, we borrow against future effort and build up a technical debt. We end up with more bugs which are important/urgent, which means less time for Code Quality, which means more bugs.....

Rinse, Repeat, buy an "Inside I'm Screaming" teeshirt.

	Not Urgent	Urgent
Important	Code Quality	Fix Bugs
Not important	Fix "trivial" bugs	Coffee

Clearly, this is an incomplete table, but you get the idea.

Tragic Heroes of Design

I doubt you could find anyone who has studied literature who could not talk about the "Tragic Hero". It has been a pattern in literature since Aristotle's time. Many of the aspects are repeated again and again in plays, stories and films. This is an early Design Pattern.

How is it then that when I interview people for Software Engineering roles, some have barely heard of design patterns. Many can only name Singleton, and few can simply state the basic idea that these Design Patterns are simply well known ways of solving problems. They are solutions that work well, are easy to maintain and have good properties in terms of specific criteria, which may be, for example, performance, dependencies or maintainability.

I'd expect any engineer with a lot of experience to at least know about a façade and a decorator, and be able to explain why a factory class is more than just a "place to put constructors together". I'd expect them to know what a Strategy Pattern was, or a Command Pattern.

These are not the "current fad", they are high level, well known ways of doing things. They are not a magic bullet, they are simple basic knowledge.

Assuming that you can read and write to a basic standard, how would you begin to compare Hamlet and King Lear without an understanding of "The Tragic Hero" as a starting point.

Why are people dismissive of the whole idea?