Cyclomatic Complexity Debunked?

I have always taken for granted that code with a higher cyclomatic complexity number (CCN) is more bug ridden then code with a lower CCN. This has been taught/assumed for many years. and apparently the old adage about assumptions (ass-u-me) holds to be true again.

I was doing some quick research to find a free tool I could use to measure the CCN of my project as part of its continuous integration environment. This is a best practice of many agile practitioners, and good software engineering to boot. According to this article however, it isn't as useful as it was assumed to be.

What the survey did not show, however, is that code complexity does not correlate directly to defect probability. Enerjy measured complexity via the cyclomatic complexity number (CCN), which is also known as McCabe. It counts the number of paths through a given chunk of code. Even though CCN has limitations (for example, every case statement is treated as equal to a new if-statement), it’s relied on as a solid gauge. What Enerjy found was that routines with CCNs of 1 through 25 did not follow the expected result that greater CCN correlates to greater probability of defects. Rather, it found that for CCNs of 1 through 11, the higher the CCN the lower the bug probability. It was not until CCN reached 25 that defect probability rose sufficiently to be equal that of routines with a CCN of 1.

There is no correlation between CCN and bug counts for code that has a CCN of 1-25! For software engineering wonks, and process improvement gurus this must come as a bit of a shock. So I ask the readers, is the measurement of CCN a sacred cow that should be slaughtered with the rest of those asinine bovine as we move to a more agile and lean software development process? Or is it still a useful tool that should be kept, just interpret the results pragmatically?

Who wags who?

It's an old joke to ask if the dog wags the tail, or the tail wags the dog. The saying fits in many contexts outside of media, including the age old battle between testing and engineering, or the usability of the application, and the technical design of the application. Do the user experience (UX) folks design without regards to the technical feasibility of their work, or does the engineering team dictate design by imposing technical constraints?

Jumping in the way back machine, five or six years ago I was working on a large web application, it was Macadamian's first project where the engineering team implemented the output of an interaction designer. When asked, I told the designer to go ahead, don't let technology limit your designs. Sure enough, we ended up creating an impressive web application (see left) with all the bells and whistles of a rich internet application, all back in 2003. I also lived at work for weeks implementing all that cool stuff. I wish I had read this article back then!

At Macadamian, we have had a world class user experience group in-house for the past few years. Learning to work with this new UX group was not an easy task for a primarily engineering and quality assurance company. It took more then a couple of months to work out the process for collaboration between UX and engineering. Everything Tim has discussed we have also learned, the hard way.

Being that I come from the engineering side of Macadamian, and that most of the costs of the project are on the engineering side of the project, the point that jumped out at me the most was the suggestion to listen to the concerns of the developers.

The first few combined projects between the engineering and UX group resulted in significant schedule delays and cost overruns on the engineering side due to really good, really cutting edge, and extremely difficult to implement designs coming out the UX group. When the estimates were created, the estimator put time in to basically add some form fields, text, and maybe a graphic or two. Pretty naive.

Unfortunately (or fortunately depending on your perspective), the customer saw these designs, loved them, and then expected to get them for the same price as that form with 23 checkboxes and 97 form fields. The complexity and innovation required on the UX side was not expected on the fixed-bid engineering side.

To solve this problem, a simple (and in hindsight, obvious) process improvement was made. The developers had a chance to look over the designs prior to the customer seeing them. This allowed any potential design decisions that would adversely impact the schedule and cost to be caught, and fully discussed prior to the designs being approved by the customer. It wasn't that engineering had a veto over the design, it was allowing the usability group to be made aware of any potential technology challenges to be discussed earlier in the cycle.

This allowed the two groups to work closely together and solve any potential issues. Sometimes the UX folks were able to convince the developers of the critical nature of the particular design, and other times the user experience group came up with another solution that was just as usable, but much easier to implement. However, don't confuse this approach with one where technology drives what personas can and cannot do with the product, that would be a mistake. User needs have to drive the design.

Innovation Story: Learning From Pixar

Last Thursday I was researching innovation to prepare for an upcoming OSEF event being hosted at Rove Mobile I came across a really interesting article about creating a culture of innovation at Pixar. Continuing in the theme of the last few posts I thought it would be interesting to examine what Pixar thinks, and to see what, if anything I can apply here at Macadamian.

