The bad, the ugly, the weak and the good.
--
There are couple, major problems in development teams, and none of them is technology related. Problem number one is Communication.
There is a wrong illusion that a software developer should be good in communicating with the machine. No! The compiler does that. A software developer communicates with people, and with most of them — indirectly. The creators of the libraries he uses; the people from other teams in the company; the end-customers, by trying to fulfill their requirements; the management body, communicating the tasks, and so on. Unless you work for Intel, AMD, or NVidia — you are not likely to really communicate with the hardware directly.
The second, and it comes partially as a consequence of the first one, is Trust. Actually — the lack of it. It is not difficult to see why. Discussing a certain software product, is like standing in Louvre, talking about Mona Lisa’s posture, the spark in the eyes, her hands, etc. Then, going out and telling the development team about your insights, giving them few tons of sand, and asking them to paint the Vatican square with Mona Lisa’s portrait… That big is the jump between high-level, feature related talks, and the granularity of the details software developers need to deal with.
Of course, industry is getting mature — there are a lot of libraries, frameworks, templates, development tools, etc. There is an open source movement, which significantly raised code reuse. But, the point is that making such big jumps always bring errors. Big and small. Design-related and implementational. A lot. When this happens the rest of the team, naturally, as part of our human nature, becomes less trustful. As a result, many teams start relying heavily on code reviews, thinking this is some miraculous panacea. They’re essentially saying “We don’t believe you, anyways, so we’ll stick several other people, to make sure you’re making less mistakes”. Well, the role and importance of code reviews is a totally different topic — I’m not anti-CR advocate. No. Still, they add up to the lack of trust. And, there is no such thing in the world, as — teamwork without trust.
And the third major problem comes from the lack of Completeness. Many companies talk Agile. Few understand it. Even less do it. The deeper into the development team people love the idea, the more useful it is. And we, engineers, naturally, don’t. We live in our brains — construct buildings, tools, machinery, software — this is very important skill for any engineer to have. If not — better do something else.
In the same time, this attitude makes us reluctant to verify, to confront our imaginary creatures with the reality. And this is what Agile stands for. An attitude that marketing people have. Sometimes — sales people too. But, we don’t like them very much either… Kind-of… Anyways, where was I?! Ah, completeness! What does engineers’ love with marketing have to do with it?! Well, not much, really. But, overcoming the inherent fear and discomfort of matching imagination with reality, by settling on a solution, even when it does not feel perfect — this has a lot to do with both completeness, and Agile.
The process usually consists of many decisions, and like always in life — decisions are about what should be left behind, not about what will be taken away.
In software industry, it is full of opportunities, possible paths, tools, branches of possibilities, and on each step there is plenty to be left behind. It is what it takes to complete something. And this is why we so often fail to do it.
The beauty is that same pill works for all three of these problems. Does not solve them completely! But, helps a lot. It is called Responsibility. Or, more accurately — the push to bring it back in the business. Splitting the work into responsibility zones, i.e. modules, sub-products, libraries, etc. and assigning a single person, because there’s no such thing as shared responsibility, to each of them, facilitates a type of behaviour which resists all of the three major problems.
Completeness is immediately enforced — from architects to settle on certain structure, to developers to deliver something usable by the other team members. The trust improvement comes as a by product of the fact that being solely responsible for a piece of code, makes you care about its quality much more. As a result, the code gets better and better over time. So does the trust from the others.
And, finally, the communication aspect. Splitting the work into standalone pieces, means that they need to be assembled at the end, in order to have the final product in all its glory, and the glue for this process, is communication — in the form of documentation, diagrams, presentations, or whatever.
Only, after addressing these aspects of the team setup, one can turn to discuss the technologies to be used — for both the development itself, and the tasks of managing it. But, that’s another story.
Note: All images are from Sergio Leone ’s 1966 movie “The good, the bad and the ugly”.
