Four Bits Worth of Dev Advice

Inspired mainly by 2 talks I saw at the JAOO 2008 conference (Kevlin Henney: Programmers Dozen, and Kevlin Henney and Frank Buschmann: 5 Design Considerations) I've put together list of advice for programmers. Such a list could obviously go on and on and on, but the exercise here is to choose the advice that I find most important, and that I see violated time and time again. So I decided to only allow as many pieces of advice as can be enumerated in 4 bits. And here's the raw, unexplained list:

0000: No bool to bool conversion
0001: Trust the implementation
0010: Declarative over imperative
0011: Beware of vampires
0100: Consider infrastructure orientation
0101: Use role based interfaces
0110: Be economic
0111: Prefer code over comments
1000: Use symmetric interfaces
1001: Use one abstraction level per method
1010: Grow guts
1011: Prefer use over reuse
1100: Write change friendly code
1101: Dry
1110: Don’t stay stuck
1111: Be curious

Most, but not all of these appeared in the two talks mentioned above.

I will be posting about all of the pieces of advice in the near future ([2], [3], [4]).

Exploring a WPF Business Application Architecture 4

I've finally gotten around to starting coding up a little GUI for my little petshop sample. It follows the MVVM pattern. After doing just a couple of windows it's clear that any GUI implemented using MVVM will have a lot of view models and a lot of commands. So where should I put all those classes in terms of folders? I see two possibilities:

1. Put all the view models in one folder, and all the commands in another folder. There might be more structure below these folders.
2. Put each view in a separate folder and put the view models and commands belonging to the view in the same folder.

As to what works out best...I'm on the fence...

Refactoring vs. Re-architecting

I was recently gave a talk about refactoring. Beforehand I was asked to include something about "refactoring on a small scale" and "refactoring on a large scale". And how the two compare. I sort of just accepted that at first, but while preparing the talk I realised that "refactoring on a large scale" doesn't really make a lot of sense: Refactoring is about doing code changes that enhances readability, but doesn't change the observable behaviour of the software. That works out really well for localized changes such as extracting a method, renaming something, extracting an interface etc. But large scale changes (like splitting a single-process-application into several processes working together or moving from a voluntary scheduling scheme to a preemptive scheme) are very different beasts. Such changes aren't just large scale refactorings, they are re-architectings, and very different rules apply to the two.

Contrasting refactoring and re-architecting

To contrast the two let me list some important characteristics of refactoring:

• Observable behaviour is not changed
• The goal is to improve readability
• Refactoring is pretty safe when you have good unit tests around the refactored code
• Refactoring should be applied in an incremental fashion as a series of small steps
• Refactoring can usually be done pretty quickly. I.e. the cost is low.
• Refactoring helps keep the code base clean, which in turn helps keep the team velocity up (this is the real motivation for refactoring)

By contrast I find the following to be some of the important characteristics of re-architecting:

• Re-architecting is usually done to improve one or more non-functional aspects, such as performance, scalability, availability, etc.
• Re-architecting thus changes the observable behaviour
• Re-architecting can't practically be done through a series of small steps. It must be done in a couple of big steps followed by a long series of small (refactoring) steps
• The big steps are risky
• The big steps are expensive/time consuming
• Unit tests don't offer much help when doing the big steps
• Re-architecting requires all levels of tests to be successful (integration, system, functional, non-functional, automated, manual)

To conclude I think that re-architecting is risky business that should only be done after thorough analysis of the cost vs. the benefit of doing the re-architecting. It's not "just" refactoring on a larger scale. That makes it sound too easy.