The Three Stages of Software Design Evolution

I have had a number of conversations lately with different people on the subject of assessing job candidate competency. This is a really hard thing to do in an interview. One of the main reasons is that the stress of the interview can seriously detract from the candidate performance.

A colleague asked me how I would assess the levels of competency for a developer and after some thought I came up with a few distinctive levels:

JFDI: Hack, Ship, Hope

Now we are talking here about the 'design' element of the process. You can hack code in a well designed component or a poorly designed one. The choices you make on your first attempt will determine whether when you need to change the code whether you can iteratively change it or it has to be replaced.

Startup developer teams often end up building components that are thrown away. This is usually because they didn't fully understand the requirements. This is kind of a special case. Startups are supposed to solve problems for which the answer is not known aren't they? (Well supposedly).

At this level code review may not pick up on the design decisions being made (or lack of design) during individual diffs. 

Ask a Friend

In reality most software developers have discovered Google search by the time they graduate. The even more socially adept may have also discovered the joy of getting help on Quora and StackOverflow. The tricky thing is that once you are in an professional role you often can't reveal too much about what you are working on.

There are a few different activities to look for:

• Searching the internal repos for a working solution (yes code can be re-used).
• Internal forum activity.
• Engaging a more experienced engineer. We all need coffee breaks.
• Finding the coding standard for your team and seeing what the normal design pattern usage is.

Defining Norms

Once a developer has started to get feedback on designs there is a natural tendency to share the decision. This may be as part of a show and tell or a wider presentation. These sorts of activity will drastically improve the efficiency of not only the developer solving the problem but the reset of the team by sparking ideas and understanding.

The nirvana of defining 'the way we work' is upon us. One of the most debilitating challenges facing any developer sitting at their keyboard:

The past, like the future, is indefinite and exists only as a spectrum of possibilities. - Stephen Hawking

There can at times simply be too many possible ways to solve a problem. Design patterns can help but they some times contradict each other. In order to be able to 'get things done' some times the best thing can be to have a standard way which means you can get started then discover along the way the problems you still don't know about. This idea works well with the concept of tracer code.

Defining Exceptions

Clearly the goal of defining a norm like how should a problem be solved should include the counter cases. If the goal of defining ways of working the challenge here is to understand where a library, tool or process doesn't apply.

How many times have you seen hadoop map reduce used to solve problems exactly matching the documented counter cases? 

Some framework take this "when you have a hammer everything looks like a nail" philosophy to the limit. 

In a startup context you can also find that you come full circle and use the wrong tool simply because you have to get something done. The reversibility design pattern is your friend. Apply liberally.