Ultimate feedback loop for bloggers...

Following up on my last blog post...  I started wondering last week if process savvy people in the work place were the same at home.  I was thinking about this when doing the recycling duties, i.e. avoiding to put garbage in the recycling bin and vice versa... 

There is a corrolation for me.  Then I thougth wouldn't it be nice to ask arround?  Then I found this little free instant survey tool... What do you say?

Code Review - How to miss the point...

Sometimes your arguments just don't weitght enough in the balance... 

I had the opportunity to "attempt" to contribute to Esther Schindler's article on Code Review.  She reached out on LinkedIn and I offerred help.  Now that I am reading her article I have many dissapointments.  Mostly related to not being able to make my contributions useful. 

Right from the get go I warned her about "meeting driven" code reviews.  These code review sessions where people each bring a tree's worth of paper and then beat the s**t out of the code worked on for a month.   They generally also spend a day reading a massive and scary amount of code before the meeting, a very costly process needless to say with limited output in general (at least from my experiences 10 yrs ago at Bell Northern Research and later at Nortel).

I could see from the other contributions she was provided with that this was the route she was about to embark when talking about code reviews.   Her article is filled with reference to "weekly review meeting"... or "meeting driven" code reviews. 

A couple good take aways are:

1. Jason Cohen from Smart Bear who is talking about a code review style that makes more sense, closer to what we believe in at Macadamian. 
   
2. Someone from Google who's is suggesting to do design review before you even consider doing code review. 

If I had to write that article I would put emphasis on what has helped us here to improve quality:

1. Small and frequent code review.  Get code reviewed on a daily basis.   This ensure you catch errors as soon as possible. 
2. Do design patch review - Just In Time Design - JITD (expression first heard from the mouth of Francis Baudet's sometime in the summer of 2008... ;-) )  This process, not only ensure that the first line of code will be a valid one, but also ensure that the deveopper starting the work took a step back and thought about the code to be written before to start writting it. 
3. Tools stack.  Do not neglect the use of proper tools to do the job, emailing a patch to each other works, but now a day there are very good tools out there.   

Last but not least, for code review to be effective you need:

1. this process to be part of your culture,
2. to foster an egoless programing environment, ensure understanding of the "what's in it for me" for your developpers,
3. to not only rely on this process to ensure quality.     

First and foremost, you need to not do code review once a weeek but have this process part of your complete breakfast.

ProjectTools part of the InfoWorld 2008 Top 100 IT Innovative Products

What a nice way to start the day! Yesterday Macadamian was awarded one of the top 100 company that have made use of technology to enhance their business.

Somewhere back in 2004 we started to be concerned by the effort that was required to be effective at project startup, monitoring and status reporting.

We envisionned that it would be a real challenge to provision all our projects with the apprioriate knowledge management technologies and to monitor them with consistency.

With now more than 100 projects starting and ending every year we can say thanks to this early vision. Needless to say that the pressure at being efficient and predictable was high and this is still an important concern at Macadamian.

"Let's automate all that". Our concern for efficiency and predictability gave birth to what we called Project Tools. What is Project Tools?

Project Tool is a software product that aims at:

1. Automating the innitiation of our project's knowledge management infrastructure (KMI). All tools needed for our projects are ready to go in no time (issue tracking, wiki, source control, mailing list, news groups, SFTP, continuous integration, IRC, etc...)
   
2. Managing access control towards all system of the KMI
3. Collecting projects progression metrics.
4. Reporting objective information on progression.
   

It is outside the scope of this blog post to go deeper about what it is, how it works and so on.

Today I want to say kuddos to everyone who contributed to this project.

Thanks to you Francois, Pierre, Benoit, Sebastien, Jake, Jimmy, Richard, Rafy, Karen & Irina. It would not have been possible to achieve this without you.

Last but not least, this award would not exists without Teresa who submitted ProjectTools to InfoWorld. Thanks to you!

This is so 1990

Sometimes I just can believe how people are getting stuck in their comfort zone. In this case, using folders as THE way of organizing email. I was 100% sure that this debate was over now, that folders (and trees of these) were bad, one of these evil creation of software people.

Coincidentally, I have a draft blog post which is totally the opposite of this guy's perspective. There is no way I could have been more effective at dealing with my Inbox content when I came back from vacation than through the Gmail client. (note that I have not tried Yahoo recently - last news was that this was simply another Outlook on the web)

His discussion on the whole unmanageable Inbox made me laugh too! Effective handling of incomming emails can be imroved through the use a powerful email client but most importantly I believe it is process thing. Looks like he did not buy into the Zero inbox concept I am referring to here.

I need to publish this "Back From Vacation" blog post...

Estimation

I am receiving the news letter from the TechRepublic. Most of the time I am only reading the titles and move on. Yesterday an article attracted my attention.

Use a pilot project to confirm estimates and lessen risks.

That is interesting in the context they describe where they have a project involving the execution of a task many times. If you made a substantial mistake at estimating the repeated task, sure you will slip big time.

In my humble opinion what is important with estimates is that:

1. You estimate everything you do.
2. You get everyone involved in the estimation process, especially the ones doing the work. This way your whole organization improves on this front.
   

Last but not least: you give exposure to your estimate and make it clear that they serve a purpose: being predictable.

your process -> my process

Picture this. I am back form Cape May with my family, we went to a restaurant altogether once. 18 of us, 10 adults, 8 kids from 5 families.

When we showed up they opened a new room for us. We sat down at three tables, one kids only, one adults only, one mixed. As you can imagine, a waitress nightmare.

When we started ordering we learned that they could not make 5 invoices, they could not simulate that we were using 5 tables, we would not have eaten at the same time (I did not get that one).

Seeing this I decided that I would take the bill and split it myself.

This is clearly a case where one's process has created a mess on another one's process. The ordering process had to win over the paying process.

It took me a few minutes to categorize the orders by family and and split the bill appropriately. Not a big deal but a clear annoyance when you are the one paying.

Could the waitress have avoided me this? I still think so. But what has happen? It is simple: a lack of consciousness that a failure at one process causes negative consequences onto another process down the stream.

This is something we are careful with at Macadamian. One critical area where this could dramatically slow down a development team is with the patch creation and code review processes. The former flows into the later. A failure at creating a high quality patch will add delays and waste in the code review process. We teach our joining team members about this in our Dev-101 training session.

Thou shalt create a high quality patch for the code review to go smoothly.

This sound like a no brainer. That said, it's easier to convinced someone of something when "there's something in it for me". In this case, a good quality patch will reduce your chance of rejection and speed up the code review process. Which is clearly in your advantage.

What was in it for the waitress? Simple, a more satisfied customer will leave a bigger gratuity.

The AgileJournal

The AgileJournal is publishing an interesting series of article about distributed software development in this week's issue. Have a look.

FIXME and TODO

Part of our development process is the need to show your code - by the mean of patch/diff files - on a daily (aka frequent) basis. Doing so, you are more often than not showcasing work in progress.

There are several benefits in enquiring frequent feedback on your implementation:

• optimizes design quality
  
• reduces potential waste caused by misunderstanding sooner than later
  
• promotes top-down software development

However, the team need to pay attention to the various TODOs and FIXMEs that are creeping into the code base. Unmanaged TODOs and FIXMEs will come and bite you at one point in the project if you are not managing them - this is stating the obvious - they can be evil to your project.

If you do not want to create tasks and estimates for each of these you have to keep them visible to all team members at all time. Some IDEs offer the meachanism to create warning in the build log when they encounters certain keywords, this does the trick nicely.

When this is not possible a simple: cat logfile | grep 'TODO' part of your build process will do the trick.

It also appears to be a good idea to ask your developpers to put their name beside their TODOs this way you will know who to talk to in two months when you will be wondering how to get rid of the TODOs.

Checklists in the real world...

This afternoon I understood the real reasons why checklists are important.

I flew a small Cessna-172 Golf Bravo Golf Zulu. Although I have been a believer in checklists - even though their use is challenging in the software world - I realized how critical using them can be and how useful they ought to be when comes time to inspect a plane before to take off.

No, my pilot was not holding a piece of paper and a pen, checking things off a list. He did not even know the exact number of items on the list. He just did the inspection required by this process with our possible death as a consequence of a checklist failure. This was enough for him to do it diligently. Thanks Marc!

We have many occasions to use checklists when creating software products, there are indeed plenty review processes at all phases of the job:

1. Specification
   
2. Estimation
3. Architecture and Design
4. Code
5. QA
6. etc...

I am observing that we sometime fail with checklists. Although we do it correctly most of the time, sometimes we still fail.

After today's experience, I believe that the answer to checklist success lies in a couple factors:

• Professionalism

Understand your role when reviewing and the impact you can have on the overall quality and risk mitigation.

• Agility
  

Assuming professionalism, you do not need to tick things off a list to claim that you have applied a check list. In doubt, go back to it when needed, revisit the checklist to confirm your understanding of the checklist.

Next time you are provided with a checklist, do not necessarily think that you have to print it or tick things off of it to use it, be smart and agile enough so you can perform the review process with diligence.

To help with applying checklist, imagine that you are reviewing a component of a plane that you will fly, I can assure you that you will likely do the right thing!

To get a feel of my flight load this into Google Earth, select it and hit play.

Powerful team collaboration using wikis

We have been using wikis for several years at Macadamian. After looking at a few options we decided to go with Atlassian's Confluence and are quite happy with it. It is not uncommon for customer's to tell us that they are more informed about what is happening within their Macadamian team that they are about their internal team.

What we do and how we do it with Confluence is partly responsible for this.

A recent verison upgrade has brought to my attention two plugins that are key in getting the most out of such a collaboration tools. Here what they are. Maybe your wiki provides similar functionality, if not let me know I can help. Macadamian is an Atlassian's partner.

Most visited page.
{popular:timespan=30d|events=create,view,update|
max=10|space=msp|types=page}

This provides you with the most frequently visited pages. In the context where your project assets are stored in your wiki. These pages are likely hot topics in your project.

Search
{livesearch:spaceKey=MSP}

Unless you are stuck in the 90' chances are that you are not browsing the web but searching it. This simple macro does this nicely for you, allowing to narrow the search to a particular space/project.

Last but not least, a wiki that offers the ability to create RSS feeds is very powerful. If your people do not like to go to your project home page to digg out recent changes, promote the usage of RSS feed.

The idea is that people will converge on your collaboration platform if there is something in it for them. If used properly, any project team member should find important project resources in the project wiki.

Oh, and finaly, do not neglect to train your people!

When an image is worth 1000 words...

Earlier this week Francois (from Cluj - Romania) and I (in Gatineau - Canada) could not use email to solve a situation, it was simply not the right tool.

We quickly got connected on VoIP and still managed to fail at understanding each other.

This is when I remembered http://www.twiddla.com/. Thanks to their guest trial thing, no accounts to create nothing, nada, niets. We were up and running on their online white board in no time.

We managed to resolve the situation in about 5 minutes, this wouldn't have been possible otherwise. When email and voice is not enough, an image might very well be what you need.

Realistically, this image above is not worth more than a couple dozen words to you but it was worth one thousand to us. ;-)

