Gandalf the White (in CCD terms)

By reaching the final white CCD degree I put on my white wristband today. So, from now on I have to obey all the principles and practices that the previous CCD degrees comprise. That is quite challenging in my eyes, for I have to keep an eye on many aspects of the whole development process. But it is worth it! It is obvious that my code has become cleaner since I read Uncle Bob’s Clean Code which was the source for the CCD idea.

Regarding the title of this post, it really feels like being on the developer’s next evolution level. Many things have become clearer to me. As I wrote before, most of the clean code ideas are not new, but they are brought together and verbalised in a quite concise way now.

One of the main points of the CCD approach is the perpetual focusing on a subset of the CCD principles and practices, i.e. on the different CCD degrees. That means, although having reached the final degree and thus keeping in mind all principles and practices, one works on the “coloured” degrees with their specific focus again and again. This is because repetition is a good teacher. Additionally, the principles and practices are not fixed, they are changed or modified from time to time. For example, the degrees comprised rules at the beginning; these have merged into the principles and practices completely.

Definitely, I will follow this track!

The dotnet Cologne 2010

What an event! Round about 300 people met at the Holiday Inn – Am Stadtwald, Cologne. And I am sure, none of them regrets his participance.

Some of the sponsors were present with exhibition stands. For me, that was informative and useful; e.g. I took home some information about a WPF control collection which could help us to solve a problem we a currently facing in my company.

I really like these community conferences. The information given there are absolutely useful for the daily work for the speakers take their topics “from life”. Additionally, it is nice to share experiences with other participants.

dotnetCologne2010The dotnet Cologne this year was held on the occasion of the launch of Visual Studio 2010 and the .NET framework 4. So, the talks, which were organised in altogether 30 sessions and 4 tracks, more or less dealt with these two aspects. That was a quite condensed programme. Even the lunch break was used for sessions! I was this time mostly interested in parallel programming, code contracts, and some goodies of the new .NET framework.

As last year, the sessions were great due to the high expertise of the speakers! The whole conference gave you the feeling of bringing you to the technological state of the art.

What was the benefit at the end of the day? First contact to new technologies or a deeper insight into it, new programming techniques, hints for your daily work – just to name a few.

Of course, there was a raffle at the end of the conference. And you may guess right that I was one of the numerous winners – this time, it was a book.

Not only from my point of view, the conference was a great success. Thanks to the organisation team – absolutely well done (again)!

The CCD blues

Today, I started to work on the blue CCD degree. It is the 5th and last sectional one.

Thus, I currently focus on these principles and practices:

  • Principles
    • Architecture and Implementation do not overlap
    • Implementation reflects Architecture
    • YAGNI (you ain’t gonna need it)
  • Practices
    • Continuous Integration (Setup & Deployment)
    • Iterative Development
    • Component-oriented Development
    • Test First

Here, we find a perspective slightly apart from the mere coding. Principles and practices both point out in their own way the relation of design/architecture on the one hand and realisation/implementation (in terms of program code) on the other. Design/architecture may be regarded as being one abstraction level higher than realisation/implementation.

The principles make you keep an eye on the distinction between architecture and realisation. In my point of view, at least the component-oriented development practice can be seen as a result of the implementation reflects architecture principle.

Besides architecture, other aspects of the software development process are involved here. Iterative development and test first address specification: Tests can be regarded as some sort of specification; iterative development results from continuous specification refinement. Finally, continuous integrations reminds you to install an automated setup and deployment mechanism here.

Just to mention it: The YAGNI principle is quite important, so it is repeated within the blue degree.

In summary, this CCD degree focuses on the embedding of the coding part in other aspects of the software development process such as specification, deployment, and architecture.

The particularity of the Product Owner

In Scrum, the three roles Product Owner, Scrum Master, and Team are all important in their own way. In few words: The Product Owner is responsible for the project roadmap, i.e. he has to decide which features from the Product Backlog should be realised next depending on his prioritisation. The most important jobs for the Scrum Master are to keep the Scrum Process running, to protect the Team from impediments (or resolve them), and to act as a moderator. Last, but not least, the Team is responsible for the technical decisions and the accomplishment of the Sprint Goal.