Brad Bird distills 10 simple rules for fostering innovation:

1. Herd Your Black Sheep
2. Perfect is the Enemy of Innovation
3. Look for Intensity
4. Innovation Doesn’t happen in a Vacuum
5. High Morale Makes Creativity Cheap
6. Don't Try To “Protect your success”
7. Steve Jobs Says ‘Interaction = Innovation’
8. Encourage Inter-disciplinary Learning
9. Get Rid of Weak Links
10. Making $$ Can’t Be Your Focus

All these points resonant with me, but, let's focus on only two.

Look for Intensity
When I am interviewing people to potentially hire at Macadamian I look for people that are smart and have that spark in their eyes, that spark that denotes a deep passion for technology, and for what they have done and what they will do. I am sure that everyone at Macadamian looks for these same qualities, but when I looked on Confluence for the "Type of People we are looking for" that attribute wasn't listed, so the wiki being a wiki, I changed it.

Intense people want to do a fantastic job, there is no laissez-faire I don't care attitude. These people are passionate about the products we are building, they aren't just working on a project, they are building an amazing product. These types of people will "own" the product, they will talk to the customer and suggest features, or other ways to improve it. They want to build the best, most innovative product they can. This is a great attitude, and one of the key differentiators between the average, and the above average.

High Morale Makes Creativity Cheap
Not only does high morale make it easier to be creative, high morale increases productivity by several orders of magnitude. Morale is directly related to the leadership of the immediate manager, and of the company as a whole.

A good leader managing the team can go along way to improving morale via their positive attitude and their fair dealings with the team. I could go on and on about leadership's impact on morale but I would run out of space. Suffice it to say that a good leader can go along way to making a good team.

Of course the organization also has a role to play, the organization needs to create a culture that rewards people that take informed risks, works hard to get the employees involved and feeling informed, that people have the right tools to get the job done, shows genuine concern for all their staff, and gives appropriate praise and recognition for the good work they do. After all, you want to reward the good behaviour, not just punish the bad.

These two points resonated with me, and these are two that I will focus on here at Macadamian, to reinforce and improve our way of doing things with respect to these. Of course the rest are good too.

Consistency versus Excellence

A quick question for you all, if you are delivering every single project consistently, with good consistent results, have you achieved excellence?

At one point in time I might have said yes, but after reading this article I will have to say no. Unless you are in a field where everyone else are a bunch of numskulls, being consistent merely means meeting your customers expectations.

Of course being consistent is good, it means you are delivering your product or service in the same manner, allowing you to look for ways to reduce errors and flaws by providing new and improved processes to catch and eliminate them. That being said however, you put too many processes in place your team will look and act like a bunch of dumb robots, carefully following well defined procedures fearing to stray outside of the bounds. Hardly sounds like a fun place to work eh?

Excellence on the other hand is about going above and beyond, about not just achieving customer expectations but blowing them away. This type of performance requires passionate and driven people, people that will own the product and be devoted to its success. When pursuing excellence processes are only a tool to achieve a goal, they are not the goal themselves. Processes will never be emotionally tied to the product's success, only people are.

People drive excellence, processes drive consistency. If you are looking for excellence then don't look to process, look for passionate, driven people to push hard to always try and achieve more.

It’s a small world after all

Sometimes it’s just amazing how interconnected we all are.

The other day I was talking about tools and methodologies with one of our new customers. This customer is using Scrum for their methodology, and as we were discussing how to integrate our team with their team the concept of how to virtualize the post-its and index cards that are so welcomed by the Agile community came up.

Luckily, the customer is already using Jira, and to add the index card virtualization they are using a tool called GreenHopper. To read more about GreenHopper click here, and here.

So I looked at the tool I could see a possible fit in our methodologies here at Macadamian, see its potential I talked to our Director of IT and Process Improvement about possibly trialing the software.

At this point I found out he met the company who makes the tool at a job fair in Sherbrooke earlier this week and talked about some of the Jira plug-in they make.

Its always amazing to see how interconnected everyone is.

Sometimes I feel like Bill Murray

What now seems like a very long time ago, Bill Murray starred in a little film called Groundhog Day. Sometimes I can really relate to that film, we keep doing things over and over.

