Recepie for Effective Meeting

I was running late for a meeting. Frustrated over being late, the meeting itself that looked like a waste of time, and overal number of meetings we have, I got an enlightment:

Meetings is a penalty for the lack of effective [face to face] communication.

Meetings are overhead. Trash. Wasted time, multiplied by the number of participants. They grow in length and numbers and the process becomes Meeting Driven Development.

But in a real world software organization we do have meetings, and no chance to eliminate them in any foreseeable future. The best we can is keep them under control.

A simple recepie of effective meeting:
* Own a meeting
* Define the goal, and expected outcome.
* Publish Agenda
* Come prepared
* Keep it short. Consider timeboxing.
* Close the meeting explicitly.

Comments on the bullets:

Coming prepared made easier when the goal, agenda, and expectation are set and known in advance. But still takes a commitment, discipline, and some training. If you see the participants didn't do their homework, stop and reschedule the meeting. It doesn't pay to continue the meeting; so you better send a strong message and the next time it will certanly be better.

Why timeboxing? Look at those people! When they come to an air conditioned board room, dive into those nice executive leather cheers, and got ready to a nap, buddy, good luck with your agenda! To keep the energy level high, keep the meeting short. Timebox it to 30 minutes, and say so. Keep a timer. Stand. Make everyone physically participate - write on a white board, take notes, walk, move! Don't steal the whole meeting (oh, is it Dmitri saying that? who can believe!?)
Sometimes the meeting subject should be resolved and finished no matter what. Even then an incremental iterative approach to meeting pais off.

How to know when the meeting is done? How to know if it went well? The answer to this is a goal and expectations posted with agenda, and restated first thing in the beginning of the meeting. Write them down on the white board, have everyone look onto it throughout the meeting.

Define the type of the meeting. Is it a brainstorming session? Is it a presentation? Is it an open discussion, feedback generation exercise? Are you gonna consume this feedback or throw it away? Decide, and define.

In closing, recap the goal, outline results, next actions, assigments. If the meeting was effective and productive, say so. Make your mates feel well (even if they missed their nap).

The final bullet:
* Foster communication beyond formal meetings. Remember that "Meetings is a penalty for the lack of effective communication."

C++ is Dying

C++ is dying.

It is complex, tricky, and unforgiving. It lacks rich standard libraries. It is slow for development. It is spoiled by M$ with COM and MFC. It is pushed away from many application domains by Java and C#.

But none of this is the reason for C++ to die. We C++ programmers learned to tackle this, we were never scared away by the difficulties and learned to love the challenges of the C++.

C++ is languishing because C++ programmers lack refactoring support.

With little refactoring tools, people do little refactoring. The code degrades, and as C++ code is not easy to write, it often putrefies faster then grows. Like a beast with low immunity to code bacterias, allergic to anti-biotics, it smells, stinks, decays and eventually dies before it grows to full size.

After first release a corpse of C++ application is left to decompose. Working effectively with a dead body of legacy C++ code is frustrating, and every look to a newest Eclipse, ReSharper or VS.NET for C#, leaves bitter jealousy.

C++ as a language is going to hold the ground in some domains.
But C++ applications without refactoring will smell, then stink, then rot, decay and spoil any programmer who comes in contact with them. C++ developers face a tough choice: stay with crappy legacy or take off from C++. Those who are fascinated with new ideas of evolutionary design, merciless refactoring and aesthetics of clean code are tempted to leave for platforms where code quality is more appreciated. Those who don't care about clean code, stay to patch and band their C++ legacy applications, compromising C++ reputation even further.
This vicious cycle is killing C++.

C++ is dying, and it has nothing much to do with technology. Like everything in software, it is about the people. C++ is loosing good programmers. When good programmers are gone, C++ is dead.

Fitness for Agile Coach

Fitness is a must have job requirement for an Agile Coach. But I am not talking about acceptance tests with Fitness. I mean real physical fitness. Surprised? Think with me:

The magic of project success distills to a combined energy of the team focused to a shared goal. The primary role of Agile Coach to inspire the team, charge them with positive energy, enthusiasm and passion. Everything else is secondary technical details.

"The key to success is to raise your own energy; when you do, people will naturally be attracted to you."
- Stuart Wilde (as quoted in Secrets of the Millionaire Mind by T. Harv Eker.)

We work for our teams. Do they need a coach who's a grim face expresses "it'sone of these days" every day? Do they get inspired by a manager yawning her motivational pitches? Do they get passion from an architect so tired of his own architecture that he looks as if he just lost all his relatives at once?

Charging the team takes a lot of energy. Ways more energy then one can get sucking coffee and crunching energy bars. Here the physical fitness kicks in.

Zig Ziglar says in his "How to be a Winner" program:
"I am so busy I don't have time not to run". When we exercise, we activate our body and get on a natural chemical high that lasts two to five hours. You're far more productive, far more creative and far more energetic. Finally, it feels good. And "Feeling good" is very contagious.

That is how maintaining physical fitness is a must have for an Agile Coach. Working knowledge of Fitness is only desirable.

Enough said. I am taking off for a run.

Why Your Code Sucks

This bold statement by Dave Astels is a catchy title of his article "Why Your Code Sucks".

