Great Principles to Live By

Patricia Sellers posted an article up on her blog a few days ago about David Ogilvy, called by some "The Father of Advertising". In the article she shares the business advice David once told her. All of these are great, most of them strike to heart of humanity and leadership. Here are ones that relate most to me:

1. Remember that Abraham Lincoln spoke of life, liberty and the pursuit of happiness. He left out the pursuit of profit.
2. Remember the old Scottish motto: “Be happy while you’re living, for you are a long time dead.”
3. If you have to reduce your company’s payroll, don’t fire your people until you have cut your compensation and the compensation of your big-shots.
4. Define your corporate culture and your principles of management in writing. Don’t delegate this to a committee. Search all the parks in all your cities. You’ll find no statues of committees.
5. Stop cutting the quality of your products in search of bigger margins. The consumer always notices — and punishes you.
6. Bear in mind that the consumer is not a moron. She is your wife. Do not insult her intelligence.

I have six of the seven posted. I am not in advertising so I don't relate to that one specifically, the rest however are all great. They seem very relevant in today's tough market, with companies downsizing or looking to penny pinch. At the end of the day, good leaders will inspire others to to success.

Which ones do speak to you the most? Which ones would you add?

Good Technical Debt vs Bad Technical Debt

Early today I was reading a short blog post over at Scrumology on an age old argument about the fine balance of technical debt and releasing early.

Accumulate too much technical debt and your product's development will slow to a crawl attempting to service all the debt you have burdened yourself with. If you spend too much time keeping yourself debt free, you will miss your opportunity as your product's all important time to market is too slow.

So where do you draw the line?

I think we can draw a lot of parallels with financial world. As the article and its links point out, there is good debt and bad debt. Good debt is debt that builds value (business loan) or the opportunity to build value (student loan) and/or builds happiness (mortgage). Bad debt is debt accumulated to gain things that rapidly decrease in value; they worth less than the debt took on. Think clothes, or that new big screen HDTV.

For technical debt to be good debt you need to gain more then it will cost to retire it.

If you can close a big deal by adding a feature to your product within a really short time line, then it makes sense to do so. You after all have bills to pay, you can get feedback from your customers, and your team will get to celebrate a success and build momentum off of a big win. This can really help morale. (Of course adding features to win deals from specific customers is its own bag of worms, but let's just assume for the sake of argument that this feature is an awesome feature that you were planning on releasing in your next major release, but the customer couldn't wait that long.)

Another example of where technical debt is good debt is in cases where the product/solution is a one off, spending too much time and effort on a clean design is simply wasted effort and not needed. The code will rarely be modified. In these cases you only add to the cost of the product.

And in those cases where the products are not one offs, there is a concept of "luxury design" in my opinion. Especially when considering architectures that need to "scale" or other such "not needed yet" nonsense.

If you are creating a new product to release you don't need to worry too much about "scaling" upfront. Having scaling issues is a "good thing". It means you are successful. It means you have the resources and the business case to go ahead and put the right architecture in place so you can scale to the next level. But putting that in too early and you could miss your market window. You have missed your chance to build value and wealth, and to gain customers.

There are of course cases where you cannot accumulate that debt because the cost is simply too high. For example, adding a new feature to a successful ecommerce website where if the customer experience drops due to performance or bugs you get big a drop in revenues. Here you have the data to prove it that the debt is bad. There is a direct and immediate cost.

Of course with gobs of money and time, you can have the best of both worlds. With a proper user-centered design approach to product creation, your user experience team will be doing user research, and running user tests with mockups and wireframes while your team off building components and backend pieces. It's too bad that this is not more commonplace, users around the world would rejoice.

There is an old adage that nothing in life is certain but death and taxes, and in product development I will advance a new adage for consideration. "Nothing in product development is certain but technical debt and too early release cycles".

What do you think? Should technical debt be kept to an absolute minimum, or is a more pragmatic approach needed?

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?

Lead, don't follow

