Hire generalists to help your specialists shine!

Imagine you are developing a highly-specialized embedded software product. Like a radio tower for the GSM/UMTS network, or a high-frequency trading back-end for a large New York trading firm. Why would you want to have generalists in that team? After all, these are niche-niche-niche products. Maybe a few thousand people work on these projects in the world. No need, right? Wrong! Here's why.

Forget common-sense

The comment above is designed to sound counter-intuitive. The reason for that is that most of this post is counter-intuitive. I'll argue that one of the basic premises behind software project management are purely and simply wrong. This one specifically, is ultra-wrong: specialists in a software project (even a niche one) should be the majority of the team. The "favor specialists" heuristic says things like: "don't hire a Ruby programmer to a Java project", "hire only people who've done financial systems to that high-frequency trading platform", etc. You get the picture.

What is the reason for this "favor specialists" heuristic? Why did it arise? The most obvious reason is that we want to hire people that "know what they are doing", and in our functional definition of software projects that means: "people who have done that one thing before". And who could argue with that? Right?

What if we looked at projects like systems, complex systems that incorporate technical and social aspects that are very hard to control or manage? In this case we would be compelled to question the "favor specialists" heuristics, because we would look at a project as much more than a technical endeavor. We would look at projects as being social and technical endeavors.

Social is complex

Social systems have many more dynamics in place than "what is the best technical solution? How do we select from competing technical solutions? What skills should we hire for?"
Social systems change rapidly (whether you like it or not), and they require a different set of assumptions about what is the best project team composition and organization. For example - the point of this post - it requires us to question the ratio of generalists to specialists.
In the last post I talked about Emergence. I explained that system behavior is affected by many unpredictable dynamics and that simple rules favor adaptable behavior in projects. I also said that a long list of complicated rules will remove adaptability from the project team. The heuristic I described in that post is: "complex rules emerge stupid behavior."

Emergence is favored by and favors generalists

I believe all projects are social complex systems. Yes, even two people projects (those, probably even more than larger projects. Think of the rule set on a 2 people project!). These social complex systems perform better when there are only a few and simple rules. They benefit from constant change (see here how to do that so that it does not kill you). Social complex systems are environments where generalists excel! Here's why:

• generalists are more likely to think laterally (similar problems in other domains), and therefore come up with innovative solutions that provide business advantages;
• generalists are more likely to establish communication links to other teams and organizations (because they are connected to more interest groups - which is what makes them generalists), and therefore improve the overall communication in the project team;
• and there are many more, let me know which you have found in your experience by leaving a comment.

Improve performance by adding generalists to your project

I propose that we start designing our projects based on a different heuristic: "favor generalists". This means that we will try to seed all teams with generalists, people who know their trade but are not invested in only one particular technical solution or process.

For Developers this means that all developers should be encouraged to learn several programming languages, work in different problems during their employment, and that we don't hire people just because they've solved the same problem in the past.

For Testers this means that we hire people that can do manual and automated testing (maybe more on than the other, but both), that know different technologies, that understand social aspects (users) and technical aspects of software development (e.g. math).

For Product Managers this means that we hire people that have worked in other industries, other types of products or even in non-software only products.

If you believe, like I do, that software projects are social complex systems, then you must not favor specialists. Hire and groom specialists but seed all teams with generalists, sit back and enjoy the higher performance.

Picture credit: John Hammink, follow him on twitter.

To all my friends and colleagues at Nokia, my contribution

Without a doubt many of you have read the news about Nokia taking Windows Phone 7 as their main Smartphone platform.

That decision by Nokia has a tremendous impact in my local software community: Finland. Nokia mobile phones (as it was known before) has always been a major employer of software development professionals in Finland where I live. It is expected that this decision will significantly reduce the number of software professionals that Nokia employs. This is nothing short of a blow to the local software community. However, this is not a tragedy. Far from it. Ironically there's never been a better time for software professionals in Finland. Many industries are adopting software as a key part of their products. From forestry to fleet management to network elements to health care, you name it.

This is why I've decided to start posting interesting software related job opportunities. I want this to be about the software industry globally, not just Finland. But, of course also about opportunities in Finland. If you are interested in posting the openings you have in this blog just drop me a line at SoftwareDevelopmentToday@gmail.com. Here's what you can gain:

This blog is read weekly by ~200 and monthly by ~790 unique visitors, from mostly Finland, United States, United Kingdom, India and Brazil. As this is a blog for software professionals, you will be reaching people that are already in this industry, but better yet you will be reaching early adopters who are interested in improving the way software is developed. This can be a competitive advantage for your company!

NOTE: i will not charge for these posting but I do reserve the right to select which ones I post, so make them interesting and as buzzword free as possible. Remember you are reaching a crowd that already knows a lot about software development, you want to focus on making your job opening as enticing as possible interesting for this crowd.

If you are looking for fresh new opportunities you get a filtered list of job openings. I'll personally read all of the posts and contact the companies to make sure they are legit and not just a fake interesting post.

