The Mindset

When I was just starting my way as a software developer I worked in a team writing simulators and other tools for testing engineers. Most of the tools I wrote were 100% my creation. I designed them, I wrote them, and I provided support for them. This gave me a chance to control almost every aspect of development (except, of course, for the requirements and the deadline). Most of the time it was a lot of fun. Most of the time…

One of my responsibilities was to provide support for one of our mythological creations. It was the it-can-do-anything-you-can-possibly-imagine simulator (but we just called it: the ICDAYCPI-Sim). Almost every testing engineer in our department used it. Needless to say that unlike most of the things I was responsible for, I didn’t design this tool, and I didn’t write it. In fact, for a whole year I didn’t even see it. Most of the time it worked perfectly well for most of its users. Most of the time…

Then, one morning as I opened my mailbox, my biggest fear became a reality. There, at the top of my inbox, was a mail with the subject “urgent fix needed in the ICDAYCPI-Sim”.

At first, I panicked. After a couple of minutes, I pulled myself together and did what every software developer in the world would have done: I fixed myself a strong cup of coffee. Then, I fixed myself another one. I went back to my desk and started to search the mythological project. Even that task was not trivial. “Good start” I thought to myself.

When I eventually found the project, I started to wish I hadn’t. I gazed at the IDE-less UNIX shell, which was filled with what seemed to be an endless list of C files. Each file contained thousands of lines. And naturally, there was not even a single README file to provide me a hint on where to start. I knew the fix I had to implement was extremely simple. I just had to change the length of some field in the parsing sequence. How hard could that be? Well, it can be extremely hard when you have no idea where to start looking for the relevant piece of code.

I stared at the screen for a few more minutes, and then I did the next thing that every software developer in the world would have done: I launched the debugger. A week later the fix was implemented (it took me two more days, though, to build the project, but that’s for another post).

***

Wikipedia defines a debugger as “a computer program that is used to test and debug other programs”. Debugging is then defined as “a methodical process of finding and reducing the number of bugs, or defects, in a computer program”. Now, let’s be honest: how many of us are using a debugger for things that have nothing to do with finding the source of a bug? Unfortunately, most of us do.

The debugger seems to be the number one tool for understanding a piece of code. Many of us use it whenever we come across a piece of code we don’t understand. This may be a legitimate approach when you have a badly written undocumented piece of code you have to work with. The problem is many of us keep writing such code because we subconsciously (or consciously) assume a debugger is the perfect tool for understanding code. Well, it isn’t.

Trying to understand a piece of code using a debugger, stepping into each line, and therefore reading each line in isolation, is a tedious and ineffective task. It’s like trying to understand a picture by seeing one pixel at a time. When code is self-describing and its high-level structure is intelligently documented, it is relatively easy for someone new to the code to find his way in it.

But there are even stranger uses for a debugger. Some developers, for example, use a debugger to verify that their code works correctly. The technique is quite simple. You write a simple main method to launch your code and provide it with some input. Then, you use a debugger to follow the execution of the code step-by-step. All this is done with various inputs and without any reported bug you are trying to locate. You are just “testing” your code. How long does each such test take to execute? Very long! Believe it or not, some developers out there use this technique as a replacement for automated unit testing. No, it’s not because the tests they want to use are hard to automate. It’s because they truly believe that using a debugger is the most effective way to test your code. Period.

***

To be honest, the way we use a debugger is just one example of a wider phenomenon. Many of us misuse tools. We think we are leveraging a tool by using it in some innovative way. But most of the time this misuse leads to a waste of valuable time and resources.

There’s a lot of room for innovation even when it comes to the way you use your toolbox. But what ever you do, you must always verify that you are on the right track. There’s nothing innovative in using a debugger for unit testing or for trying to understand the structure and logic of 100,000 lines of code. Unless, of course, you’re trying to come up with innovative ways to waste time.

What do police officers, vultures, hunters, guards, predators, and cleaning people, have in common? And what they are all doing in my blog?