But there is one thing that makes the Product Owner role quite particular for a project: The quality of the Product Backlog Items is crucial for the project progress. When put into the Selected Product Backlog of a Sprint, these items have to be worked on by the Team during the Sprint.

So, what happens if the items are of poor quality? And what do I mean by poor quality?

The description of a Product Backlog Item of poor quality is incomplete, ambiguous, unclear in such a way that the Team is not enabled to satisfy the Product Owner’s idea regarding that item. If such an item is part of the Sprint, it causes – in best case – a lot of unnecessary communication during the Sprint which as a result decreases the Team Speed. But normally, the effect is even worse. If the Team does not hit the Product Owner’s need, the delivered piece of software will not work as desired. Agile Processes often measure the project progress in terms of software features. Using this definition of project progress, there is no or slow progress in case the implemented features do not work as expected by the Product Owner!

To gain high quality Product Backlog Items, these are some basic demands on the Product Owner:

  • The Product Owner has to know what he wants.
  • Yet more important: He must be able to tell the Team what he wants.
  • Most important: The Product Owner must have an urgent need for high quality Product Backlog Items. He must feel the necessity for items of high quality; he must recognise that poor quality items hinder the project progress. So, it is in the Product Owner’s interest to have good items and in some way he should feel responsible for that.

The Product Owner does not need to be left alone with the task of producing high quality Product Backlog Items. The Team can help: It just has to insist on good or exact descriptions. Moreover, the definition of acceptance criteria is crucial. The Team may work with the Product Owner on their respective formulation (at best during Estimation Meetings). The goal of Estimation Meetings is to produce high quality Product Backlog Items. Furthermore, the Team can improve its knowledge of the business domain which in turn leads to Product Backlog Items of better quality. A ubiquitous language is quite helpful here.

So, for short and as a summary, in my eyes the Product Owner role is the most important one in Scrum with respect to the project progress. The Product Owner has to internalise the need for high quality Product Backlog Items. He must not be content with poor quality Items. He must recognise that the latter slow down the project progress. Together with the Team, the Product Owner can produce high quality Product Backlog Items.

Green is my current CCD degree

I have reached the upper half of the ladder. (I do not count the CCD black degree.)

Green is the 4th CCD degree and emphasises:

  • Principles
    • Open Closed Principle
    • Tell, don’t ask
    • Law of Demeter
  • Practices
    • Continuous Integration (Build & Test)
    • Static Code Analysis (Metrics)
    • Inversion of Control Container
    • Share experiences

The principles focus proper class design and lead to loose coupling. The same is true when making use of a container. Continuous integration and metrics increase productivity, for they check your software quality automatically. Once more, there are no rules at this degree.

I think I can rush through this degree, because I use these principles and practices (almost) every day. There is one exception: I have to get more interested in the code metrics, for I have really lost sight of that.

Sharing experiences – that is what a blog is for, isn’t it?

The dotnet Cologne 2009

Today, I attended the dotnet Cologne 2009. It was a one-day community conference (in German) on WPF and Silverlight.

About 180 people gathered at the Microsoft building in Cologne. They were presented a very good programme. The speakers were great, the topics of the talks were great, too. The talks were arranged on two tracks most of the time.

For me, it was a quite valuable event. I gained a lot of practical insights into WPF and Silverlight. In particular, the talk on the data binding mechanism in WPF attracted my special interest. As usual, the discussions with the participants during the breaks were interesting as well as inspiring.

In addition, which made the day valuable for me in terms of money or development tools, I won a ComponentOne Studio Enterprise licence from the closing raffle. 🙂

Thanks to the organisers and I’m looking forward to the dotnet Cologne next year!

Now it’s CCD yellow degree

I started to wear my yellow CCD wristband today. So my focus is on the principles and practices of the 3rd CCD degree currently.

