It was nice to see that JetBrains was present with a booth and two talks (on their products ReSharper and YouTrack). It was for the first time, so I went to their booth and had an interesting conversation. Anyway, talking to other participants and exhibitors is as much important as the conference sessions.

My highlight session was Rainer Stropek talking about WinRT! It was a great technical deep dive. Johannes Hofmeister shared his thoughts about Empathic Code (i.e. how code should look like with respect to readability) with us which urged me to nod the whole time. Besides that, I was interested in CQRS, some C# goodies, Windows 8 for .NET developers, and in what is new in Visual Studio 2011. Again, it was hard to pick the best sessions of that broad offering.

PS: The next dotnet Cologne is on 3 May 2013!

So, should a Scrum Master be a skilled programmer? In my eyes: Definitely yes!

Why? Well, I think, that is quite obvious. One aspect of the the Scrum Master role is his responsibility for the team. The Scrum Master has to improve the team. There are a lot of facets of what can be improved, one of these are programming skills for sure. Improving the programming skills lead to better code, to clean code in best case. If a Scrum Master finds his team (or a part of it) needing some help in that area, he has to coach it. First, this requires that a Scrum Master is able to recognise this. And second, the Scrum Master must be able to demonstrate to the team better techniques, best practices, and so on. (This is not meant as a prescript for the team. It is more a hint how things may go better. Still, the team can decide in what way it wants to work.) Therefore, to fulfil this part of his role, the Scrum Master must own programming skills!

By the way: Meanwhile, it should be clear what my understanding of a skilled programmer (or better: skilled developer) is. It is not only the knowledge of one or more programming languages, frameworks, and development environments. It is rather the things, that CCD comprises, behaviour/test driven development, domain driven design, design patterns/principles, just to name a few… I think, both sorts of skill are requirements for a skilled programmer which make him a skilled developer then.

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!

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.

The 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)!

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.

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.

]]> http://blog.bollow.name/2009/08/the-particularity-of-the-product-owner/feed/ http://blog.bollow.name/2009/07/green-is-my-current-ccd-degree/ http://blog.bollow.name/2009/07/green-is-my-current-ccd-degree/#comments Fri, 03 Jul 2009 18:55:00 +0000 Erik Bollow http://blog.bollow.name/?p=216 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?

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!

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.

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.

Usage

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.

Example:

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

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:

HibernatingRhinos.NHibernate.Profiler.Appender.NHibernateProfiler.Initialize();

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.)