[Warning: not too good metaphor ahead] When I was a teenager, I thought all teachers have one purpose in life: to hunt me! And guess what, all my friends felt pretty much the same. Some of us were not-so-good students, and some of us were better. But none of us understood why all the teachers were constantly trying to find what we did wrong. They were always trying to find our mistakes — just waiting for us to slip. And surprisingly enough, they always managed to find something.

Now I understand, of course, that my teachers were in fact there for me. Their goal was not to hunt me, but to help me succeed. Some of them were better than others, but they all had the best intentions. Maybe, if my friends and I had been a little more cooperative, the results would have been much better. But we were teenagers, so what can you expect?

So, (back to the real world) now we are all grown-ups, and some of us are in the software development business. Some of us became software developers, while others became… the new enemy.

Here’s a little experiment you can do in your company. Take a group of testers and another group of developers. Ask each person to write down a metaphor describing his role and another metaphor describing the other group. Chances are that the most common metaphors relating to the testers group will resemble the list above. What’s even more striking is that both testers and developers see eye-to-eye when it comes to the tester’s role. The metaphors most of them choose are very emotional. The metaphors are also extremely negative. If a tester is a vulture, a police officer, or a cleaning person, what is the developer? Prey? A felon? Someone who produces garbage?

The way we see ourselves, and the way we see the people we work with, shapes what we do. If we, as developers, feel we are constantly being watched by people who are just waiting for us to make a mistake, being cooperative is the last thing we will do. If testers feel they are always cleaning up the mess developers leave behind, the last thing they want to do is hear what developers have to say. When the working relationships between us are that charged, we all waste valuable energy on “dealing with” the other person – energy that should have been invested in creating a better product.

Am I just being naive? Can testers and developers really work together? Well, it does happen — sometimes. Some testers and developers out there actually feel they are working together towards a joint goal. And you know what? They are actually doing a better job.

Can you imagine developers helping testers come up with innovative test scenarios? Can you imagine testers helping developers design unit tests? Can you see in your mind developers and testers openly talking about ways to deliver a better product? Believe me, it has been known to happen.

Developers are the best people to know their code. They usually know deep inside which parts of their code are likely to fail and in which cases. If testers are indeed the enemy, why on earth should developers share this intuition with them? But if testers and developers are both on the same side, this kind of information can help testers invest their effort where it can really make a difference.

Testers have the best knowledge when it comes to testing. If developers are “the people we always clean up after”, why on earth should testers try to communicate with them? But if testers and developers are both on the same side, helping developers design better unit tests will cause the product to be delivered to testing in a better condition.

Of course, testers should be independent. Testing should not be limited to what developers think should be tested. But open communication and constant information flow between developers and testers is the best way to optimize testing resources. Open communication with testers will also help developers improve their skills and do a better job to begin with. Developers will learn to see things from the testing perspective and, in some cases, even from the user’s perspective. How bad can that be?

When you come to think of it, managers and developers should feel they are on the same side too… but that’s for another post.

Here’s a little party trick for true geeks. Take your company’s coding standards. Count the number of times an ‘_’ character appears in it. Multiply this number by the maximum number of lines allowed per function. Add the number of times the word “comment” is mentioned in the document. Divide the result by the number of times the word “meaningful” appears in the document. And finally, multiply the number you received by the number of people in your company who actually write code that fully complies with the standard. [Now, imagine I close my eyes and do some telepathy gestures] your final result is… [drums]… 0.

Now, here’s the greatest thing about this trick. If your result was indeed 0, every geek in the room is astonished by my amazing telepathy powers. But what if the result was different, you ask. Well, think about it. How the heck did I know your company has a coding standard document?

Okay, okay. Because you are all loyal readers, and I just know you can keep a secret, I am willing to break my magician oath, and tell you how I knew that. You see, (are you ready for this…) every software company in the world maintains a coding standards document. If you think your company doesn’t, believe me, somewhere on a long-forgotten location in your storage system there’s a dusty document that carries this exact title.

So, if every company in the world maintains a coding standards document, how come there’s so much buggy, unmaintainable, unreadable, and complex code around?

