I have to admit first that my first idea about this article was going to me a rant about how TDD goes well beyond what design by contract gives as I felt Bertrand Meyer in computer magazine dated August 2008 missed that point. Then I thought better of it and checked for resources through google and discovered that I am late to the party with at least three very intersting articles on thus very subject: DbC and Testing, more on TDD vs Design by Contract and Test Driven Development and design by contract, friend or foe. On the other hand I did not find a tool that was satifsfying to link TDD and DbC (don’t you love acronyms ?). So here is my attempt at a story describing what I would like.

Let’s imagine the following scenario. I need to write the function f of a service S.

That function will take an id and a number as input, find an object responding to interface O from a cache responding to interface C.

In a TDD manner I start writing the test. Discover in the process that S needs to know about a C. Stubs a C for the purpose of returning an O to my service. There I specify that the contract of the find message of C is that the passed id is not null, it returns a non null O or throws a NotFound exception.

Now I would like that the calls to the C stub would verify that contract to ensure I am testing in accordance to the contract. This way if the contract changes in a way that is incompatible with my assumptions, my test will break and signal the problem.

I would further like the contracts to be verified automatically against the instances of implementations of C throughout my development cycle. And I would like to be able to selectively keep the contract enforcement in my deployed product.

The net result is not to get rid of the defensive programming but to move it into a well defined area as a specific concern that crosscuts my software. I would even have the choice to test whether the contracts actually specify what I intended. It would also remove the necessity to test the defensive programming code in the same artefact as the functional code.

Why all that ? Because TDD, beyond creating regression test artefacts also is a way to specify the component being created and that therefore it would be nice to be able to capture in separate, executable artefacts the implied specifications made on the related components.

Anyone knows about such a tool ? Anyone wants to write it ? Am I crazy ?

Or How thorough QA can lead to lower quality ?

Indeed this is a paradox but it appeared very clearly to me after observing a change in the QA style in our team. Before this realisation I would have happily argued that thorough QA is the best thing that can happen to a project. The paradox unfolds in three parts.

Firstly it makes it harder (and more importantly longer) to finish stories. I understand that it also avoids accepting low quality work. However the QA perspective is slightly different (and this is good) from an actual user’s. So thorough QA, uncovers plenty of minor problems that do not significantly impact user experience or that would be minor production issues. This generates frivolous work that delays the development of more important stories, bug fixes or refactoring, thereby reducing the overall quality of the product.

Second, after a while the QA style modifies the developer’s attitude. When QA is thorough there is a sense of false confidence in the QA process that generates sub par unit and integration tests. This in turns leads to more bugs. Also, when QA is too picky before accepting a story, it removes one of the incentives to write well tested code because the difference in terms of the time it takes to close a story with good tests or not is marginally different. This effect in general is all about removing quality ownership from the development team and transfer it to the QA function.

Lastly the combined effect of the first two is that velocity falls, the project gets behind, people (well mostly managers) get nervous and start sending the message that quality is not important. The first signal is to encourage QA to log a bug but pass the story. The second signal is to de-prioritise existing bugs, effectively ignoring them (as we all know bugs underneath a given critically are never fixed and fall into the priority blackhole).

And there you have the QA paradox. Does this resonate with your own experience ?

This is supposed to be a very flammable article so please light the fire. I attended two talks by Linda Rising one at a Bay Area Agile Leadership meeting, the other at QCon. That added to some other readings fueled the thoughts in that post.

I believe that all humans are naturally driven to perfection. It is the way the human brain works, using pattern and simplifications to accelerate reasoning. When people imagine something it is always perfect. At least initially. Or ideal. It is really unfortunate that many of us realized very early that real things are not perfect. Some may argue that this is the source of the religious fact but I am neither a theologian nor a philosopher.

Working with people, knowing that they are not driving for perfection proves beyond any doubt that they are not motivated and committed. I am not saying it is wrong, I think at some point everybody will stop believing and will try to find something different in which to project their drive.

Now, in many agile talks you hear people saying that one of the founding principles of agility is to abandon the idea that you can make a perfect product in favor of a reasonably good target. This however is only a half truth. It is true that you need to realize that the finished product will be the results of trades off, compromises and misunderstanding because that influences how you are doing things. On the other hand, Kaizen, continuous improvement of the process and the product are all signs of the drive for perfection. The proof ? No one gives the termination condition of these iterations. The termination will always be arbitrary. In other words, it is almost impossible to give a definition of good enough until you see it.

I would further contend that for each item of work, a motivated individual will always do as good as he can. Never good enough.

What are the implications of this for agility ? One is that I think it explains why there is not strong competition among agile team members. To compete you want to do things better than the other team members. If you are trying to do things perfectly you will ask all the help you can. Is this what keeps agile teams motivated or is it a result of the motivation ? I think it is a self-sustaining feedback loop (or something like that). Command and control typically does not achieve that because it is much harder to keep people motivated in that kind of environment which means that sooner rather than later workers will shift their perfectionist mind to other subjects.

