Do not spread generic types around. They are ugly and primitive.

Allow me to elaborate.

Generics are great

Before we got Generics (2004 in Java, 2005 in C#, and 2009 in Delphi) the way to enforce type safety on a collection type was to encapsulate it and use delegation.

class OrderList
{
  private ArrayList items = new ArrayList();

  public void Add(OrderItem item)
  {
    items.Add(item);
  }

  // Plus lots of more delegation code
  // to implement Remove, foreach, etc.
}

Nowadays, we can construct our own type safe collection types with a single line of code.

List<OrderItem> orders = new List<OrderItem>();

That alone is good reason to love generics, and there lies the problem; many developers have come to love their generics a little too much.

Generics are ugly

The expressiveness of generics comes at a price, the price of syntactic noise. That’s natural. We must specify the parameterized types somehow, and the current syntax for doing so is probably as good as anything else.

Still, my feeling when I look at code with generics is that the constructed types don’t harmonize with the rest of the language. They kind of stand out, and are slightly negative for code readability.

OrderList orders = new OrderList();
// as compared to
List<OrderItem> orders = new List<OrderItem>();

This might not be so bad, but when we start to pass the constructed types around they become more and more like litter.

List<OrderItem> FetchOrders()
{
  //…
}

double CalculateTotalSum(List<OrderItem> orders)
{
  //…
}

void PrintOrders(List<OrderItem> orders)
{
  //…
}

Besides being noisy, the constructed types expose implementation decisions. In our case the list of orders is implemented as a straight list. What if we found out that using a hash table implementation for performance reasons would be better? Then we’d have to change the declaration in all those places.

Dictionary<OrderItem, OrderItem> FetchOrders()
{
  //…
}

double CalculateTotalSum(Dictionary<OrderItem, OrderItem> orders)
{
  //…
}

void PrintOrders(Dictionary<OrderItem, OrderItem> orders)
{
  //…
}

Comments redundant.

Generics are primitive

A related problem is that the constructed generic types encourage design that is more procedural than object-oriented. As an example, consider the CalculateTotalSum method again.

double CalculateTotalSum(List<OrderItem> orders)
{
  //…
}

Clearly, this method belongs in the List<OrderItem> type. Ideally, we should be able to invoke it using the dot operator.

orders.TotalSum();
// instead of
CalculateTotalSum(orders);

But we cannot make that refactoring. We cannot add a TotalSum method to the List<OrderItem> type. (Well maybe we can if we make it an extension method, but I wouldn’t go there.) In that sense, constructed generic types are primitive types, closed and out of our control.

So we should hide them

Don’t get me wrong. I use generics a lot. But for the previously given reasons I do my best to hide them. I do that using the same encapsulation technique as before, or – at the very least – by inheriting the constructed types.

class OrderList : List<OrderItem>
{
  double TotalSum()
  {
    //…
  }
}

So, the rule I go by to mitigate the downsides of generics, is this:

Constructed types should always stay encapsulated. Never let them leak through any abstraction layers, be it methods, interfaces or classes.

That is my view on Generics. What is yours?

Cheers!

P.S.

Just to be clear, the beef I have with Generics is with constructed types alone. I have nothing against using open generic types in public interfaces, although that is more likely to be a tool of library and framework developers.

You should always leave the camp ground cleaner than you found it.

Applied to programming, it means we should have the ambition of always leaving the code cleaner than we found it. Sounds great, but before we set ourselves to the mission we might benefit from asking a couple of questions.

1. What is clean code?
2. When and what should we clean?

Clean Code

What is clean code? Wictionary defines it like so:

software code that is formatted correctly and in an organized manner so that another coder can easily read or modify it

That, by necessity, is a rather vague definition. The goal of being readable and modifiable to another programmer, although highly subjective, is pretty clear. But what is a correct format? What does an organised manner look like in code? Let’s see if we can make it a little more explicit.

Code Readability

The easiest way to mess up otherwise good code is to make it inconsistent. For me, it really doesn’t matter where we put brackets, if we use camelCase or PascalCase for variable names, spaces or tabs as indentations, etc. It’s when we mix the different styles that we end up with sloppy code.

Another way to make code difficult to take in is to make it compact. Just like any other type of text, code gets more readable if it contains some space.

Although the previous definition mentions nothing about it, good naming of methods, classes, variables, etc, is at the essence of readable code. Code with poorly named abstractions is not clean code.

Organized for Reusability

Formatting code is easy. Designing for readability, on the other hand, is harder. How do we organize the code so that it is easily read and modifiable?

One thing we know, is that long chunks of code is more difficult to read and harder to reuse. So, one goal should be to have small methods. But to what cost? For instance, should we refactor code like this?

SomeInterface si = (SomeInterface)someObject;
doSomething(si);

Into this?

doSomething((SomeInterface)someObject);

What about code like this?

string someString;
if (a >= b)
  someString = “a is bigger or equal to b”;
else
  someString = “b is bigger”;

Into this?

string someString = a >= b ? “a is bigger or equal to b” : “b is bigger”;

In my opinion, the readability gains of the above refactorings are questionable. Better than reducing the number of rows in more or less clever ways, is to focus on improving abstractions.

Extract ’til you drop

Abstractions are things with names, like methods or classes. You use them to separate the whats from the hows. They are your best weapons in the fight for readability, reusability and flexibility.

A good way to improve abstractions in existing code is to extract methods from big methods, and classes from bulky classes. You can do this until there is nothing more to extract. As Robert C. Martin puts it, extract until you drop.

That leads me to my own definition of clean code.

• It is readable.
• It is consistent.
• It consists of fine grained, reusable abstractions with helpful names.

When to clean

Changing code is always associated with risk and “cleaning” is no exception. You could:

• Introduce bugs
• Cause build breaks
• Create merge conflicts

So, there are good reasons not to be carried away. A great enabling factor is how well your code is covered by automatic tests. Higher code coverage enables more brutal cleaning. A team with no automatic testing should be more careful, though, about what kind of cleaning they should do.

Also, to avoid annoying your fellow programmers it’s best to avoid sweeping changes that may result in check-in conflicts for others. Restrict your cleaning to the camp ground, the part of the code that you’re currently working on. Don’t venture out on forest-wide cleaning missions.

If the team does not share common coding rules, there’s a risk that you end up in “Curly Brace Wars”, or other religious software wars driven by team members’ individual preferences. This leads to inconsistency, annoyance and loss of energy. The only way to avoid it is to agree upon a common set of code rules.

With all that said, I have never imposed “cleaning” restrictions on my teams. They are allowed to do whatever refactorings they find necessary. If they are actively “cleaning” the code it means they care about quality, and that’s the way I like it. In the rare cases excessive cleaning cause problems, most teams will handle it and change their processes accordingly.

Cheers!

I’ve been using the plugin for a couple of months now and I’m quite happy with it. The only problem, for me, has been that it doesn’t support The D Programming Language. Since I couldn’t find any on the internet, I decided to implement a D brush myself. (It’s quite simple.)

Following Viper’s advice I implemented the support as a tiny Wordpress plugin. If you’re using SyntaxHighligher Evolved and want to be able to display syntax highlighted D code, feel free to download shBrushD from my new Shared Stuff page.

Cheers!

1. Is the team as productive as it can be?
2. Is it doing the right things?
3. Is it delivering on expectations?

To me those questions represent the essence of project management. Finding the answers, identifying the impediments and removing them are what I consider my most important tasks as a project manager; not to impose a particular methodology.

Productive teams

Good questions to ask while analyzing the productivity of a team might be:

• Does the team contain the right people?
• Is it getting rapid answers?
• Is it getting quick feedback?
• Is it optimized for long term or short term productivity?

In software development, the only measure of team productivity is its ability to produce working software. So if you want to maximize your team’s productivity you should focus on those capable of creating software. Make sure they can spend as much time as possible producing customer value.

For that reason, I think twice before I ask my developers to perform some compliance activity, like writing a report. It’s almost always better to have someone else do stuff like that. If I need information I can always ask, and if writing a report is necessary, I can collect the information and write the report myself. That way I contribute to keeping the team focused and productive, which is more important than to ease my own work load.

Monitoring the team’s productivity is an important task of the project manager. I do this mainly by being around the team a lot. Taking an interest in each individual’s working situation and task at hand is the best way to pick up problems and impediments.
Other important sources of information (although not as efficient as MBWA) are the daily meetings and iteration retrospective.

If you’re really lucky; with the right material and inspiring goals, the team jells and becomes hyper productive. That is every project manager’s dream, but few get to experience it.

Efficient teams

But being productive is not enough. What we really want is efficiency, and to be efficient you need to be both productive and produce the right things. Right in this sense means the right features, with the right quality, in the right order.

To eliminate the risk of producing wrong features you need to work closely with the customer. Make the feedback loop as short as possible, preferably by utilizing an onboard customer, or at least by holding regular review meetings.

Another thing you’d really want to do is to have the planned features prioritized. For some reason many customers (here in Sweden at least) are generally unwilling to do this for you.
“I decided what I want to include in the release, didn’t I? All those features are equally important.”

The problem with leaving priorities to the team is that the system will be developed in an arbitrary order, most likely with the easiest features first. While that may have a value in some situations, the downside is that it decreases the project’s chance of success. The reason is, that without customer value as the leading beacon, chances are that you’ll end up with a lot more bells and whistles than you can afford. And when you find that out it’ll be too late to rectify.

Dealing with expectations

How do you define project success? Here is one definition:

If the output is in line with what the customer expects, the project is successful.

The good thing with this definition is that it implies another variable to work with besides output, namely customer expectations. If the answer is yes to both questions 1 and 2 above, we know we are maximizing the output. But if that still isn’t good enough, we have only one option left. We must change the customer’s expectations, or fail.

Again, the best way to tune the customer expectations is a tight feedback loop. If the customer sees the progress regularely, she will adjust her expectations accordingly, or have a chance to react to reality. Either way, the chance for success increases.

Never lose focus on the end goal.

Cheers!

According to Martin Fowler and his companion pair programming is an effective development practice because:

1. We can only use one part of our brain at one time, and
2. “The driver” and “the navigator” of a pair programming unit are using different parts of their brain and are thus complementing each other.

I have no idea if this is a proven truth, but it certainly conforms to my own experience with pair programming. The driver (the one with the keyboard) usually ends up in a state of completing-the-task-at-hand focus, while the navigator, a little more detached, makes bigger sweeps and thinks more on the big picture. For me pair programming has always resulted in better design, less bugs and a lot more fun.

If you want to watch for yourself, but don’t want to spend the full one hour, you’ll find the pair programming part 36:20 into the presentation.

Cheers!

Shallow Testing

There are many possible reasons for a bug tracking system to turn into a dump of wasted effort. One reason is when the testing team is practicing shallow testing. That is when the testers file bug reports right after discovering bugs, leaving any further investigation to the developing team. This is convenient for the testers but bad for the overall process of finding and fixing bugs.

The shallow testing technique results in many bug reports, most of them with poor quality. But the measure of effective testing is not how many bug reports it produces. What counts is the amount of bug reports that lead to bug fixes. To be effective we need great bug reports.

Great Bug Reports

So, what does a great bug report look like? We need to ask another question to answer that. What does the developer need to fix a bug? The first step of a successful bug elimination is to reproduce it in a controlled development environment.
In order to do that he needs to:

1. Put the system in a state from which the error can be produced.
2. Perform the actions that produce the error.
3. Know how to identify the error.

Most bug reports contain enough information to make step 2 and 3 clear. Clues toward step 1, on the other hand, are usually missing. As a result the developers end up doing additional testing to pin down the problems.

If we do a better job with our bug reports we can get two really important effects. We help developers spend less time on each bug and instead fix more of them, and we increase the chance that the report will be acted upon. This is why thorough testing on behalf of the testing team is so important.

Focus On the Right Things

The basic formula to produce great bug reports is as follows.

1. A descriptive name.
   The most important details of the bug presented in a sentence.
2. Steps to reproduce.
   This is the part that distinguishes great bug reports from lesser ones. A well-described sequence of action steps that describes how to reproduce the bug removes uncertainties and signals thorough research. Developers are therefore more inclined to act upon such a bug report than a fuzzy one.
   It’s also important that the reproduction steps start at a known state, preferably at a clean program start.
3. Expected results.
4. Actual results.
5. Any possibly relevant attachments, for example screen-shots and data.

Depending on the system you’re using, a multitude of additional parameters may be set to categorize the bug further. Provide the extra information if applicable, but it’s not essential so don’t let it steal focus from the basic formula.

Bug Mining

The foundation of a great bug report is built with great testing. Great testing is hard work and requires a special mindset: the love of bugs and the willingness to spend a lot of time examining each new specimen.

When a great tester discovers a bug the first thing she does is not to fire up the error reporting tool and start describing it. She leaves that for later. Instead she goes about to find the answers to these two questions:

1. Can I reproduce this bug?
2. If so, what is the smallest number of steps I need to do so?

This usually requires several program resets, attacking the bug from different angles. I like to call this process Bug Mining and it’s the tester’s most important task.

Why all the hard work?

Why should the tester have to do all this work, you might ask. After all, the developers introduced the bugs in the first place so they should clean up their own mess, right? Besides, isn’t it better if the testers spend their time testing and finding more bugs?

The problem is this: If the testers prioritize quantity over quality we’ll end up with a very ineffective test-correction-test cycle, and an ever growing mountain of unresolved bugs.

The more time developers spend on each bug the fewer bugs get corrected. And if fewer bugs get fixed, more time will pass between bug discovery and bug correction, making it even more expensive to fix.
Since the developers are the only ones that can make the bugs go away you really need to think twice before making them do work someone else can do just as well. This is especially true for Bug mining.

Guiding Principles

As a summary, here are some guiding principles to produce great bug reports:

• Focus your effort on the steps to reproduce the bug. They should be clear, complete and as short as possible.
• Only one bug per report.
  Handling several bugs as one is problematic for several reasons. For example, what should you do if the bug report contains bugs with different severity? Also, it’s difficult to describe several bugs in the name sentence so some might be overlooked. A third reason is the communication problem that happens when only some of the reported bugs get corrected.
• A few really good bug reports is better than plenty of not so good ones. Quality is better than quantity when it comes to testing.

Cheers!

(Yes, they are mostly Windows developers, Xnix users don’t seem to have this problem.)

But can you blame them? I mean, have a look at this regular expression for validating email addresses.

[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?

That’s enough to send any normally functioning individual out the door screaming. Fortunately, regular expressions aren’t always this messy. In fact, the simpler the problem, the more effective and beautiful they get.

Let’s look at an example that shows the power and density of regular expressions.
Suppose we have a chunk of text. We know that somewhere in it there’s a social security number. Our job is to extract it.

This is one of those tasks that involve a decent amount of code unless your language of choice has support for regular expressions. In Ruby, on the other hand, it’s a single line of code.

text = “Test data that 123-45-6789 contains a  social security number.”

if text =~ /\d\d\d-\d\d-\d\d\d\d/
  puts $~
else
  puts “No match”
end

If  the match operator (=~) and the magical match result variable ($1) puts you off, here’s how it’s done in C# that doesn’t have a special notation for regular expressions, but support them through the .Net framework.

String text = “Test data that 123-45-6789 contains a  social security number.”;

Regex ssnReg = new Regex(@"\d\d\d-\d\d-\d\d\d\d");
Match match = ssnReg.Match(text);

if ( match.Success ) {
  Console.WriteLine(match);
} else {
  Console.WriteLine("No match");
}

A beautiful thing with regular expressions is that it’s really simple to extract the parts of a match. For instance, if we need to extract the area code all we need to do is to put parenthesis around the part we’re interested in. Then we can easily extract that information, in C# by using the match.Groups property.

String text = “Test data that 123-45-6789 contains a  social security number.”;

Regex ssnReg = new Regex(@"(\d\d\d)-\d\d-\d\d\d\d");
Match match = ssnReg.Match(text);

if ( match.Success ) {
  Console.WriteLine(match);
  Console.WriteLine(“Area Number: “ + match.Groups[1]);
} else {
  Console.WriteLine("No match");
}

As intimidating as they may seem, the payoff using regular expressions is huge. And, since efficiency is what we strive for, they have a natural place in our bag of tools. So, learn the basics of regular expressions. You’ll be happy you did.

Finally some advice sprung from my own experience with regular expressions.

•   Get your regular expressions right first. Use Rubular, or an equivalent tool, for pain free experimentation before you implement them in your code.
•    Document your regular expressions. They are notoriously difficult to read so a short description with example match data is almost always a good idea.

Cheers!

Previous posts in the Tools of The Effective Developer series:

1. Tools of The Effective Developer: Personal Logs
2. Tools of The Effective Developer: Personal Planning
3. Tools of The Effective Developer: Programming By Intention
4. Tools of The Effective Developer: Customer View
5. Tools of The Effective Developer: Fail Fast!
6. Tools of The Effective Developer: Make It Work – First!
7. Tools of The Effective Developer: Whetstones
8. Tools of The Effective Developer: Rule of Three
9. Tools of The Effective Developer: Touch Typing
10. Tools of The Effective Developer: Error Handling Infrastructure

After more than 4 years C is back at position number 1 in the TIOBE index. The scores for C have been pretty constant through the years, varying between the 15% and 20% market share for almost 10 years. So the main reason for C’s number 1 position is not C’s uprise, but the decline of its competitor Java. Java has a long-term downward trend. It is losing ground to other languages running on the JVM. An example of such a language is JavaFX script that is now approaching the top 20.

It’s important to point out, thought, that only the language part of Java is losing ground. As Tiobe Software indicates in their comment, the JVM is as hot as ever with all kinds of cool language evolution occurring.

Another interesting note to make about the april index is that Delphi is once again among the top ten. I’m really happy about that, although it means my old prophecy of a hasty decline kind of puts me in the corner (although I’ve already taken it back).

A third point is the giant leap of Objective-C, from 42:nd to 11:th most popular language. This is a combination of iPhone’s popularity and the fact that Objective-C is the only OO alternative allowed on that platform, besides C++.

Cheers!

The task board is absolutely invaluable and I’ll probably never do team related work without it again. The question, though, is whether to use a computerized or a real world one.

Henrik Kniberg recommends the latter. The following quote is from Henrik’s excellent book Scrum and XP from the Trenches.

We’ve experimented with different formats for the sprint backlog,
including Jira, Excel, and a physical taskboard on the wall. In the
beginning we used Excel mostly, there are many publicly available Excel
templates for sprint backlogs, including auto generated burn-down charts
and stuff like that. [...]

Instead [...] what we have found to be the most
effective format for the sprint backlog [is] a wall-based taskboard!

And there are good reasons for picking an analog task board. Maybe the most significant being:

• Visibility. A wall-based dashboard is always up, always visible. If positioned near the team it’ll work as a constant reminder of the shape of the iteration.
• Simplicity. Planning and re-planning is simply a matter of moving physical cards around, tearing them up or writing new ones.

In my current project we’re using an application (Scrum Dashboard on top of TFS). The reasons are:

• Availability. Actually, this is the only reason for us to use a digitalized task board. We’re having dislocated team members from time to time (did I say we’re ScrumButs?) but since our dashboard is a web application they are able to access it remotely. It would be a lot more painful to relay the information otherwise.
• Automatic burndown update. No need for me (or any one else) to do a work remaining summary and update the burndown chart each and every day.

What are your reasons? I’d be most interested in hearing your point of view on this subject.

Cheers!

In my organization we only fulfill two thirds of the Scrum Checklist, so I guess that makes us ScrumButs. I’m not going to feel bad about it though; Change takes time and we’re pretty happy we’ve gotten as far as we have. But Ken’s right, we really should do something about our most difficult problems and go the full ten yards. Maybe later.

Cheers!