Wednesday, November 30, 2011

Feedback Requested: Is there any valid usage for the ‘new’ keyword?

Yesterday I ended up being part of a discussion about using the ‘new’ keyword to hide base-class members. A colleague of mine used it to alter a base-class property in a derived class with the purpose of making it more strongly typed.

I’ve always rationalized guideline AV1010 (Don’t hide inherited members with the new keyword) by referring to the Liskov Substitution Principle and claiming that if you need it, then you’re probably facing a design smell. In this particular case that was indeed the issue, so after fixing it, the keyword wasn’t necessary at all.

But, his arguments did make sense. In fact, he was so convinced about it that he sent me a proposal for an exception to the C# Coding Guidelines. As part of the discussion, he also sent me some background info on the keyword’s origin by C# co-author Eric Lippert.

This is the example he claims is a valid and useful exception to the guideline. The purpose was to ensure that a manager always has a smart phone rather than any other type of phone.

    public class Phone

public class SmartPhone : Phone

public class Employee
public Employee(Phone phone)
Phone = phone;

public virtual Phone Phone { get; }

public class Manager : Employee
public Manager(SmartPhone phone) : base(phone)

public new virtual SmartPhone Phone
get { return (SmartPhone)base.Phone; }

As far as I see it, the Manager class is violating the contract defined by the Employee class, and thus violates the LSP. If an employee can have any type of phone, and a Manager cannot, than clearly, a Manager is not an Employee. They may share some characteristics, but that might be solved by a common base-class.

Small Liskov Substitution Principle poster

I don’t easily loosen guidelines unless there’s a really sensible exception, but I do like to give any suggestion serious consideration. So please provide me your feedback. Is there any valid reason for using the ‘new’ keyword other than for legacy purposes (where you can’t change some base-class code) and which is not a design smell?

Let me know by commenting on this post, by sending me email or tweeting me at @ddoomen.

Friday, November 04, 2011

Almost five years at Aviva Solutions and still enjoying it every minute

I know, I know, I’m still 3 months away from it. But without doubt, on the 1st of February, I will be celebrating my first 5-year anniversary in the 15 years of my professional career. That might sound silly, but I’ve always had a problem of getting restless after a few years . It never was a problem with the people around me, and in fact, from a employee point of view I’ve never had anything to complain at all. It has just been my desire to move along at some point and discover a fresh new environment.

Strangely enough I don’t have that problem at all currently. Some may claim its my age and the corresponding desire for finding a final settlement, but I’m quite sure it’s the uniqueness of my current employer, Aviva Solutions. I think this is well illustrated by this photo collage (click for a bigger picture).

Collage Summer Event XL 2011

Obviously our annual social trip to a warm place close to the beach is only barely sufficient to keep me happy (pun intended). But the fact that we have practically no hierarchy, that I enjoy the company of some very experienced colleagues, and that our two CEOs value each and every employee by heavily facilitating in their personal and technical knowledge and skills might be more important.

To clarify my added value to the company, I try to lead the themes Custom Solutions & ALM and Cloud Solutions. That means that I spend four days a week on (long-term) consultancy jobs and one day in making sure we as a company invest enough in current and new Microsoft technologies, practices and software development methodologies.

BTW, the other themes include Application Integration, E-Commerce & CMS, Business Intelligence and Portals & Collaboration. This doesn’t mean anybody is fixed to a particular theme for life. Its just to allow them to focus a bit and prevent them from drowning in the elaborate world of Microsoft. In fact, everybody is expected to have thorough knowledge of the .NET Framework and a clear understanding with the practices from Extreme Programming and Agile methodologies such as Scrum or Kanban.

We’re only with 40 professionals right now, and we’re still looking for new colleagues that match the following characteristics:

  • Are passionate about the software development profession
  • Like to share their opinions
  • Are capable of conveying that opinion to the lesser gods (read: managers)
  • Are not afraid to propose alternate or better solutions to a problem
  • Have a natural tendency of trying to improve themselves and the people around them
  • Speak Dutch fluently
  • Who don’t have anything against an annual weekend at a warm sunny beach and a drink here and there

