Recently I was reviewing requirements for Microsoft Architect Certification and had found description for architect roles. After reading I had a question: do we need this kind of architects in a software team? Can they really help with building successful software?

The summary of architect responsibilities (as per Microsoft):

• Enterprise architects: set the overall vision and framework for the IT environment from a strategic business perspective.
• Solutions architects: design the solution to take advantage of the existing assets, integrate them into the existing environment, follow the enterprise architecture, and solve the business problems of the business owner or unit.
• Infrastructure architects: responsible for creating an architecture that meets the business and service level agreement requirements of the business owners and supports the applications and solutions that are required to operate their day-to-day businesses.

The bottom line is that company hires expensive and canny software architects before start of the project. They talk with the business, come up with solutions and make bright key decisions about architecture. But they don’t program. During the course of the project they ensure that developers don’t spoil this great architecture.

Now business owners can hire not so bright programmers, who should just follow directives and implement this great architecture. There is even correspondence with theories of some management consultants that programmers are just house painters.

Completely irrelevant questions: Can you trust advise of your friend about Paris, if he saw the city only on TV? Can you trust battle plans if battle didn’t begin and your commander knows little about enemy? How many chess moves ahead can you predict with high certainty before start of the game?

I don’t reject a need in architecture, but I don’t agree who, when and how should make architecture decisions in a software project.

Read full post >>

42… Do you still need more explanation?

42 is the Answer to The Ultimate Question Of Life, the Universe and Everything (Google confirms this). According to The Hitchhiker’s Guide to the Galaxy, a hyper-intelligent race constructed the second greatest computer in all of time and space, Deep Thought, to calculate the Ultimate Answer to the Great Question of Life, the Universe, and Everything. After seven and a half million years, Deep Thought answered: “forty-two.” The computer rejected complains:
“I checked it very thoroughly, and that quite definitely is the answer. I think the problem, to be quite honest with you, is that you’ve never actually known what the question is.”
This is probably the largest known communication failure in the Galaxy. What about you? Do you know how to communicate effectively, avoid communication failures and still get things done?

Communicating with humans

We know that effective communication with humans requires skills, experience and effort. It is not easy and straightforward. Professor Albert Mehrabian explains that in communication

• Only 7% of meaning is in the words that are spoken.
• 38% of meaning is in tone of voice.
• 55% of meaning is in facial expression and body language.

It is not overstatement. Our unconscious parallel processing in the brains is much more powerful than controlled sequential thinking. It is matter of our survival to use “gut feeling”, all senses and analyze many clues – much more than we can do with the limited conscious mind. In addition, we cannot trust words, we often use them for convincing explanations without really knowing how we came up with them.
Therefore, person-to-person, face-to-face communication is the most effective. But excessive communication could be a big waste of time and prevent us from accomplishing other things. To survive in the modern communication flood we should learn how to communicate effectively.

Read full post >>

Programmer’s Side

Programmers in the software team work well together, trust and support each other. But they don’t talk about their salaries – the most important reason why they work for the company. It is taboo. Tell them that one of their fellow programmers earn 50% more than others. You’ll see smiles disappear, people don’t look at each other and become silent. They will rebound, but these things leave scars on team morale and cohesiveness. Feel of unfairness is not the best companion in the software development.

But why does compensation is so important and sensitive for us?

• We work to live. We spend more than half of our conscious adult life earning money on work. We need money to live. Money enable for us almost everything material in this world. Any non-material incentives cannot compensate insufficient money income.
• Money are social status. The better compensation means you worth more and more attractive from social and even biological perspective. People strive for relative prosperity. They could accept less themselves than see a rival get more.

Read full post >>

Marc Andressen quotes Frans Johansson’s book “The Medici Effect”:

In a [1987 study, researchers] concluded that brainstorming groups have never outperformed virtual groups. Of the 25 reported experiments by psychologists all over the world, real groups have never once been shown to be more productive than virtual groups. In fact, real groups that engage in brainstorming consistently generate about half the number of ideas they would have produced if the group’s individuals had [worked] alone.

It is hard to believe (as with any categorical statement) that this is a final verdict. Some bloggers correctly point that done right, brainstorming is a powerful tool (here and here). Mindtools.com and Wikipedia describe effective brainstorming process.

However, group brainstorming indeed has potential risks for generating less and lower quality ideas:

1. Ideas that challenge conventional wisdom are suppressed or considered mistaken
2. People can change or even disregard own ideas while listening to ideas from others, especially authoritative sources
3. Sticking with the crowd causes less willingness for risky and innovative ideas.

Effective brainstorm process avoids these problems when:

1. People investigated the topic before the meeting and come prepared with own ideas and considerations.
2. People are diverse, have different perspective and background. They bring specialized and tacit knowledge to the table.
3. People are encouraged to think independently, creatively and don’t criticize others. Everybody contributes as equal; ideas could be even presented anonymously.

I experienced myself both successful and unproductive brainstorming sessions. I found that good brainstorming session produces ideas, which are better and more than just selection from individual ideas. It is real enjoyment to see when people create ideas, enrich each other thinking and generate new wonderful and unseen ideas. A side effect is important: people consider themselves as a part of the process, feeling ownership and control. They accept final ideas readily, better understand these ideas and are committed to implement them. This is a way to become self-organizing team.

4 Effective Leadership Styles in Software Development

What should be the qualities of the best leader for the software team: strong decisive knowledgeable or quiet supportive cooperative? Best leaders have two main concerns – people and getting things done (Blake and Mouton’s Managerial Grid). Both concerns have cumulative effect – high concern for people makes them motivated and therefore more productive, high concern for production creates sense of achievement and makes people more satisfied at work.

However, there is no one leadership style that suits all situations, projects and individuals. There are 4 main leadership styles (based on The Hersey and Blanchard model and Vroom and Yetton’s Normative Model), which could be effectively used in software development: The Commander, The Coach, The Supporter and Self-Organization.

Read full post >>

I have just recently read an interesting post in Cedric blog:

“..software engineering is nowhere near as advanced as building engineering is. We are still working on these nuts and bolts, and whenever a new software project starts, we still can’t be sure it won’t collapse under its own weight after just a year. To make a parallel: imagine a world where every time a new construction takes place (say, a bridge), the future of that bridge depends on the team of engineers and workers you choose to build it…”

Bridges do collapse. Tragedy shows that even standard engineering solution which was following strict guidelines, regularly inspected and maintained could fail.

One bridge is a relatively simple construction. We can probably compare it to one week of programmer’s work considering complexity, number of elements and relations between parts. What could we compare in the engineering to the several month project with many developers and subsystems involved? It is comparable to the very complex construction like combination of hundreds interlinked bridges (don’t ask me to prove my ballpark estimates :)). It is comparable to the construction of Boeing. How much does research and development of Boeing 787 cost? $11 bln dollars.

Typical software projects have much lower cost, much less people and don’t have luxury of relying on stable laws of the physical world and established engineering principles. But programmers carry in their brains the same amount of information, many system relations and complexity as in advanced engineering projects . These are essential difficulties that software developers are facing. In addition they deal with the changeable world of people and business needs.

Major bridges collapse every 30 years and engineers learn from these mistakes and make better and more reliable designs. When we complain that Software Development doesn’t have the same sound practices as engineering, we shouldn’t accuse just immaturity of our profession. It is one of the most intellectually complex human activities dealing with very complex systems. I just hope we will experience less and less collapsing bridges both in physical and software worlds.