Well, you really caught me in a good mood, so I’m willing to share yet another industry secret with you. No coding standard in the world will turn your code into quality code. If you want to know why, Tom Harris’ latest post is a good place to start:

“The developer has to understand the warning, standards item, or comment, and then decide:

1. How to change the code to comply, while not breaking anything else
2. When to make the change, in order to meet the deadline for the rest of the features/fixes in the delivery

The coding standard is no help for either of these decisions. Both decisions are context-sensitive, and require guidance (or mentoring — call it what you want) to decide correctly.”

No set of black-and-white rules can ever define what quality code is. Good code and good design are both context-sensitive. This context changes not only between projects – it often changes even during a project. The only way to master the craft of producing good code and good design is to gain experience in a guided manner through learning and mentoring.

In his article, Tom suggests that any standard must be accompanied by a learning effort. I would take this idea further: a true mentoring effort aimed at nurturing professionalism, gaining experience, and developing intuition, makes any coding standard almost redundant.

Most coding standards are being used as a replacement to professional common sense. They are perceived as a recipe for writing good code. Clearly, they are not doing a great job. In that sense, relying on coding standards to improve code quality is avoiding the real challenge: helping developers develop a genuine professional common sense of their own. Memorizing and following a set of black-and-white rules cannot do that. Sooner or later the hard-coded wisdom of your coding standard will not be able to guide you through the complex and dynamic reality you work in.

So, where does this leave us? Surprisingly, it leaves us with yet another great trick. Are you ready? Take your company’s coding standard (that’s right, I know you have one). Leave your office, and look for the nearest shredder. Shred the document. On your way back to the office, find yourself a professional developer to observe, work with, and learn from. Now wait for the magic to happen…

***

Further reading:

• Coding Standards on the Hitchhiker’s Guide To Software Development.
• The Root Of The Matter
• Mastering Context-Sensitive Domains

A couple of days ago Kathy Sierra wrote about the difference between who companies say they want to hire and who companies actually want as their employees.

When I read Kathy’s post it sounded awfully familiar. Sure, I have seen the exact same phenomenon with my own eyes: companies allegedly looking for smart, innovative, independent people, while in fact they encourage people to be robots. But that was only part of the déjà vu feeling I had. Because companies actually say many things they don’t really mean.

Commitment to quality and professionalism is a common example. I doubt if any of us ever heard a CEO say he couldn’t care less about the quality of his products. On the contrary, CEOs usually say that quality is a top priority. But many CEOs don’t put their money where their mouth is.

And why should they? Long-term thinking does not come easy. It is much easier to manage a company one day at a time. Or at least one quarter at a time. So, whenever there’s a tough decision to make, short-term prevails. Quick and dirty was once saved for “special events”. It was an extreme measure for extreme circumstances. Nowadays, it is a mainstream methodology for many companies. How else can you increase productivity to meet the ever-growing demands of your customers? You have to be quick now and take care of the dirty later. But as every manager in the world knows deep inside — later never comes.

But as long as the financial results of the next quarter are satisfactory, everyone is happy.

So, as a service to our top-management readers, here is the complete list of why quick and dirty is the best methodology for your company:

1. Quick and dirty solutions always work. At least for a while. But chances are that by the time they cease to work, it won’t be your problem any more, will it?

2. You will never need to clean up the mess. You will always have subordinates to clean it up for you, won’t you?

3. Your customers will never notice. When it comes to software products, we are all used to bugs, crashes, loss of data, and extremely unusable interfaces. And we are the perfect customers — we never say anything, do we?

4. Your investors will be happy. Who cares about the long-term as long as you sign contracts and sell products? Investors want to see their money now, don’t they?

5. It always seems like something is happening. There’s a constant frenzy. Everybody is working around-the-clock. You are certainly getting value for your money, aren’t you?

6. That’s what your competitors are doing. You have to follow their lead to be competitive, don’t you?

7. Business reality is too dynamic. You have to be quick (and dirty) to respond to all these changes. You simply cannot make long-term plans in such a dynamic reality, can you?