So, I hope this is a contribution to the next career path for all my friends and industry colleagues at Nokia. I wish you the best of luck!

Photo Credit: streetart @ flickr

What can we learn from illusions that helps us manage projects better?

Just had the opportunity to watch a BBC documentary about illusions.

The show went on to detail how we as humans get deceived by our own senses. There were 3 things that opened my eyes in that documentary:

The things that caused me to think were:

• when we mix senses one of them tends to take over: this is the case when we are watching a magic act. The example on the documentary was a magician throwing a ball in the air for a few times, and then making the same gesture but keeping the ball in his had. Although the subjects eyes stayed on the face of the magician, the brain perceives the movement of the ball and later realizes that the ball has vanished.
  
• some of our senses are completely/100% contextual (see image above): the example they had here is a cube with many small squares on it's faces. Some faces are lighter, others are darker. When asked about the difference between 2 specific squares in the faces of the cube people would clearly state that the colors were different. However, when you moved one of the squares to the other face of the cube, you could see that the colors were exactly the same! Our perception of color was completely dependent on the colors surrounding the colors we were comparing.
  
• we can learn new senses if we are exposed to the right stimuli: The amazing examples they had for this was a blind-person that had learned to use sound and echo to see and used that learned sense to ride a bike (while blind!) The second example was quite amazing. A person would use a belt what was wired with buzzers/vibrators (like mobile phones) so that they could constantly feel where the magnetic north was. Later they would use that learned sense to navigate their way in a place while blind folded!
  

All of these observations from the documentary point to one thing. We are not wired to perceive reality. We jump to conclusions far too quickly, but we can also take advantage of that if we train our brain with the right stimuli! That was the most interesting find from this documentary.

The implications are huge in a software project setting, where it is quite common that people use only a very small number of stimuli (some reports, a couple of graphs, etc.) to jump into conclusions. We need to "learn" how to sense the status of a software project, and that can be done by following the example of the person who was taught how to "feel" the magnetic north...

Can you think of applications of this knowledge in your project?

And the mobile OS winner is.... Linux!

And suddenly the smart/super phone market is getting crowded with proper OS-platforms based on Linux!

This is a new one from AAVA Mobile (demo by Intel), a new comer to the mass market stage, but already providing a very cool device (HW-wise) with a powerful OS (Moblin - Linux based and supported by Intel).


If nothing else this proves that Nokia was on the right track already in 2005 when it introduced the first mobile device (Nokia 770) based on Linux.

It's exciting to see so much dynamism on the Linux Mobile OS front! Certainly makes the PC-based version of Linux much more attractive as well, if nothing else at least as a development platform!

