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!

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!

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!

“APM reliably delivers innovative results to customers within cost and schedule constraints.”

Let me take that sentence out of its context and make a point I believe needs to be stressed. Software development methodologies (Agile Project Management in this case) delivers nothing! People, on the other hand, do.

Some years ago I developed a special interest in software development methodologies. Since then I’ve spent much time reading literature on Scrum, eXtreme Programming, etc, aiming to optimize the processes we use in our projects. During that time I’ve learned a lot, but also come to realize that I’ve been focusing too much on the wrong things.

In the past I thought the problems we were experiencing were problems with the methodology, an easy conclusion to draw from the propaganda-like information out there. However, I’ve found that the methodology matters little in comparison to the quality of my project team. Today I focus more on the team, the product, and the customer, and less on the latest within agile.

Thus, my formula for a successful project is this:

• Spend less energy on the methodology; i.e. pick a simple one and adapt it when (and only when) needed, or stick to the one you’re currently using
• Do more to get the right people
• Make sure they are motivated and connected
• If you think you’ll fail, do it fast

Summary

If we focus too much on the methodology, and give it too much importance, we risk loosing sight on the real goal, namely producing the right system. And for that you need the right people.

Cheers!

I first came across this version of The Rule of Three in Johanna Rothman and Esther Derby’s excellent book, Behind Closed Doors. The idea is to brainstorm solutions to a given problem, and not stop until you have at least three options to choose from. Listing the pros and cons of each solution helps you make a good decision.

With The Rule of Three I’m forced to think broader. I need to widen my view to find possible solutions other than the first that springs to mind. I’ve found that this process makes me explore the original solution better, and the risk of overlooking a good option is greatly reduced. Also, two different solutions can sometimes be combined into a new, even better one.

The Rule of Three can be applied in many ways, within a group or by yourself. It’s a cheap way to build better foundations for your decisions. That’s why I embrace The Rule of Three.

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

The 20% folks are what many would call “alpha” programmers — the leaders, trailblazers, trendsetters, the kind of folks that places like Google and Fog Creek software are obsessed with hiring. These folks were the first ones to install Linux at home in the 90’s; the people who write lisp compilers and learn Haskell on weekends “just for fun”; they actively participate in open source projects; they’re always aware of the latest, coolest new trends in programming and tools.

The 80% folks make up the bulk of the software development industry. They’re not stupid; they’re merely vocational. They went to school, learned just enough Java/C#/C++, then got a job writing internal apps for banks, governments, travel firms, law firms, etc. The world usually never sees their software. They use whatever tools Microsoft hands down to them — usally VS.NET if they’re doing C++, or maybe a GUI IDE like Eclipse or IntelliJ for Java development. They’ve never used Linux, and aren’t very interested in it anyway. Many have never even used version control. If they have, it’s only whatever tool shipped in the Microsoft box (like SourceSafe), or some ancient thing handed down to them. They know exactly enough to get their job done, then go home on the weekend and forget about computers.

Ben took a lot of heat for his oversimplification. People, it seems, don’t like to be categorized, a fact I too discovered when trying to make a distinction between Developers and Programmers. They especially don’t like to hear that they’re mediocre, not special, or less worth, which is the undertone of Ben’s 80% category.

During my military service I learned that statistically, only two soldiers in a group of eight would be effective in a combat situation. The rest would be pinned down, unable to return fire. Thus, one could say that the firepower of a squad comes from a fraction of it’s soldiers. I think this is often true for development teams as well. A few members are accountable for a majority of the produced value.

The funny thing is, that some of the best value-bringers I’ve met in my career does not fit the 20% alpha-geek group defined by Ben. And many of the “elite” programmers, the ones that do fit the description, have been remarkably inefficient. One reason for this could be that bleeding edge isn’t always the best strategy to achieve business value.

So, the question we should ask ourselves is not whether we’re in the 20%, it’s: Do I add to the firepower of my team? What can I do to bring more value?

You form a project to achieve a specific goal, a goal you want to reach as soon as possible. So projects are all about focus, and you can not focus on more than one task at a time. It’s inevitable that you’ll lose time juggling projects. Thus, part time engagement makes projects move slower.

So, what to do? The same things you always do when resources are scarce: prioritize, divide and conquer. Always form teams that work full time on a single project. They will be more productive, and if you’re lucky they might even jell. Let the teams finish before you assign a new task. Instead, see to it that projects are small and can be completed within relatively short time. If a project swells and get big, find the smallest set of features that would still be useful, and form the project around that. Remember, the process of iteration can be applied at the project level too.

Project iteration has several advantages: it increases the closure frequency which helps keeping the teams performance rate high, it increases the chance of success for the individual project, and it releases something useful to the users sooner. And, it provides a constant stream of opportunities for you to make new strategical decisions based on small manageable projects.

To conclude this rather messy post: Don’t mess with my team, let us stay focused and finish what we have set out to do.

One cannot make every team jell. All you can do is provide the basic ingredients and hope for the magic to kick in. All teams in a jelled state have this in common:

• A jelled team has a specific goal, a goal that is shared by all members.
• All members of a jelled team have a high sense of responsibility and commitment.
• All members of a jelled team feel they are accomplishing something of value.
• All members of a jelled team take interest in each others work, since it’s part of their goal.
• The members are enjoying themselves. They long to get to work to spend time together while moving the project forward. Laughter is frequent.
• A jelled team has great communication: with customers, management and in between members.

As a project manager, if your team enters the jelled state you should step back and let the team dynamics do the work. Concentrate on keeping the team jelled, which most of the time is the same as doing nothing at all. Focus on protecting the team from unimportant external interference, and on stuff that boost the team’s confidence and wellbeing.

Appreciation and the sense of completion is very important to keep a team jelled for a long period of time. I once read (don’t remember where) about a team manager that hung a bell in the center of the workplace. The developers were instructed to ring the bell whenever they had done something good. It may sound silly but it’s actually one of the best ideas I’ve ever heard to boost team spirit. Whenever the bell rung people left whatever work they were doing to join the bell ringer and hear about his accomplishments. That team fed appreciation to itself, and provided a constant feeling of accomplishment.

So, how do you know if your team is jelled? Well, one way would be to hang such a bell in a strategic location. If the bell starts ringing on a regular basis chances are good that your team is jelled. If people also leave their workstations to cheer with the happy fellow – then you know for sure.