Michael C. Feathers: Seven Blind Alleys in Software Design

August 25, 2009 | 3 Minute Read
This post was originally posted on my old blog.

Michael Feathers (author of Working Effectively with Legacy Code) gave an interesting talk at the Norwegian Developer Conference:

Seven Blind Alleys in Software Design.

The video of the talk can be found on this page.

Here is a short transcript of the seven dead alleys he identified:

1. Programming in Pictures

This has been a pipe-dream for years and years in the software industry.

"Anybody remember MDA?" (note the notion of the past ;-)

Some complexity is irreducible.

Pictures are not necessary better than words!

Word language symbolism vs. letter language symbolism. Thats the options we have, regardless if visual or textual.

Where are the real systems?

Think about the edge-cases.

2. Metaprogramming

A result from the notion that it is hard to change code.

The promise is that it is easier to change data that represents things in the code.

We have to remember that code is data anyway.

Flexiblity vs. Understandability

Complexity is not reduced with flexibility.

Its hard to figure out what's going on in production.

3. The Ultimate Abstraction

It always just seems one step away.

Believing in perfection

People don't want to make compromises

Programmers are abstraction junkies

Striving for the grand unified theory

Indicator: attempt to unify one and many

Deadlines and budgets help

4. The perfect taxonomy

Do not try to create it upfront. Let it evolve and hope that it eventually will become stable.

Do not generalize too early -> failed framework projects.

Abstractions just have to be good enough not perfect.

English is ambiguous, programming ought not to be.

5. Modeling the real world

Software is really different, it is subject to tighter constraints than the real word

If we can borrow concepts from the domain for our code, then that is great, but we don't have to.

Behavior is key. We can't always find a metaphor. We don't have to be limited by the concepts in the domain. We can make stuff up.

Why would you want to model the real world, thats where the problems are!

Classical example: Liskov substitution princple (Square/Rectangle)

6. Code generation

Accept: You are never going to be complete! Don't be ambitious!

Traps! Can be shaping the code in bad ways.

Effect: De-skilling development

Encodes advanced knowledge of the domain which is likely to be wrong - workarounds are inevitable and get even the norm the older the system gets

Cruft buckets - Places where developers are forced to put their code. No design freedom possibe! Complexity cannot be tackled!

7. Natural Languages

Business people are never going to be able to program - even in plain english

Programming is always going to be more constrained than plain english is

English seems easier, it does read better, but you have to think like a programmer!

I can't say that I always agree, but this presentation really allows you to take a step back and reflect. Michael addresses a lot of current and reoccurring hypes, and lets us remeber that there is no silver bullet.