(Disclaimer: I'm a Nokia fan boy :)

Here's the demo video (note the landscape mode focus on this phone, just as in the Nokia N900)

Does Toyota really use waterfall for software development?

I saw this post and could not resist leaving a comment. Here's what I wrote as a comment to that post:

How can they [Toyota] apply waterfall and be predictive, fast and high-quality? Those are all qualities that waterfall lacks.

Predictability is lost because of lack of visibility into quality until it is too late (the test phase). Not to mention that trying to predict how a software project will go is like playing Lottery blindfolded and selecting a ticket to the wrong draw!

Speed is lost because writing requirements up front leads you to create a lot more requirements than you really need because you don't have the feedback of running software.

High-quality is lost because waterfall leads to slow and late integration which leads to many defects being left in the software! Not to mention that you can't inspect quality in, you have to build it in!

Now I'm curious about how you get out of that "they use waterfall but they provide all of the "goodies"!

Oh, and you can't say "they said they used waterfall but did not actually do that"! ;)

What do you think? Do you agree that Waterfall can be used with predictability, speed and high-quality.

The Software quality hash tag #swquality

If you do Twitter you probably know exactly what I'm referring to, if you don't here's an article you should read.

Together with @most_alive and @Mendelt we just coined a hash tag to aggregate discussions about the cost of quality in software development. The hash tag is #swquality just add that to every tweet that you write about the subject.

Join the conversation!

What is a bottleneck? (TOC)

When faced with a problem in a process, the first step you should take is to identify the process map and bottleneck.

This is nothing new, TOC people have been advocating this for a very long time as part of their "5 focusing steps". But if it is why don't we do it?

Well, because it is hard work. To identify the bottleneck you can't just sit around a table and have a meeting with the managers to define what is the bottleneck. You have to go to the Gemba and analyze the process "as is", not as "it should be" and make some actual work on data collection and analysis.

Once you have done that you are then equipped to start searching for the bottleneck, it's location is buried in the data and process map you just collected.

To find the bottleneck you have to work hard, but finding it is just the first step! Much more is to come...

The Skill issue, the industry shame

I was reading Jason's blog when I came across this post. I could not agree more.

Way too many times I bump into problems that can be traced directly to the idea that you can hire just anyone, with any skill level and they will perform to the expected level of professionalism. This is pure bulls#%&!

Some time ago (just before the bubble burst in 1999) a company I was familiar with was hiring QA people just because they knew how to boot Windows. Yeah right! Way to go!

We also see the same with people putting together teams that behave like a set of individuals all pushing in different directions because "anyone" can be a manager! Stop believing in magic. You don't get a high performing team if you don't have a proper leader in the team (the leadership can be shared BTW, no need for a "hero", in fact that's sometimes worse). Start coaching the team and them make them understand how to work together!

If we put these two things together: hiring coders and testers that have no skill, and promoting people to leadership position that have no leadership skills what do you get? You got it: our software industry!

Can you believe it! This type of behavior and belief is rampant in our industry. Small wonder that we will be seeing lots of people being laid off in the near future...

PS: if you are smart and really good at what you do (testing or coding), you are better of these days starting your own consulting company, charging bucket loads of money and getting out of there once you are fed up with the local incompetence!

The value Black Swan (or the killer improvement in software development)

Thinking back to how we value our work, we must recognize that, in software, quantity is not value!

The number of things we do in a sprint does not vary too much, we can consider it a Gaussian (assuming correct and consistent measurement) -- or in Black Swan (TBS) parlance: velocity is a variable from Mediocristan. However, the value of each item does not follow a Gaussian -- in Black Swan parlance value per item is a variable from Extremistan. It is conceivable to think that we can have one item that accounts for 90% of the value we deliver, in fact that is most often the case, but even knowing this we may underestimate (or lack understanding of) the real extreme value of an item.

What does that mean in practice? How does this affect our planning or item selection? Can we in anyway predict the value? (not, according to TBS).... The payoff of a "large value" item would however be much bigger! (altavista vs Google)

In my view, given the current knowledge I have of the software development process/world, I'd say that this assertion means that the most value in a software development process can be obtained by concentrating on selecting those extreme value items that can make the software a success. Current science and practice on this, however, seems to lack any repeatability or reliability when it comes to reliably selecting the "killer" features... Do you have any links to papers/articles about value focus in the requirements selection process? link them up in the comments section.

PS: if you don't know what a Black Swan is, you better read this, or the book.

Testing to script is waste, creative testing is extremely valuable

Testing is a hard job. Imagine this, you have to make sure an application of more than 2 million lines of code is ready to ship. It all depends on you, and your team of 2 testers.

How do you do it? Well, one way to do it is to make sure you cover all the possible use cases and test for those. But that can go into the thousands. There's no hope you can test all of those cases in a short period of time (let's say 3 months or so...). Well, now we just made it even more difficult: we have to release every 4 weeks. Oh, and did we tell you that we are changing the architecture as we go? Incrementally of course, but nevertheless.

How would you cope with a situation like this? Yes, the answer is you would not (just setting up my answer... wait for it). The answer is that you must make sure you are never in the this position!

How to avoid being in a position to have to test a large piece of code with large code changes ongoing and still release every 4 weeks? Test automation. All tests that can be automated should be so, and at all levels: unit, integration, system, performance, reliability, you name it.

The point is this, testers brain power is wasted if all they can/are allowed to do is to test against a static specification with a few tests added every 4 weeks. That's not the best way to get the most out of the smart people you have in your company. If you are not a tester, just imagine yourself having to go over the same 40-50 pages of tests every single iteration, month-in, month-out. How long would it take you to quit? I suspect not too much...

Additionally, if you consider the effect of familiarity (reading the same test cases 2-3 times a month for several months) on the quality of the testing you quickly realize that manual testing against a script over and over again is the best way to get problems to escape even the most dedicated tester's eyes.

So, what next? Well, test automation is one solution. The next step is to train your testers to be expert "breakers", their goal should be to find more and more ways in which to break your software. Specifically ways you have not thought about!

The message is: testers are way too valuable and way to smart to have them spend their work-hours going over a brainless set of tests-to-spec, you will get a lot more from your test team if you automate the repetitive tasks and let the loose on your code.

This is, BTW, what Richard Feynman advocated when he reviewed the Challenger disaster in the 80's:
"(...) take an adversary attitude to the software development group, and tests and verifies the software as if it were a customer of the delivered product."

On the subject of problem solving, and problem root causes

Problem solving is key to the discipline of software development. What we do when we code/test/release a software product is essentially problem solving. We learn about a problem we analyze the root causes and then we come up with a solution.

This post by Brett Schuchert reminds us that very often the apparent causes of problems in our efforts are not the right ones. In his example, a developer is blamed for "doing the wrong thing" when in fact the policies and rules in place force developers to actually do the "wrong thing". Often, problems in software development come from policies and rules, not from people wanting to be bad.

If you are analyzing a problem in your team right now, ask yourself: are there any policies or rules that may cause this behavior?

W. Edwards Deming suggested that in 96% of the cases the deep root causes of a problem lie within the web of rules and policies put up to "regulate" the work (he called it the system) as opposed to suggesting that the problems are caused by people, on purpose or due to incompetence.