It's been a rough 6 months, heck, for many people it has been rough for a lot longer than that. The global economic crisis, economy melting faster then ice cream on a hot July summer day in Ottawa on Bank Street. Admittedly that is not saying much with this summer's unseasonably cool weather.

The fact remains, many people are feeling very uncertain about their jobs, job satisfaction is at an all time low for many people, fear for the safety of their jobs, or the stability of their employer is weighing heavily on many people throughout the country.

With all this doom and gloom what is a leader to do?

There is little a leader can do about the economy, and there is little a leader can do to create job security where there is none, but a great leader can do many little things to reassure his followers, and to bring some light to these difficult times.

Self-motivate
A good leader must be able to self-motivate when he is feeling sad, insecure, sick, or tired. This means that you are smiling, positive, and upbeat where ever you can be. This doesn't mean you are to be dishonest, or not genuine, just remind everyone of all the good things that are going on right now. If you cannot motivate yourself to get up, and get going then no one else will be able to.

Celebration time
Celebrate all victories, even the small ones. You don't have to throw a lavish party in Las Vegas (though if you do, please invite me), but a thank you card, a small get together after work, or even the a verbal pat on the back can do a lot to motivate people. Rewarding people in an ad-hoc manner with small little things will do wonders for morale, and little to your pocket book.

Invest in people
Don't stop investing in people. Don't stop investing in the tools and software your team needs to do their job. In the grand scheme of things, most of these things are "pretty cheap", but mean a lot to those that need them to do their jobs. This will help improve someone's job satisfaction. If you can improve your company's benefit package without busting the bank then go for it.

Communication
Keep the lines of communication open. Communicate the good, the bad, and the ugly with everyone in your company. Get up and out of your desk or cubicle. Talk to the people you are leading outside of your day to day job. Talk about the weather (rain), talk about sports, talk about the vacation you just had. Just talk. People will get comfortable with you and may talk about more then just trivial things, perhaps you will learn something that might keep that key player at your company.

These are four simple things that can help improve the morale of those on your team. There are many more small, simple, and yet thoughtful things that can be done to help your team's morale flourish.

What do you look for a leader to do in these tough times?

Hyper-Productive Distributed Teams?

Agile and distributed development are not supposed to be able to co-exist. Co-located teams are supposed to be one of the key tenants of Scrum.

If you have this (mistaken) belief, then you need to watch this video and presentation. I actually attended this presentation at Agile 2008 in Toronto. If I remember correctly, there were a few skeptics in the room.

The key points are:

• Ability to leverage benefits of distributed development
• Fully transparent teams
  
• Seeding new teams with talent from existing teams
• Automated tests
• Continuous integration, nightly builds, automated tests, performance testing the whole 9 yards
• High quality developers in both locations
• A tight definition of done
• Travel between the two locations
  

I think the travel between locations is a key aspect of their success, remember that both "sides" of the teams have to be equal. Equal in "power", information, and influence, and treated equally in terms of inconvenience. The "remote" guys shouldn't always be the ones staying at the office late.

Another important point to distributed Agile, or even Agile in general is that practice doesn't make perfect, practice makes habit.

The presentation wraps up with the potentially explosive statement that distributed Scrum has more value then local Scrum. What do you think?

Performance Reviews for Developers

It is getting close to that time of the year again at Macadamian, that's right, review time. Luckily however, it is mid-term reviews instead of the full year end reviews. This time of year always gets me thinking about how we review our employees, and to look around for new ways on how reviews could work.

This year I stumbled across the Cockburn-Boehm Levels of Developer's Competency. The focus of this approach is not measuring performance on generic skills, but rather in terms of how to approach software construction projects. It's not about the skills of developers; rather, it's about the characteristics of the developers.

There are 5 basic levels in the scale, higher is better:

1. Level 3: Able to revise methods and methodologies to fit unexpected and unprecedented situations.
2. Level 2: Able to tailor a method to fit a new situation that is expected.
3. Level 1A: With appropriate training, able to perform discretionary method steps, such as estimating features, tasks, and user stories, complex refactoring, etc. With training, can achieve Level 2.
   
