The Business-IT-Gap has a face

With all the current hypes, just think about the Architecture, SOA and SaaS hype, you might think that agility, stability and interoperability are goals in itself. That they are specific magical ingredients recently discovered about to solve all IT related problems. This would not be an unlogical conclusion. After all, that's what is being promised you will need and get an agile business because that is what everybody needs.


Is it not? No, not at all!

In fact you just met the "Business-IT-Gap" in person. It might be the manager asking a developer for an application that should (obviously) be flexible and stable. Or it might be a sales person or consultant explaining a client that they really need to go for a SOA-solution for agility reasons. Either way you are actually physically facing a (e.g.: talking/listening to) person embodying the Business-IT-Gap.


Really? Explain!

The whole reason why the Business-IT-Gap exists is because managers have lacked to provide enough guidance about what kind of flexibility and interopability and the dagree of stability is that was needed (a responsibility now being hijacked by people calling themselves Architects).


Lacking this guidance resulted in systems lacking flexibility or the wrong kind of flexibility (thus maintainability) and interoperability. Moreover, because every developer has its own personal view on the type of flexibility needed, changes are that what is flexible in one application is fixed in another. Thus in fact lacking this guidance cannibalized the overall investments in flexibility. Believe me this is not theoretically speaking, this is what I see day in and out! I can't believe nobody else notices this...


So what should I do?

Of course, it's not only you. It's the whole branch! Developers should demand more guidance. Sales people and consultants should not propagate agility, interoperability and stability etc. "pur sang". They should explain that it is about Just Enough and about Just Right and that divers from situation to situation and company to company. You just can't and don't want to be totally agile either given a solution or given an total enterprise. It's about finding the right balance between what can be fixed and what should be flexible. Because flexibility comes with a big cost that can only be returned (roi) if it will be used sooner or later. Just think about architecting a house. Realizing all your dreams and whishes (read: requirements) in a totally agile structure would have you end up with something crazy like a hyper expensive stretchable balloon!

But now that you know, you can and should close the gap by asking the right questions and demanding a reasonable answer!


Happy closing the gap!

Compare Assemblies (ALM)

To get your build and release procedures right you need to know and inform about what has been changed in this release compared to the last (major)release.

As far as I know there are three tools that can be used to compare assembly versions:

• Microsoft's LibCheck which might be incorporated into your build server to have a document generated with your release that lists all the differences; This application outputs a xml-file with the differences;
• For ad-hoc investigation you should you ndepend;
• For simplicity you might use the free opensource Framework Design Studio; Which can also be incorperated into your build server using the "fxdiff.exe" found in the install folder. This application gives you a visual SourceSafe-like comparison.

I recommend using nDepend today! If you are not using it allready.

Happy comparing!

P.S. If you can't find the download for the Framework Design Studio click here.

Defensive Programming (Spec#, DotNet)

Do you apply Defensive Progamming techniques?

Based on my experience, changes are good that you are not.
If so you may be missing out on many benefits such as:

• Producing easier to use, understand, and maintain class-libraries;
• Havinging applications that are much easier to support and test;
• And last but not least, having more secure code.
  

In other words: defensive programming makes your solutions more easy from many viewpoints. Which, to me, in itself is a goal.


So what is this defensing technique about?

Defensing is a concept that has many aspects to it (see WikiPedia here) but in this article I will focus on the ensuring that the so called "pre-conditions" are met instead of assuming they will be met.

I am sure you know what I am talking about we have to deal with this every day all of the time! Just think about all those function parameters that might have an invalid value when that function is being called. That integer parameter* that should not be zero or negative or that object-reference parameter that just should not be null for example. With defensing you always check those pre-conditions first and immediately throw an exception if one of them is not met.

In any application there are thousands of those "pre-conditions" that could and should be checked. Sure that sounds like lot but in fact when you do it from the start it is hardly any extra work and you start enjoying the benefits almost immediately returns your small investment . And with the help of a small (existing) library the equation is even more interesting! Let me explain what I mean:

• For anybody, including yourself after a while, maintaining your code it is immediately crystal clear what your function cannot do or handle! In many cases there is no need to test if this new situation is supported, anymore;

• If one of your methods is called with an invalid value a clear exception is thrown immediately. No more “Null Reference Exceptions”, for example, deeper in your library that are all too hard to trace! Which is only possible by developers nothing to do for the support department, over and over again.

• Many security issues originate from an unforeseen use of an application or library. By making sure that all your, assumed ,preconditions are checked it becomes much less likely to have your methods begin misused.

Should I really use this? It sound like a lot of work!

Sure it sounds like it, but when you do this right this is certainly one of those so called "Low Hanging Fruits". Quick wins with huge benefits. If you would ask me just do it! Apply from the start of a new project or add when changing a function that already exists. A good programmer is a lazy programmer so make defensing more easy for yourself using Macro's, Tooling and a small library of perhaps extention methods!?


Oke, I am convinced! What do I need to do to start defensing, Today?

One of the first things we need to do is have a library that helps us easily check parameter values and throw the appropriate clear exceptions. You basically have three options here:

• One option is of course to write your own; This has the benefit that the exceptions that you fully control the messages and types of exceptions that are thrown;

• Another option is to use the assertion classes from any Unit Tests framework. The, architectural, downside to this is that you are using Unit Test classes and libraries in a production environment. Conceptually this is not wrong but as far as I know there are no practical downsides.

• The last, certainly not the least, option is to use the upcoming, but already available, Spec# framework from the Microsoft Research department. Which has the huge benefit of having a framework specifically for this use on one side which comes with integrated Visual Studio support as well!

Spec# sounds really interesting! Where can I find more?

I will soon write an introductionairy article about this, so stay tuned!


How do you look at Defensing from an architectural point of view?

Architecture is about how things relate and about meeting stakeholder stakes:

• The library classes that help to make your defensing easy should be part of your Core;

• The information about the valid and invalid use of your methods should be part of your technical (generated) documentation. This is something, spec# nor sandcastle or nDoc, does not yet take into account but possibly could.

• Defensing makes your class-libraries more easy to use, to maintain, to support and more secure. This is someting that should be in the interest of every stakeholder but in particular to the CTO and ICT (support)Managers.

We have been talking about defensing, but can’t I just see what it looks like?

Sure thing! To wrap things up I have included some examples below using my own practical little defensing framework. After all, we should not talk too much about coding, coding is something that you “just” should do!

public void example1(object parameter)

{
Defence.Object.MustNotBeNull(parameter);
…
}

protected void example2(object valueToAdd)
{
Defence.Boolean.ShouldBeFalse(_collection.IsReadOnly );
…
}

Does not look difficult does it? I told you so! The best things in live are the simple things...

Happy Defensing!

----

*) I know we might use an Unsigned Integer here, but this is not CLS-Complient thus in many not recommended to be used.

Succesvol software ontwikkelen (Agile)

Slechts sporadisch kom je een boek tegen dat zo praktisch en zo realistisch beschrijft hoe je succesvol software zou kunnen ontwikkelen dat je niet kan begrijpen dat dit niet veel eerder bestond.

Dit is dus ook het geval met het boek "Getting Real". Hierin staat dit op een werkelijk fantastische manier in 16 actiegerichte hoofdstukken beschreven.

Voor iedereen die met softwareontwikkeling te maken heeft een echte aanrader en voor iedereen die ambities heeft een eigen softwarebedrijfje te beginnen een absolute must!

Het boek is volledig publiekelijk beschikbaar. Zie: 37signals.com

(Bedankt voor de tip Gerard Doeswijk)