Even my grandma knows why unit tests are just ***cool***.

The primary goal of unit testing is to take the smallest piece of testable software in the application, isolate it from the remainder of the code, and determine whether it behaves exactly as you expect. Each unit is tested separately before integrating them into modules to test the interfaces between modules. Unit testing has proven its value in that a large percentage of defects are identified during its use.

If even my grandma knows, how come that there are still developers down there in their cave or under their piece of rock that still need to be convinced that unit testing is more than beneficial?

1. they are not true believers. They are convinced that writing god classes is just okay.
2. they have writers block and have no idea where and how to start writing good unit tests.
3. they are residing in an anti-pattern: no unit tests.

Of course, it is easy to create some for newly created code. (Although the reality often proves otherwise.) Real ***black belt*** unit testers also unit test all legacy code!

Nope, this post is on burn down charts.

In Scrum you have two kind of burn downs, the release burn down and the sprint burn downs.

An important feature of burn downs is that they should burn ***down*** as time goes by.

Sometimes, this is not the case, especially with the sprint burn downs.

In that case, we have a flat liner.

I was brain storming how something like this could happen and the following possibilities bubbled up in my mind:

• bad administration?
• feature or task creep?
• bad planning?
• gold plating?
• holiday season?
• all above?

Then, it suddenly hit me: lack of discipline!

It is not the fault of the Product Owner. The Scrum Team just needs discipline and the Scrum Master has to enforce that discipline. Problem solved.

Both aggregation and composition are special kinds of associations. They are used to represent ownership or a whole/part relationship.

But when should you use them? I am always confused and I have difficulties to remember which one to use when.

It is pretty simple though, composition is just a stronger relationship than aggregation.

An example will probably help. Henk and his brain have a composite relationship. If you destroy Henk, his brain will be non functional too. In fact, it is already pretty non functional since I have a hard time remember this composite relationship thing, but that is besides the point I am trying to make here.

On the other side, Henk and his blog have an aggregate relationship. If you destroy Henk, then his blog will survive. You could also call this a kind of stand-alone composite relationship.

Only we need now is a kind of mnemonic reminder!

Unfortunately, I cannot think of one…

maybe we should modernize our architecture and use a MVC design pattern, that is cool!

I would like you to remind that: MVC was first described in 1979… So, it is even more ancient than MFC, which was initially released in 1992!

For WPF, we nowadays have MVVM as a more “sophisticated” version of this ancient pattern. In its essence, you have decoupled model(s) and views. The glue between them is the ViewModel, often mentioned as a converter on steroids.

Sounds as good architectural thinking, but remember to put on your pink WPF glasses: it all fits in the presentation layer – except the model.

But what is a model, anyway? It is the same as a data model?

Not necessarily. It resembles more a simplistic view on separation of presentation from the rest of the application logic.

What is great about this pattern is its simplicity after you mastered its steep learning curve. It is worth doing it.

It has, however, one insuperable impediment: it is a dead open source project way beyond all resurrection boundaries.

In deep secrecy I tried different other UML tools, including Enterprise Architect (EA), MagicDraw and (even) ArgoUML. For a very long time the best candidate was Poseidon for UML, but I found it to Javaish and Eclipsy. That is not my cup of tea.

For some time I work with EA now. It has rich UML functionality, but I am not pleased with its lack of user-friendliness. It possibly works better for laaaarge modelling teams, where you need heavy versioning. I just like to create simple drawings.

And now there is: Software Ideas Modeler

I have some good news, and some bad….

Good news is: so far, so good. Looks like a promising UML modelling tool.

The bad news is: StarUML probably is exit now. Going to miss you.

One of many valuable things I learned is that you have to eliminate waste that does not add customer value.

C# Design Patterns Top Posts

1. Chain of Responsibility
2. Factory Method
3. Abstract Factory
4. Interpreter
5. State

Other Category Top Posts

1. Data Access Object design pattern in .NET
2. Validation Framework – Enterprise Library Validation Block
3. HTML4 will kill Silverlight, WPF and – in the end – even MFC
4. O/R mapping – from Database Record to Entity Class
5. Validation with Unity

What if I applied some lean principles to my blog?

Refactoring is “a disciplined way to restructure code”, undertaken in order to improve some of the non-functional attributes of the software.

The problem with refactoring is that it is a nerdy thing. No non-technical person on earth will ever ask you: please, will you improve some non-functional attributes for me? Please?

It just will not happen!

You have to cloak it somehow in an urgent issue or some hot requirement. This, your customer will understand.

Your customer wants a modern GUI? In fact, she asks for refactoring.

Your customer complains about slowness of the software? Suggest refactoring!

However, never pro-actively suggest refactoring. People could think that you entered play time.

Microsoft is also committed to HTML5. Of course, they want to sell and push IE9.

Nevertheless, HTML5 probably will be the next hype killer technology. So, in the unlikely event that you can understand Dutch you should listen and see for your self in this podcast.

In fact, there are people that believe that HTML5 is so promising that it probably will blow Silverlight away soon. Thus, that means that Silverlight will be doomed. There are also people in this non virtual world who believe that Silverlight is WPF vNext, thus WPF will also be dead (soon). On first glance, you could think this is some kind of domino effect. A cascading delete, so to speak.

Lastly, there are also people that are afraid to abandon MFC because of this doom say. Why should we invest in new technology that is doomed to be dead in the (near) future. Sounds feasible, right?

MFC is about 20 years old. Can you believe that there are people who are afraid of abandon MFC? Can you believe that there are people that do not want to invest in new technology as young as WPF?

Yes, we can!

Maybe this sounds a little weird to the innovators and early adaptors amongst us, but not to the late majority and laggards (according to the innovation theory of Rogers). Laggards only will embrace new technology when they are forced to. That pops up a new question: how-to get inertia and laggards in motion.

Maybe we should investigate that in the near future!

It is so easy! The only thing you have to do is make sure that you don’t make the user have to think about it how to accomplish a certain task with your software. This maybe sound easy, but is very hard.

One problem is: when you are designing your software the answer is already in your mind. That makes you a biased thinker. You think that it is obvious to find your way in the software.

However, when you start with the right answer in mind, your have the wrong starting point for usability.

“Move the mouse to the left upper part of the screen.” If you give this instruction to a novice, you would not expect that the user lift up the mouse, moves it towards the monitor and touches the screen. However, some people with absolutely no experience with computers do that.

Another problem is: while developing functionality, we already have a certain not so novice user in mind.

We think ourselves that we have in mind a picture of a novice user, but in fact that is not completely true. We already know how to do the task, we find it easy to perform. Of course, we implemented it.

Therefore we cannot imagine someone who doesn’t. And to be honest, most of the times we just think that the user is plain stupid. However, your user is not stupid. Not at all. The user only is not used to your software, this footprint of your brain. People think differently. Users are not all nerds.

So, please think out-of-the-skull-cap and take your usability serious!