4. Level 1B: With training, able to perform simple method steps, like implementing methods, simple refactoring, following coding standards etc. With experience and training could master some Level 1A skills.
   
5. Level -1: May or may not have technical skills, but is unwilling and unable to collaborate in a team environment or follow shared processes. You don't want these people on your team.
   

Then name of the last (and worse) level is illustrative and telling. You would think it should be "Level 0" based on the pattern, but someone is a Level -1 is not a zero, because not only do they not contribute to the team, they actually drag the team down.

Developers at this level decrease the productivity of the team, either through their lack of technical skills, or worse, their poor attitude. A positive, constructive, can do attitude is more important than technical skills. You can usually train people on technical skills; it is much harder to change someone's personality.

Leadership in hard times

It is much easier to be a leader when times are good, when business is plentiful, when the sky seems the limit. The strains put on a leader in bad times are much greater, and this is where you you separate the leadership wheat from the chaff.

A co-worker of mine sent me a newsletter that had a great article on how to lead when times are hard. I hunted around a bit to get the corresponding web page for this article so I could share it. If you are leading people in a company highly recommend that you read this article. If you are not responsible for leading anyone, read this article.

When Macadamian recently had to make some hard decisions, I agonized on how to communicate this to the teams that worked with me. I spent hours thinking about how to effectively communicate the rationale, the plan, and how we can together move forward and succeed. It was the hardest thing I have ever done and I am glad I spent the time to prepare for it.

Is your company experiencing hard times? What are you doing to be an effective leader during this time? What behaviors have you changed?

Whatever it takes

(Well almost.)

Pawel Brodzinsk over at Software Project Management wrote a blog about why developers should work on crappy machines. To sum the article up, developers should use crappy machines to force good programming practices on them, and to some extent, good usability. I am sure that most of the reasons behind the post are related to the frustration users feel for having to deal with bloated, slow performing software, or software that doesn't display right on lower end resolutions; and in that, I wholehearted agree.

However, where Pawel and I differ is how we should deal with that. There are two main complaints in the article,

1. Bloated memory requirements of many applications
   
2. Usability of applications on smaller screen resolution sizes

One of my most important missions as a project manager at Macadamian is to make sure that my developers can work as fast as possible. I don't mean to hack out code without regard for technical debt, but that their tools and the processes don't slow them down. Yes process is necessary, but the right amount of process can make the difference between highly motivated, self-organizing teams able to efficiently collaborate between distributed locations, and teams that are swimming in quicksand unable to make a release to save their lives, or their companies.

Their tools need to be top notch, their development machines are dual or quad cores, 4 gigs of RAM, big and fast hard drives, and dual monitors. And yes, some developers still complain about the setup :) We also invest in tools like IncrediBuild to build code faster, and IT infrastructure that can allow you to copy large amounts of data across the network as fast as possible.

I don't want my very talented, and very expensive developers wasting time on waiting for projects to build, new versions to push to production, or code to checkout. If a fresh build takes much more than a 15 minutes to build, you have just lost thirty or more minutes to a game of foozball, a Starbucks run, or a YouTube foray.

So how do you deal with such things like usability, and performance requirements? Simple, engage in formal usability work and create formal requirements on performance that are monitored and enforced by your testing team.

A proper usability team cannot only design UI that can scale to multiple resolutions, but is actually usable by the end user. They can apply actual scientific research to solve usability problems. And you will get the added benefit of having wire frames that your developers will be able to rapidly develop with less iteration and confusion. A picture is worth a thousand words!

This leaves only performance requirements that need to be tackled. Developers can follow requirements (no really they can!), especially when monitored by your testing team. The memory and processor usage, install size, and overall performance characteristics can be defined in the project requirements. The testing team can then apply tools and process to ensure that these are met, and log bugs if they are not.

An excellent testing team takes responsibility for the overall quality of the application, they don't just run test cases. This will mean they will ask questions like "All I did was log into the application and it is using 123 megs of RAM. Why is it so high?". Your testing team does look for memory and other resource leaks as part of their testing don't they?