8. We have innovative people. They can innovate their way around any crisis we come across. This is what true innovation is all about, isn’t it?

9. How can it be wrong? After years of practicing the quick and dirty methodology and getting away with it, there is simply no chance in the world there’s a better way to do things, is there?

10. _______________________. I’m leaving this one for you to fill in, because everyone has a secret justification for doing it quick and dirty no one has ever heard before…

So why can’t you find a single CEO to admit that his company’s motto is delivering quick and dirty solutions? Probably for the same reason no one says he wants to hire robots. It just doesn’t sound good, does it?

Well, it has been three days since my Hiring Great Developers? post. During this time an interesting discussion took place both on this blog as well as on others. I usually try to respond to most of the comments posted here, but this time I’ve decided to step back and let the discussion roll. Now I feel it’s a good time for a follow-up. I hope it will address most of your comments, questions, and insights.

***

The Good

I really can’t tell how good the developers in your shop are. All I know is that wherever I look I see good developers just waiting to be great. Sure, there are some “rotten fish”, as Reg Braithwaite insists on calling them. There will always be in any profession. But they are as rare as the prodigies I mentioned in my previous post. Few developers have no professional aspirations. Most developers are eager to learn and evolve if only they are given the chance.

Some of your comments, as well as Joel Spolsky’s article, referred to students and interns as having the greatest potential. In my experience, developers who are already five, ten, and even fifteen years in the industry, can be as eager to learn as an intern.

Some people can learn and evolve by themselves. But many are already caught in an endless loop of tight schedules, overloaded projects, and no guidance whatsoever. I daresay that these people constitute the majority of our industry. And that’s why so many projects fail (or experience difficulties). It’s not because the people are not good. It’s the basic infrastructure which is flawed: there is no commitment to professionalism, no guidance, no practice.

Yes, we all need to practice. Tom Harris said it very clearly in his comment:

“In orchestras, the violin section people are indeed good violinists. But they all practice for hours a day (something that’s missing in software, but mentoring could substitute for it) and everyone learns from the first violin”

The Great

So, naturally you need a first violin in your orchestra. And that’s where the great developers come into the picture. It’s perfectly reasonable for you should to try hiring great developers. But chances are not all your developers will be great. With all the respect I have for Google, I find it hard to believe that all their developers are “the best”.

And it is perfectly natural. The message is that you can still do something about it. No, I don’t mean you should fire your good developers and replaced them with great ones. What you should do is try to turn as many of your good developers as possible into great ones. And when you have some great developers on board, that’s not so hard to do.

With a good mentoring plan, your great developers can help the rest of your team improve their skills and experience, and become professionals. But without true commitment to this idea, your great developers will fail to make a significant difference. To borrow Reg Braithwaite’s metaphor, they will merely add some Wasabi to your not-so-tasty dish.

The Better

Of course, balance is needed. And that’s why I explicitly said you should look for your best developers and hire more of that kind. But at the same time, you should embrace the opportunity to work with the rest of your developers and turn them into great ones as well.

The problem is that in most shops no one is talking about mentoring. Fewer shops are practicing it. And why should they? It’s a lot easier to hire some great developers, isn’t it? Well, no!

Ongoing mentoring is your only option if you really want a strong and stable team of developers in your shop. When mentoring and improvement are part of your organizational culture, you create more than merely a group of individual professionals — you create a community. You create an environment for people to grow in. And this is priceless in terms of motivation, productivity, and loyalty.

Remember, you already have good people on board. You should keep trying to hire great developers as you find them. But don’t settle for good, and don’t settle for great either. Always look for a way to take what you have and make it better.

Stop whatever it is you’re doing. There’s a new buzz in town.

In our ultra-dynamic industry, yesterday’s Holy Grail is today’s old news. A couple of days ago I wrote about Googlism as the new emerging religion, and what do you know, I’ve just discovered the signs of a new one, already creeping into blogs, articles, and eventually management meetings.