The yellow degree emphasises:

  • Principles
    • Interface Segregation Principle
    • Dependency Inversion Principle
    • Dependency Injection (without Locator or Container)
    • Liskov Substitution Principle
  • Practices
    • Automated Unit Tests
    • Mockups
    • Code Coverage Analysis
    • Partiticipation in technical conferences and meetings

Here is my attempt of a very short subsumption as I did in my post on the previous degree: The principles of the yellow degree support proper design and architecture, they enhance testability in the same way. This is required for the practices (except the participation in conferences), for these concentrate on (automated) code testing. (There are no rules here.)

Stefan Lieser told me, that together with Ralf Westphal he tried to build thematic bundles for each CCD degree. As I can see so far, they did a good job.

Once more, I am aware of almost all the elements focussed at my current degree. In general, most of the principles, rules, and practices presented on CCD are well-known. The purpose of a CCD degree is to concentrate on the elements of that degree and to try not to violate them. By this, they hopefully will become second nature to you.

Nice tool: NHibernate Profiler

A few weeks ago, we started to use a new tool by Ayende: The NHibernate Profiler (currently beta). It is a real-time debugger to debug and improve the usage of NHibernate in our modules.

The NHibernate Profiler provides a lot of valuable (technical and statistical) data on the current activity:

  • SQL statements per session with additional information: Details, stack trace, and alerts. Alerts are some warnings which Ayende explains on his website.
  • A session usage report: Number of entities loaded, entities loaded, duration, etc.
  • A session analysis, e.g. View by Method which displays all SQL statements generated by a particular method of a module.
  • Statistics not only on the sessions, but also on the session factory.

We have used it several times to see, what our modules using NHibernate internally do. In particular, the alert information have been extremely valuable for us.

Obviously, there are still some minor bugs in the beta version of the tool. For example, we get a Use of implicit transactions is discouraged alert although we only have explicit transactions.


In order to debug an application, the client for monitoring the activity has to be started. This client provides all the information explained above.

The best way to make your application communicate with the client is to use log4net, for the application (and the solution/project) does not need to be changed in any way in this case (provided that you already use log4net in your application). Just add an appender in the log4net.config file and make the required loggers use that appender.


<appender name="NHibernate.Profiler" type="HibernatingRhinos.NHibernate.Profiler.Appender.NHibernateProfilerAppender, HibernatingRhinos.NHibernate.Profiler.Appender" >
  <sink value="tcp://localhost:22897/NHibernateAppenderLoggingSink" />
<logger name="NHibernate.Transaction.AdoTransaction">
  <level value="DEBUG"/>
  <appender-ref ref="NHibernate.Profiler"/>
<logger name="NHibernate.Loader.Loader">
  <level value="DEBUG"/>
  <appender-ref ref="NHibernate.Profiler"/>
<logger name="NHibernate.SQL">
  <level value="DEBUG"/>
  <appender-ref ref="NHibernate.Profiler"/>
<logger name="NHibernate.Impl.SessionImpl">
  <level value="DEBUG"/>
  <appender-ref ref="NHibernate.Profiler"/>
<logger name="NHibernate.Persister.Entity.AbstractEntityPersister">
  <level value="DEBUG"/>
  <appender-ref ref="NHibernate.Profiler"/>

As this example shows, the profiler appender class has to be referenced and a TCP sink for the communication with the client has to be declared. The defined loggers redirect the required information to the profiler. Finally, the DLL containing the profiler appender class has to be stored in the application directory. That’s all. When running the application, the NHibernate activities are monitored by the client.

You can (and due to the licence, you probably must) ship your application without the profiler appender class DLL. There is no need to modify the log4net.config file, though. The profiler appender does not have to be removed. log4net just complains (within its log file), that the particular appender could not be instantiated (because it was not found). If you do not want that message in the log file, you have to ship your application with a log4net.config which does not contain the profiler appender.

Another way to use the profiler is to reference the HibernatingRhinos.NHibernate.Profiler.Appender.dll and make the following call within the application startup:


But as this means a change of the application code and requires a reference within the project, I do prefer the first kind of usage. Additionally, the application cannot be shipped when modified in this way. (Remember, you may not ship the profiler appender class DLL with your application.)

Now working on CCD orange degree

I have mentioned the Clean Code Developer (CCD) and its idea earlier. After having worked on the red (1st) degree so far, I am currently focusing on the principles, rules, and practices of the orange (2nd) degree.

The orange degree emphasises:

  • Principles
    • One level of abstraction
    • Single Responsibility Principle
    • Separation of concerns
  • Rules
    • Source code conventions
  • Practices
    • Issue tracking
    • Automated integration tests
    • Read, read, read
    • Reviews

A two sentences subsumption: The principles and rules of the orange degree support readability and understanding of source code. The practices are related more or less to the soft skills of a software developer.

The first degree was comparably easy, because I was already aware of most of its elements. Nevertheless, it took me almost two months not to violate the 21 day rule, which says, that you may not violate any of the aspects of your current degree for that time span before you go on to the next degree.

Just one remark: CCD defines professionalism for a software developer. The application of what is said there leads straight to better (i.e. higher quality) software. It was not expressed that explicitly in my first post on CCD. But it seems important to me.

Scrum Master part of the team?

It is said almost everywhere that a Scrum Master should not be part of the developer team. And in my experience, this really should be avoided.

Due to several circumstances it may be that you have a part-time Scrum Master, who has to switch between that role and the one of a team member. But there are several reasons for that a Scrum Master should do his mastering job rather than being occupied with working on Sprint Backlog items:

  • The Scrum Master role defines a full-time job if it is taken seriously. Serving all the facets of that role consumes all of the Scrum Master’s available time.
  • Having the Scrum Master role alone avoids conflicts of interests. How can a Scrum Master be neutral and propose an appropriate solution if there is a conflict between the Product Owner and the team, and he is a team member the same time?
  • A Scrum Master has a better position for moderation if he is not involved in the everyday business of working on the Sprint Backlog items. This makes him have a more abstract and less emotional view on what happens during the Sprint.
  • In case the Sprint Goal is in danger: I bet, a part-time Scrum Master will decide to concentrate his work on the Sprint Backlog items, neglecting his alter ego. This definitely results in a weak Scrum Master and means a danger for a proper Scrum process.

For sure, these aspects are even more important when you want to carry Scrum into your enterprise for the first time. At that time, obeying the Scrum rules is crucial for success. And so, the Scrum Master should not be distracted from doing his job. Part of this job is implementing Scrum and comprises – among others – creating an understanding of the underlying concepts in the mind of the people involved. He acts as a change agent!

If you do have a Scrum Master who is a team member also, you should check the option, that he is not the Scrum Master of his own team. This prevents him from at least a few conflicts of interests and puts him in a better position for his moderation jobs.

Fortunately, we recently had a change. We do not have Scrum Masters any more, who are members of the developer teams the same time. A Scrum Master now is responsible for up to four teams and the same number of Product Owners.

Just two more ideas concerning the Scrum Master role, which may lead slightly off topic, but I find them worth mentioning here:

First, when starting to implement Scrum or trying to do Scrum seriously, I advise a Scrum Master not being part of the company originally, i.e., he should not be recruited from the existing staff. This helps him

  • to have a better standing towards the management. A prophet has no honour in his own country.
  • to have a better standing towards the team as well. For the team members do not know him, they have an open mind to what he tells.
  • to be impartial, because he can be more objective. He does not know all the internal things of the company at the time he starts his job.
  • to find out the skills and abilities of the team, because he can have an unprejudiced look on it.

Second, I hardly dare to mention, that of course a Scrum Master has to be well versed in Scrum, agility, etc. in general and to be well versed in his role in particular. I.e., when the decision for doing Scrum is made, an experienced Scrum Master should be engaged. Furthermore, the Scrum Master role requires a lot of soft skills – first to mention communication skills. (But the latter is worth another blog post…)