I will finish this article with a saying ‘Better is the enemy of good’ which essentially means that you never achieve good if you are aiming for better. I would add that to achieve good you have to aim for perfect.

This is not a summary of Jay Fields’ talk but mostly the thoughts it inspired me.

To make it clear, in Martin Fowler’s nomenclature, Business Natural Languages are external Domain Specific Languages. That being said, they tie pretty neatly with the major principle of software development that you should establish a common language between the parties involved in a project (which, in the context of QCon is a tenet of Domain Driven Design).

Anyway, the basic principle is that you create a language that is close to natural language but applies only in a specific context in the business and you create a user interface from it. This is the grand rediscovery of text based interfaces, which many of us know are much more efficient than graphical user interfaces in many cases. The example that specifically spring to my mind is Summit System’s quick entry for some trades that applied that exact principle by enabling the users to use their terse business language, the very same one they use on the phone all the time.

I would go a step further. Defining that language probably is a very useful step in the design of a graphical user interface. Because to be natural and easy to use, the graphical user interface should embody that business’ language.

I can see a few obvious examples of when this kind of textual interface can be very efficient. One case:

• A part of the business that would lead to a fairly complex dialog box with plenty of optional fields,
• That is not constantly and repeatedly used (until there are efficient embeddable language workbenches).

The other (as illustrated in the previous example):

• A terse syntax already exists in the business that would make even a simple GUI clunky (for instance because selection from list is too long).

It could also be very useful to program query in a less formal setting, like processing e-mail business queries in a partially automated fashion.

Jay Fields used regular expressions to create his BNL languages. However, outside the context of his projects, I feel that using formal grammars and tools (like lex/yacc, antlr or similar) would make the language easier to maintain and enrich.

A final point that was stressed during the presentation is that such languages should be very simple and specific to an area of the business. Remember that computer understanding of natural languages in general is a very complex problem.

This is by no means a summary of Eric Evans’ talk, only my main take away and some thoughts it triggered.

I have to admit that the term Domain Driven Design was a bit fuzzy and this talk did a good job at clarifying what it means. Essentially it means that when you build software you effectively build a domain model as well (whether implicit or explicit) and that you should pay attention to that.

In particular, the domain model you build is partial on the domain itself. It reflects some of the views you (and hopefully) your users, take on the domain. It serves the specific purpose of building a shared representation of the domain with your users. All that circled back neatly with agile and embedding the customer and all those good things.

Also I cannot pass over the row boat analogy through which Eric Evans helps explain why agility works more easily on small teams (he noted that boats have a maximum of eight rowers, in part because rowing requires perfect synchronization and that a single miss by one of the rowers throws everybody off rhythm). I would add a few notes to that. It is interested to note that boats of two and four are self organized whereas for eight someone needs to call the cadence. I would also like to reflect that it does not mean that boats of more than eight cannot exist (see the antiquity’s galleys). Just that to make them faster than eight will require a lot of training and that it may be difficult to assemble the individuals that fit together and that it may require more non rowing team members (who thought dead weight ?).

There was another greatly useful analogy with athletic relays which illustrated one pitfall of over engineering system interfaces but it would be too long to explain here.  The core of it is that you should engineer an interface that the other system will be able to handle reliably. If it is a csv file exchange then so be it.

Anyway, a final point before the presentation was interrupted by a fire alarm, was that there will always be multiple models of the same domain. That these models are more or less compatible and that you may need to translate between them. As it is, I have first hand experience in that with FpML, Calypso and others and I will add this, if you need to translate your model into another, make sure they are not too different or it will cost you a lot of time and effort which is exactly what you are trying to reduce by defining your domain specific model.

What is the link with strategic design in all that ? Well the premise that not all of a large system will be well designed. Therefore make your domain model explicit helps focus on the core of the system. If peripheral parts of the system are not as well designed, it is not so important.

Here we go. I have now been working on digitalbrikes for almost two months. That is a bit more than I would have liked in terms of time to market.

Granted I was not spending my fulltime on it and I got distracted by the birth of my second daughter. And also I have to accept that design (as you may have noticed by now) does not come to me naturally, even with the help of a recently acquired book on which I will comment more in my next post. Yet I am pretty happy with the result as my first shot. I can confirm that for me customizing wordpress themes is still a terrible pain. I hope it will get better as I continue to refine the look of this blog. Unless one of you dear (imaginary ?) readers convinces me this design is not worth anything and I short restart from scratch.

Up until now this has been a very useful and entertaining exercise but now is the time to go live. I intend to publish at least one post a week, possibly less during vacations, hopefully more but I don’t really imagine having the time for more.

Next post: White Space in my Software.