This time we have really found the answer to our collective prayers. The age of looking for the perfect development process might be coming to an end. After years of trial and error, many now see that the quest for the ultimate process is futile. But none of the problems we are facing was actually solved. So, people are thinking, we must look elsewhere.

And thus, after years of Agilism – the people-oriented hi-tech-religion – our industry managed to take the next step and mark its own people as the source of all the world’s problems. And we naively thought the process was bad. Silly us. No, no, no: it’s we, the people, who cause all the trouble.

It started with Joel Spolsky’s article about the quest for Finding Great Developers. Joel didn’t say it explicitly. He just wanted to help you hire the best people for your company. Nothing wrong with that. Then, about a month later, came the by-now-already-classic-article by Steve Yegge, describing Google’s development dynamics. Steve hid it well in his text, but the message was clear (judging from many of the comments to Steve’s article): the secret to great software development is having great software developers.

This kind of message could have been great. The key to success in our business is having a team of true professionals. But Joel’s article, and in a sense also Steve’s article, offered the easy solution: if you want a team of professionals, just go a head and hire the best ones on the market.

Now, imagine your CEO reading these articles and all the fuss around them. “Great!” he says to himself, “all we have to do in order to improve things around here is to hire better developers than the ones we have. We have tried everything else, so THEY must be the source of the problem”. And thus, a new silver bullet was born. And this time it can be really deadly.

People are the key to great software development. Having a professional team is the only (yes, the ONLY) thing that can help a company succeed in the long run. But there is no way in the world that prodigies can fill 100% of the industry’s open positions. And what are you going to do with your existing developers? Fire most of them and spend your time in conferences to get your hands on the next David Heinemeier Hansson? Great plan!

People are the key to great software development. But people are not a commodity. They are… well, people. If you want a team of professionals, you can have one. But the only way to have more positions manned by professionals is to grow more professionals.

There will always be prodigies – people with natural talent who have it all figured out the moment they touch a keyboard. But the rest of us can still be highly qualified professionals. At least most of us can. But just as in any other profession, to become a true professional you need guidance and mentoring.

Dear CEO, if you think the root of your problems lies in not having “the best” developers, ask yourself what have you done to make your developers better. Did you provide them with mentoring? Did you take it upon yourself to nurture them for their sake as well as for your company’s sake? Do you truly believe they can become professionals? Do you tell them that?

My father always said that money doesn’t grow on trees. Well, professionals don’t either. You have to work hard to grow professionals. “That’s not my job,” you might think to yourself. But the fact is you have everything to gain from nurturing your people. Your homegrown professionals will be better for your company. They will be more loyal. They will feel more committed to their workplace and to a shared vision. They will know they are treated not only as professionals, but also as humans. They will help you grow just as you helped them.

Sure, you can hire a couple of prodigies. But without nurturing professionalism as a key strategy, your prodigies will soon find better place to work for. A place with more people like them. A company truly committed to professionalism. A company willing not only to pay for professionalism, but also to work for it.

So, here’s the revised plan:

1. Find your best developers. They might be hiding in their cubicles, or merely too busy to be noticed. But they are there.

2. Reinforce them with some additional committed professionals. You can “shop around”. That’s OK. Just don’t think of them as replacement to your existing developers.

3. Provide mentoring for the rest. Give your best developers anything they need in order to create an extensive mentoring program to help the rest of your developers gain guided experience and develop their skills.

No, the change won’t happen overnight. Mentoring is a process, and professionalism is not built in a one-week workshop. But if you are really committed to professionalism and you chose the right platforms for mentoring, you will start to see the fruits in no time.

So, maybe professionals, unlike money, do grow on trees. But as any gardener knows, growing trees requires hard work, commitment, and patience. You can always get some fruits on your local grocery store, but they will only help you get through the next meal.

***

Followup: The Good, The Great, And The Better

And see also: The Root Of The Matter

When I started reading Steve Yegge’s latest article I was optimistic. The title sounded promising. The quote from Wikipedia was great. And the arguments against the Agilism religion were well articulated. The first couple of pages were really a great read.