If you think you fit that description in any way, let me know by tweeting me at @ddoomen or emailing me at We might be drinking a beer at next year’s annual event.

Silverlight Cookbook: Looking for a great UI design

Why? Because even though think I have a reasonable idea of when a user interface is consistent and user friendly, I suck at the raw design skills. Just check out the current ‘design’ if you don’t believe me.


I’m actually looking for something that resembles the Cosmopolitan theme or MetroTwit:


It’s enough to have a one or two screenshots to get me started. But I’m currently a bit out of inspiration to get something interesting out of my hands. Obviously you’ll get all the credits in my tweets, posts, etc.


Thursday, November 03, 2011

In Retrospect: About Bugs

This is the third of several posts in which I’d like to share some of the things we learned throughout more than 14 sprints of Agile development using Scrum. Some of them might appear as open doors, but I wish I knew or thought about those before I started that project. Just by looking back at the mistakes a team of 9 developers and one tester made in a period of 12 months, they apparently aren’t that obvious. So after having discussed the way we handle the sprint planning meeting elaborately, let’s briefly talk about bugs.

Strive for a zero-bug policy

In other words, try to keep your list of bugs empty and don’t start a new story until all bugs are solved. The reason for this is the longer you wait with fixing that bug, chances are that it will take a whole lot of more work to fix it. And be reluctant to moving a bug to the product backlog for reprioritizing. If you’re doing that, then you’re probably not dealing with a bug after all and should have been filed as a user story instead. A side-effect of this practice is that it will make it very visible when your team is suffering from a lot of bugs. It should give you a natural tendency to change your way of working so that bugs are less likely to occur.

Reduce the focus factor to deal with regressions.

We never assign story points to bugs that are being solved within the same sprint. The estimated focus factor of your sprint should accommodate for the average number of bugs that are typically found in a sprint. And beware that if you’re not applying automated testing to your entire codebase, the larger the codebase, the bigger the chance that regression issues will occur.

Schedule left-overs in the sprint planning

When, at the end of the sprint not all bugs have been solved, move them onto the agenda of the next sprint planning meeting and estimate them just like you do with stories. This makes it clear that the quality level of the work in the last sprint was not at the expected level and protects you from a sprint with a false start.

Make sure a bug is really a bug

I lost count of how many times somebody in the team started working on a bug and found out that it really was a disguised change request. Especially HTML/CSS-related improvements have the tendency of ending up as bugs and require a lot of time to fix. Just move them to the product backlog as a user story storyotyped as UI Enhanchement. Misinterpretations and oversights in business rules have popped up as bugs once in the while as well, especially if the product owner didn’t spend enough time evaluating the story in the previous sprint. If that happens, we simply change it into a user story and ask the PO to reprioritize it for the next sprint. If you do this often enough, it might encourage the PO to allocate a bit more time to the evaluation next time.

Use a tool to keep track of issues

In the beginning of the project, we simply created a Microsoft OneNote page to keep track of small issues that our tester found throughout the sprint. We thought the low threshold of OneNote would keep the administration to a minimum. But we found that some descriptions were a bit vague, especially if the test professional that created them was out of the office. We introduced some specific requirements for each issue such as what he or she did to trigger the problem, what the expected behavior was, etc. Then we discovered that occasionally, two developers were working on the same issue. So we agreed to highlight the issue in the issue list as soon as a developer started to work on it and to add his name in a dedicated column. The next problem was the length of that list, in particular because our lack of automated UI tests. We tried to solve that by moving the fixed issues to another OneNote page, all to keep away from too much administration.

But you can guess how this story ends. We finally started to file real bugs in our Team Foundation Server environment. Our test professional are now using the Microsoft Test Manager to do structured and exploratory testing, so for them it’s little trouble to create a bug. In fact, we now get a lot more details about the circumstances under which the test was executed. Those really help tracking down a particular problem.

Remember that these are the experiences of me and my team, so they might not work as well for you as they did for us. Nevertheless, I’m really interested in learning about your own experiences, so let me know by commenting on this post or tweeting me at ddoomen. Next time, I’ll be discussing the things we did to get through the sprints as efficiently as possible.