Here is what amuses me: it's hard to find someone who disagrees with Dave's points when talking, but it's hard to find someone who truly agrees when coding.

How to Prioritize a SCRUM Backlog

A prioritized list of work itmes is a key artifact of any Agile development process. Take a SCRUM Project Backlog or eXtreme Programming User Stories as examples. Armed with such lists, the development team will be working on the most important tasks at any given time.

The problem, however, is that assigning priorities to real tasks on a real projects doesn't follow a simple recipie. The act of prioritizing is the art of prioritizing. And as with any art, there are always tips and tricks. I will share a few from my experience.

Before We Plunge

I assume that a "collection" of items and a "time estimation" are already done. We have produced the list is of items with routh estimations waiting to be prioritized. I recommend a brisk borders between "Collection", "Estimation" and "Prioritization" stages. Have the "collection" and "estimation" sessions officially "closed", switch to "prioritizing". Don't let the talk to drop back until we have the priorities done.

Backlog Prioritization

The default strategy a project owner tend to take is "everything is important". As a SCRUM master you will try and convince him to use priorities, and explain that the Project Backlog "is a prioritized list so that the item on the top is the single most important one, with items below that being successively lower priority."

But how to do it in reality? Let's get a feeling: for the lack of a real project backlog, try to prioritize a vegitables in a grossery store. It is obvious that Oranges (10 lb) beats Potato (20 lb). But should onion (3 lb) go before tomatos (5 lb) or just after? What about lemons and garlik (1 lb)? Man, it just feels silly. Frustrating. Makes no practical sence. Discriminates the whole prioritizing session. Doesn't work for me.

This is my approach: I assing priorities, usually ranged from 1 to 5. Why 5? Just cause I've got 5 fingers on my hand, and got so used to it.

On the first round we quickly go through the list and a project owner assing the priorities from 1 to 5 as he feels. Don't think too much on computing exact priority to an item: use intuition. When in doubt, give it 3, and move on. Make it fun, and move it fast. We are not going for precision for now.

The result of this quick round is already good enouth: look, we got some priorities! So many projects around work with no priorities AT ALL. We are light years ahead of our competitors! Cheer up! Great start!

The second round: refine. Compare equal priorities, escalate more important items, put down tasks that appear less important. Not sure? Appears equal? Fine, keep them. Try it out and you'll find that adjusting the original rough draft is easy. Few mintues later we are looking at a refined prioritized list that makes sence.

The final touch: count estimated time per priority, write them down on a whiteboard. It will look something like: Prio 1: 3 weeks, Prio 2: 12 weeks, Prio 3: 6 weeks, and so on. This simple math exercise is often incredibly revealing: a collective oh...s are often heard. We brought to our conscious mind how much time we are going to spend on what we named "important". But how much time we actually have? This conflict usually triggers another burst of thoughts, and some final jiggling of priorities.

At this point our list of items is prioritized just fine to use it for planning the iteration. And it doesn't take much time to do: we did prioritize lists of 20 items in 10 minutes.

Final tips

It is funny that some product owners, in spite of my "5 fingers" reasoning, reported that they can't work with more then 3 categories. Fine, I let them feel in a driving seat and give them 3 gear transmission: 1st, 2nd and 3rd.

The advanced technique to tackle less reasonable Product Owner who tends to say "everything is important". Give them one "1", a limited number of "2", and as many "3" as they want.

If there are about 20 items, 1-5 priorities work efficiently. * If it is more then 25 items, you are in trouble. Consider bucketizing.

Do the exercise of [re]prioritizing regularly, at least once every iteration, before or (preferably) during the iteration planning.

Why not #inlude #include into #include?

I have an empirical rule of thumb, which I bring to all my C++ projects:

Do not #include other #includes in header files.
The only thee excuses are:

Inheritance: #include a base class to inherit from it.

Composition: #include a class to use it as a value member object.

Standard types: #include STL and standard headers for standard types used in class declaration.

In all other cases use forward declarations.

It sounds straightforward, even trivial. But somehow I find myself explaining it again and again to C++ programmers, even to quite experienced ones.

So, why not include extra #includes in header files? Here is my "short answer":

Each include introduces a dependency. Extra unnecessary includes introduce extra ways many unnecessary dependencies. The application soon snowballs to a monolithic blob of well pressed spaghetti code, where everything depends on everything.

The order of .h files suddenly matters: sometimes it magically works because of the hidden includes. But this white magic becomes black magic. Someone removes an #include because noone seems to use it. This innocent change breaks things 5 header files away, it doesn't complile any more. So scared programmers don’t dare to change the order of #includes.

Any touch in any include file results in rebuilding the whole application. Nowadays the compiling time doesn't concern me (if it concerns you, check out Xoreax IncrediBuild). But the fact that the whole system has been recompiled concerns QA folks: the files now are not binary equal so all bets are off and they got to retest the whole application!



Code reuse, refactoring, and unit testing become almost impossible. Every class drags behind the entire code base.



For long answer, I refer you to "Large Scale C++ Software Design" by John Lakos.

The "rule of thumb above is a simple and powerful empirics to keep C++ code dependencies under control.

This is the way I teach C++ programmers not to #include #include files into #include files. What do you think? Am I doing something right? Leave your comments, please help me do better.