Then, as I began to read Steve’s description of “the Google experience”, my enthusiasm started to fade. At first I thought I was just envy. After all, who can resist working with no deadlines, being flooded with rewards and incentives, and eating great (and free) food all day? Oh, and let’s not forget the fact that you get to choose the project and the team you want to work in on a daily basis. It’s heaven on earth!

But after reading on, I realized that the strange feeling I had was not envy. It was a déjà vu feeling. So, I went back to the top of the article and started reading it again.

Okay, I admit it: Google does sound like a great place to work in. I’ve never worked for Google, so I can’t know for sure, but I have no reason to doubt it. But Steve’s description had something else in it. It was almost religious. Or, as one of Steve’s readers accurately phrased it:

“When you hear people talk about working at Google its like listening to someone who just found Jesus.”

Yep. That was where my déjà vu feeling had came from! It was like reading Extreme Programming Explained all over again. A new religion is starting to emerge. And judging from the number of links to Steve’s article, the books, the seminars, and the endless consulting sessions, are just around the corner.

You see Steve, you could have gotten away with it if you hadn’t written such great arguments against Agile. Let’s see now. Here’s one of them:

“The consultants kept going with their road shows and glossy pamphlets. Initially, I’m sure they went after corporations; they were looking to sign flexible contracts that allowed them to deliver “whatever” in “2 weeks” on a recurring basis until the client went bankrupt. But I’m equally sure they couldn’t find many clients dumb enough to sign such a contract.”

That’s really hilarious, but more important, it is true. At least the part about no client being dumb enough to sign such a fuzzy contract. I wonder what Googlism has to say about that:

“Most of us in our industry are date-driven. There’s always a next milestone, always a deadline, always some date-driven goal to it.

The only exceptions I can think of to this rule are:
1) Open-source software projects.
2) Grad school projects.
3) Google.”

Working without deadlines! Isn’t that convenient? Maybe Google can afford it, but can you? For most companies this is as practical as sending all employees to a one-year paid vacation. Why? Because the same clients who will never sign a fuzzy Agile contract will also never sign a contract with no deadline.

And for the exact same reason almost no company can really have its developers changing teams with a one-day notice. When you run a software project you usually can’t afford waking up one day only to find out some of your developers are missing no matter how good your code is.

Now I’m in a difficult position. On the one hand, it all sounds great. Many of the things Steve talks about were even discussed in this humble blog. But let’s face it, the way Steve describes it you have only two choices. The first is to join one of the few companies in the world (if not the only one) that can afford creating developers’ heaven. The second is to go on fantasizing. So, should I add Googlism to the long list of promises in my previous post?

But maybe there’s a third option. Not an easy one, though…

Don’t take anything you read for granted, especially when it is spiced with religious passion. Adopt the good ideas, but drop the impractical ones. Think for yourself and try to come up with the optimal solution in the context you operate in. Remember that no article, book, or seminar in the world can have it all figured out for you. Not even this article.

***

PS. You should really read the comments to Steve’s article. There’s a lot of them, but trust me, many of them are very enlightening.

Here’s a pop-quiz: what do [take a long breath] Agile, Peer Reviews, JUnit, Pair Programming, SCRUM, velocity charts, burn-down charts, Bugzilla, Subversion, lint, ClearCase®, RequisitePro®, ClearQuest®, RUP, UML, MDA, TDD, BDD, XP, ISO, CMM, and (my personal all-time favorite) Refactoring have in common?

OK now, let’s see. If you found it easy to come up with an answer regarding a subset of this list, chances are that you are either an Agilist or, what many people in our industry call nowadays, a “traditionalist”. But that was not the question. The question was what all of these terms have in common.

The answer to this question is that each and every item on that list carry a promise – a promise for better software development, and eventually better software products. Each and every one of these methodologies, practices, tools, and standards is being marketed as a solution (and sometimes the solution) for the problems our industry is facing. Maybe the creators of these tools, practices, and methodologies, didn’t mean to market them as such. But the fact is, that most of us tend to perceive them as “just what we need” to improve quality, increase productivity, and reduce costs.

