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?

Unit Tests, Code Quality and Legacy Code

Some days you start adding unit tests to legacy code. Perhaps you are about to make some changes, and you'd like to be sure you don't break something else.

In your Test Setup, you find that first you need to set this, and you need to call that, and you need to make sure this data is set, and so on.

There's a number of problems here, but the one that I'm looking at in particular is that as you continue to try to get your tests to run, you find more and more prerequisites.

Suddenly your Test Setup is starting to get a little out of hand.

This comes down to code quality.

What is good quality code? It's fairly complex to define. As you try to add a "second client" to a given class, you find out if it's easy to have someone else use the code or not. In this case our second client is the Unit Tests.

Fair enough, if the code is doing something complex, there may be a lot of setup, but there are two problems here.

• It's not clear what setup is required.
• Perhaps the code should not be doing something so complex.

Of course TDD gets around this by writing the tests first, and many of the things that we consider "good quality" come from the constraints that Unit Testing forces on you.

In this same way, unit testing make code reviews more practical. Now you have a Clearer Metric for good code. If the code can't be tested, it's a good hint that the code is not Good Code.

Before Structured Unit Tests, you had the pantomime code reviews -

• "that functions too long", 
• "oh no it's not", 
• "oh yes it is" 

Now it's simpler

• "that functions too long", 
• "oh no it's not", 
• "How come it's got no unit tests"
• "it's doing too many thing to test"
• "so it's to long then"
• "yes, I guess so"

A lot of the Code Quality which people used to call subjective, now has a practical metric. If it's hard to write unit tests for, then the code's not good code.