Killing inefficiencies one at a time... (Part-1)

This theme is based on Gille's famous "Twelves Weird Links of Christmas", he has been posting funny links on our Intranet, I am proposing a similar series on common inefficiencies in the work place.

This could be ugly, I am a sarcastic person (yep this played against me in the past), hopefully it will be more funny to you than anything else, however, if the hat fits you, I will propose alternatives to these inefficiencies so you can act on right now.

Jason Womac is earning a living telling people how to use Outlook. More recently (not that recent anymore) Merlin Man from Google posted his famous Inbox Zero


These guys got it right, there is a serious problem with email (we all know it) but it is pathetic to see how few people seem to be acting on this problem, the sad things is that there are solutions and they do not require a huge investment.

Somehow inefficiencies in managing email seems taboo, you can offer help as much as you want people will generally ignore you. Even when they are in a crying need for help.

To me, my email handling inefficiencies started to fade away with Womac's talk, I then reached more recently paramount when I got rid of Outlook in favor of Gmail. (more on my tool box later)

In the mean time, if you are recognizing yourself in the quotes below chances are that you are in need of help.

- I am often looking for that email but I can't find it anymore.
- My inbox has more emails in it that the screen can show.
- I am frequently wandering in Outlook folders, scrolling like a mad man, for this email.
- What should I be doing now, I know I have a few tasks hidden in my inbox.

(to be continued...)