Believe me, I’ve used many of these methodologies, practices, tools, and standards at one point or another. Each of them is good in a certain context. Each of them can indeed spice the way we work and the product we create. But none of them can fulfill the promise. Not as-is.

No tool, methodology, practice, or standard, can fundamentally change the quality of our work. I have seen organizations spending literally millions of dollars on integrating tools (even open-source tools) in their development environment. About the same amount of money is often spent on conferences, lectures, and consulting sessions, in a never-ending race to catch-up the latest methodologies and practices. You know what? That might be perfectly reasonable, but that’s the easy thing to do. And as life often teaches us, a change — a real change — never comes easy.

To do a good job — to create a good product on time and on budget — you need a team of true professionals. And professionalism cannot be grown artificially. Wishing that tools, practices, and methodologies, will nurture professionalism is like saying that in order to grow fruits you need fertilizer. Of course, fertilizer can help, but no fruit has ever emerged out of a pile of manure.

Fruit grows on trees. We take it for granted, but trees are designed to enable just that. It all begins deep in the ground with the tree’s roots. No tree can live without roots. The roots nurture the tree — feed it to enable growth. Similarly, growing professionals and creating quality products require organizational commitment. All the standards, the tools, and the methodologies in the world will not change that. Adopting a new methodology without true commitment to quality and professionalism is like manuring a tree without roots.

The roots alone are also not enough. Without a trunk and branches, the roots will not be able to nurture the fruit. For organizational commitment to be translated into action, a culture of mentoring, sharing, and open communication is required. These are the branches on which people, and therefore the organization, grow as professionals. Just as the trunk of the tree thickens, the supporting organizational culture will be strengthened as commitment is more rooted.

Fruits will grow naturally when the roots and the branches are an organic part of your organization.

Tools, methodologies, and practices, all have their place. But before you invest your money and your energy in obtaining the latest technology or complying with the latest standard, take some time to work on what really matters: achieving true commitment and building a network to support professional growth.

There isn’t any other way. Really, there isn’t.

In a recent article, Timothy Johnson describes a great technique for voting on ideas that came up in a brainstorming session. His article made me think about recent brainstorming sessions I was part of. Each of them had a different nature, but there was one thing common to all of them. The people who took part in all these meetings felt they have to come up with a definitive conclusion by the end of the session.

Now, I don’t know about you, but my best thinking happens when I take a walk, when I’m driving, and often when I’m in the shower. It’s not that I don’t think when I’m in the office. But when I manage to clear my head, something else happens. It is as if I make room for myself to see what ever it is I’m thinking about differently — sometimes even more clearly.

Brainstorming sessions are all about gathering as many ideas as possible. Participants are encouraged to bring up ideas, no matter how wild. Criticizing is not allowed. That’s a great technique for coming up with innovative ideas. But can you seriously analyze these ideas within the scope of the same session?

Not every innovative idea is a good idea. That’s why you are expected to consider the ideas that came up in the meeting and vote for them. In order to do that effectively, you have to absorb the ideas, to think about them, to challenge them. This process requires quite a different mindset than the one required for coming up with crazy ideas. Changing your thinking mode so radically in a short time is not trivial.

Only five minutes ago you were supposed to come up with innovative ideas, and criticizing was not allowed. Now, you are expected to carefully analyze all those ideas, and choose the best ones. Can you really do that? Can you really break free from your own ideas and seriously consider other ones?

To be effective, the brainstorming process must include taking some time to absorb the ideas that came up. Each brainstorming session should be divided into two separate meetings. Use the first meeting only for bringing up ideas and making sure everyone understands them. Then, give every participant a printout of the list of ideas, and send him to sleep on it.

The decision-making meeting should take place the next day, after all the participants had the proper time to consider the ideas, and to come up with difficult questions. Only after conducting a serious discussion should you vote to select the best ideas.

You would be amazed to learn how a good night’s sleep (or taking a shower) can improve the quality of the discussion.