At Macadamian, we take a lot of pride in "Constant Improvement", in fact its one of the Cs in this blog title. As part of this process, at the end of each project we do what we call a "Phoenix Session". Also known as a project post-mortem. One of the outputs of this process is what we call the "Lesson Learned". Usually, we learn at least one lesson, sometimes two.

The problem with this process is that the "Lesson Learned" gets documented in Confluence, and becomes "Yet another page no one ever seems to read". Many of these "Lesson Learned" are very insightful and useful, and while we send them now to the entire operations leadership, we fail to teach them to our project champions.

This is true for PL101 training in general. We are all so busy, we often rely on what many call OJT. Out of the most recent batch of "Lessons Learned" there was one re-learning what was actually documented in the "Client Deliverable" process. Documented on Confluence. Oh, and its actually the first page in our PL101 training.

I don't blame the champion for this, that person didn't have the knowledge or the skills. I blame us. We as an organization have to better support our champions, PLs, and new developers.

This will help them not feel isolated and left out to dry. We already have a mentoring program for new employees, now we need to extend this to new champions, PLs, and of course, PMs.

Just make a decision

I am pretty big on leadership, and I stress the importance of it whenever I can. This isn’t to say that I am the perfect leader, far from it. I make mistakes, and through these mistakes I hope to improve.

I once told a young cadet that was facing some difficult leadership issues at the unit that the mark of a good leader isn’t in the mistakes you don’t make, but how you learn from the ones you do. It seemed really profound when I told this to the cadet at 3am one cold winter night, and in the light of day, it still seems pretty good.

At Macadamian, this concept of constant improvement is enshrined in our values; in fact it’s the last “C” in “TRACC”. It permeates everything that we do and every aspect of our company. Every new hire goes through training that discusses our values, and we discuss that as part of the employee review.

However, you can’t make mistakes if you never make a decision. A person who never makes a decision is pretty common affair, but they are not really a leader no matter what their business card says.

A leader must be confident, and make sound and timely decisions, you can of course rely on experts in your team for information, but in the end it’s YOUR decision to make.

In almost every case, it is better to make a decision when you have 70% of the information then to make the decision when you have 100%. You will never get 100% of the information, and if you make that decision at 70%, most of the time you will be right. Trying to wait until you get 100% of the information will lead to unnecessary delays, team stoppages and wasted effort.

So just make a decision.

Overtime as an implied order

Every month the Macadamian Leadership team meets for some D&D. No, it's not Dungeons and Dragons, rather it is discussion and debate. Our topics are wide ranging, but always focused on one of Macadamian's core values, constant improvement.

Some of the topics we have covered in the past include:

• Project tracking;
• Software Development Process;
• Estimation Process;
• Usefulness of patch-a-day, and code reviews.

Today's meeting was about what strategies and lessons have we learned that can bring a project from red back to green.

We discussed a lot of different strategies, ranging from team member changes (addition and removal), to adjusting the forecasted dates and communicating the new delivery dates to the customer.

One of the Project Leader’s suggested that it might be better to do overtime rather then add a team member to the project. The PL argued that a new team member would distract the team during the ramp up period, and it would be awhile before the new team member was productive. Of course these are all true.

There is just one problem with asking for/requesting overtime, it is really easy for a team member to perceive that as an order.

Asking for overtime can be perceived as an implied order as it is a superior asking a subordinate for something, even when you preface it with “You don’t have to…” or “Feel free to say no...” etc. Most people want to please their manager, and will do what is asked for/requested even if they don’t want to.

Other examples of what could be perceived as implied orders include the manager saying something like "There is more work left then time", or if the Project Leader starts working overtime on his own when the team knows they are late.

If you need to ask for your team to work extra hours these simple suggestions will help:

• be sure that you meet with them in person
• ask them for feedback, and thank them when they give it;
• make sure that there is a compensation plan in place for those extra hours;
• reassure them that if they don’t work any extra hours, there will be no negative consequences (and mean it);
  
• don't expect an answer on the spot;
• thank them regardless of their decision.
  

Of course, a healthy work environment where the employee is trusted, respected, empowered, and overtime is the exception rather then the rule will also help alleviate the perception of an implied order.