Why software models matter

The control software for The Large Hadron Collider (LHC) experiment at the European Organization for Nuclear Research (CERN) was developed by a group of people that more than likely know a thing or two about software development (http://news.thomasnet.com/companystory/CERN-Chooses-Coverity-to-Ensure-Accuracy-of-Large-Hadron-Collider-Software-602630 , http://www.slac.stanford.edu/econf/C0303241/proc/papers/TUJP001.PDF, ). You typically don't let the control of a particle accelerator up to some first year students as part of their VB class. The following still clearly demonstrates that even experienced software developers need tools to analyze and verify the behavior of large, complex, systems: http://mcrl2.org/release/user_manual/showcases/CMS.html

Design by Contract

I am currently working on implementing code contracts and code analysis for a project. Some developers have been giving quite a bit of push back though, requesting test driven development and unit testing. By itself I am supportive of test driven development since I feel it is still a more pragmatic solution than code contracts and code analysis. The tooling for code analysis is still maturing and I noted the cautious wording around static analysis in the latest release of code contracts. Rightfully so since we know that a machine checking the correctness of an other machine gets us in to NP-complete problems.

However, as noted by Dijkstra, testing can never proof the absence of bugs, it can only proof the presence of bugs. Testing is more or less the same as looking for a counter example: you only need one counter example to refute a proof (http://www.amazon.com/Proofs-Refutations-Logic-Mathematical-Discovery/dp/0521290384/ref=sr_1_1?ie=UTF8&qid=1333823887&sr=8-1). The same holds for test driven development (TDD): unit testing will never proof that you met a requirement, it will only demonstrate that you did not meet a requirement. In case of the inclusion in your test path of blackbox components that do not have proven deterministic behavior (and that occurs more often than you might think), the test only reflects the outcome for that single run, but does not give any kind of indication for future runs (in which case you need repeated samples to provide a statistical confidence level that the requirement has been met). Test driven development also requires significant effort: since the test is first, there is no tooling that can help you derive the tests. And the argument of high code coverage through test driven development is somewhat flawed, since I have seen many developers focus on 'positive paths' as described in the requirements. 

As mentioned in the following article http://leansoftwareengineering.com/2007/04/24/start-with-something-simple/ ,  TDD can be considered DbC for dummies and DbC is formal specification for dummies. I like DbC better than TDD, since TDD is looking for a counter example, where DbC actually focuses on defining the contracts. DbC also offers the potential for tooling to automatically derive test cases (Pex for example) and automatically checking for contract violations. 

So step up on the evolutionary ladder of dummies to DbC and keep TDD as a complementary approach.

WCF behind a load balancer

If you have an issue with the wrong address in the WSDL of a WCF .NET 3.5 SP1 service that runs behind a load balancer, look at

http://support.microsoft.com/kb/971842

Hope that saves you the time of writing a custom behavior to change the WSDL :).

Another case for code contracts

I stumbled upon one of the many articles on inversion of control (IoC). Interesting enough, one of the arguments the author used for utilizing interfaces was that it enabled you to safely change the actual implementation of the interface later on. I have to disagree on that point. In fact, in some way I think that depending upon a specific class rather than an interface is more 'honest'. Not saying that you shouldn't use interfaces: interfaces, combined with IoC,  are very useful. One issue I have with many interfaces is that they are not defined in terms of pre-conditions, post-conditions and invariants. Without a contract you can still only guess what the interface provides to you. If you rely upon a specific class, you at least recognize that you are dependent upon the implementation details of that class. When you rely upon an interface without a contract, you are basically saying "I rely upon an interface that has no clear specification, but I trust anyone that implements it not to violate my interpretation of the interface." Code contracts are crucial for well defined interfaces.

On a related note: during the "meet the experts" session at the Windows Build conference I talked to some Microsoft employees about model checking. Their first reaction was, with a somewhat surprised look: "Do you develop driver software?" My answer was "Nope", but it was a clear indication that formal methods are still only generally accepted in very small pockets of our industry. Maybe over the next couple of years Microsoft will finally be able to make some of these formal methods readily available to all programmers.

Back to basics

One of the projects that I work on involves customization and modification of an existing system. The original system was however not architected for change. Beyond the rather long list of architectural and implementation issues that surround the system, one of my colleagues noted that the system was really a world by itself. This brought me back to the thought that larger systems have organic aspects to them.

In the end, simple organisms are favored above complex organisms when disaster strikes. Cockroaches are for example more likely to survive nuclear holocaust than humans. Are simple applications more likely to do well in a changing environment? I have lately been leaning strongly toward limiting custom frameworks and not 'over architecting' applications. The closer you can stay to mainstream constructs that you can expect any programmer to know, the better. As part of the 'less is more' strategy, I have for example ensured that the interaction with Windows Identity Foundation is completely transpartent to the programmer. We have also started to refocus on basic concepts, like encapsulation, contracts and decoupling and making the developer aware of these concepts in an intuitive way through the IDE. I understand why the industry aspires to extreme test driven continuous integrated agile development :), but I also don't want to loose sight of the basics.

Code Contracts and more ...

There is so much fun to be had and so little time. A list of some of the areas I have been working on (some professionally, some for my own fun):

• Code Contracts: A Microsoft Research project that brings pre- and post-conditions and invariants to .NET. Although I understand the limitations, I have been very impressed with the capabilities it brings to the table. For example: after adding code contracts to existing code, the suggestion was to add a restriction on the size (at least 20) for an input parameter of type string. Rather odd requirement, which turned out to be the consequence of some substring calls inside the method in question. Obviously it was time to weaken the pre-condition. I can deeply appreciate a tool capable of pointing these issues out.
• PEX: Yet another Microsoft Research project that brings automated whitebox testing with high code coverage to .NET. In combination with code contracts, it rocks. You will never have any excuse for an 'object is null' error again.
• Kinect for Windows 7: Yet another other Microsoft Research project bringing the Kinect to Windows. What else can I say, NUI is finally available for the masses and the way we interact with machines has changed for the better.
• Windows 8 METRO applications: After my visit to the BUILD conference, I have been trying to keep the momentum going and get more familiar with the new Windows 8 METRO applications.

Ofcourse I still have actual projects going on and fun questions to answer like for example 'What does code quality mean to us?' Luckily Fall has finally kicked in and I have two additional hours a week available that are normally spent on mowing the lawn. That will make a big difference :).

Arduino ...

Been tinkering around with the Arduino boards. It is a blast! They are somewhat of a pain to interface with, but it's been good to learn in detail about bluetooth profiles and wiring :). You can do some wild stuff with these boards, so go and have fun: figure out how to open your garage door from your Android or change tv channels from your laptop.