Discussões sobre Memória Organizacional em ambientes de desenvolvimento de Software
I always read complains about how the software factory paradigm leads inexorably to failure. I really can’t say I don’t agree with this point of view, but I find it amazingly disturbing that most of these assertions are void of reasoning or are filled with – to say the least – disputable bases.
Software is an art
I’ve already stated in previous posts that software is NOT an art. That’s absurd to even consider it, unless you take medicine, law, arhitecture, engineering and so on as arts. Being able to act with a certain edge of discretion doesn’t mean that creativity is the whole part of the process, the main part, or even that there’s no techinque. Wait! Did I said technique? Even ART conceives the presence of techniques (and has quality assessment based on them)… Well, not according to some of my colleagues.
What we need to understand is that creativity is part of the human essence. The very reason we are – for better or for worse – having this discussion using a world-wide mean of communication is a chain of problem-solving creative actions taken by our fellow humans during the course of history. Even the production lines are subjects to change! Or is it really acceptable to say we produce cars now the exact same way the first assembly line was programmed to do? I don think so. Machines are perfected, and so are methods, in different levels, without leaving the “factory” idealistic boundary.
So, my point is software is not an art work, but a logical production where creativity is a key element to success.
Projects with variable scope
This is probably the source of a huge number of mistakes and misconceptions in software development. It seems clear to me that everyone knows a project is not the same as product. And it is constantly stated that a project exists only by the definition of time, cost and scope. So why do we insist on this nonsense called “variable scope project” as an undisputable truth?! It’s just another a management/negotiation problem. If there’s need to change SCOPE (which means a change in the requirements on the perpective of Project Management, not Requirements Engineering), the project will need replanning or these new needs should just be postponed to the next project. Remember: project is NOT product.
So, the variable scope hell is, in fact, a permissive project management, a lack of knowledge or inability to negotiate with the client. Either way, it is the result of irresponsibility.
We already excel at information transfer
I see this as the key element to perceive the arrogance existant in the software development area. We actualy know nothing about information transfer. Being able to transfer and copy bytes really don’t make us experts in this field simply because we intentionally ignore the subjects in the process. We avoid to think in matters of cognition, translation and semiotics. To be fair, some of us do work with these concepts, but they do it when it is imperative in the projects they’re working.
Just to mention some views on the matter, it’s not unusual to read opinions saying requirements engineering is useless or that short meetings just do the job of knowledge sharing. Obviously these are not well-founded ideas, since registration led mankind to another level of technical and cultural (including all forms of art) production mainly because people could share and discuss their ideas without the presence of the other. It’s undeniable, also, that the act of writing leads the writer to take into consideration his thoughts and the aesthetics of the content he’s creating, so it will be more accurate and therefore understandable.
This is utterly important in a software factory, because we need to translate the client’s needs to a language that the whole team can understand undoubtedly. This means less erros and less document traffic/revision.
But that’s not the reality I experienced. There’s a culture that forces the requirements analyst (in some places called business analyst, though I think these are two completely different profiles, with different methods and timeframes in the development lifecycle) produce documents in client’s language and pass on to the next phase, when there should be another translation to developers’ language. This is just absurd! The first translation will be ineffective, because it’s produced by a non-expert in the language (requirements engineer): the client will understand it because he was involved in the process and they know the context, but a part of the information (background knowledge, specially) will be lost and then lead to conflicts of understanding in the team. This translation problems is well known for translation theories, but also can be easily related to the evolutionary theory’s copy problem – the capability to make copy involves a variability in the content.
Then, the more translation steps you create in the production lane, more noise will be included, leading to error or revision. This means the most effective way to communicate needs (or requirements) is to translate once from client’s to team’s language.
Some people just say that we’ve been taken as machines, and that measuring doesn’t take into consideration emotional matters like excitement, interest and so on. Maybe in some cases this is true. But I think this is not the appropriate approach.
First of all, measuring is not necessarily related to excess of control. It’s rather obvious we have to know if the things we’re doing are leading to success or falling appart. If I don’t have the habit of taking a look at my account balance, I probably will be bankrupt anytime soon. Mankind had to create a way to measure time in order to know when to seed and harvest. We NEED control in order to survive. It’s not different for social organisms.
But in software development we fail because we simply don’t know what we’re doing when it comes to administration. The fact is that we don’t have a good way to measure products/projects. Then, we tend to create lots of illusions that we’re measuring anything – like daily having to register each and every minute you spent doing everything you actually did. It just doesn’t work! We tend to make othes assumptions like the business party being promoted because they generated revenue, while the coders didn’t – this is common in factories. Well, technically, in every company the main (I’m not risking “only” here) revenue source is the client… so, promote the client!
These things are not caused by a disregard for the feelings. They happen because we don’t use to evaluate CONTEXT. The numbers only generate valuable information when put them into contexts. We’re also lazy when it comes to applying administrative theories. Most of the managers I stumbled upon (lol) used to read a set (quite small) of books and tried directly to apply what he assumed was the author’s point of view. Though most of these books (some I read… most they told me were “a must”) where based on success cases, they tend to take them immediately as universal truth. What we don’t use to think is that these books tell only a fraction of the story – there’s a lot untold variables that made that case a success.
Maybe we don’t know how to read numbers and think that one example defines a tendency. Maybe we’re just lazy to put things into perspective and investigate further. Maybe we’re to arrogant and think that we know everything. In the end, it doesn’t matter, for decisions are made over uncertain measures and frameworks.
If I only had a heart
Free projects can’t be used as a benchmark simply because most projects don’t have a large discritionary edge, like the opensource ones do, based on the developers community’s interrest. Take any project as Wikipedia and Gmail is just nonsense. It’s the same way with companies: each has its values and culture. We can’t turn all of them into Google, Harmonix and other “cool” companies simply because there’s no room for that. These companies’ model is interesting, attractive and they prize creativity… well, it would be nice to work there. But I don’t see it actually becoming the rule. Their products are intended to be trendy, innovative, different – it’s in their DNA. Other companies (or specially TI teams inside another company) are not completely free when it comes to innovation – and that’s completely understandable. In these cases, the innovation emerges from the business and only the few business analysts who broadened their views are able to promote change… and sometimes it requires some political skills.
It doesn’t mean the company doesn’t have no regard for the worker. It’s a shame this “evil company… poor me” view is actually spreading, because it shows a lack of understanding of the business mechanics.
The same thought about opensource projects and how their rule isn’t adequate latu sensu can be applied when we’re observing the work relationships. I’d really love to believe (and to see) it happening, but there always will be those uninterresting projects to be mantained, those nobody wants to be part. There are also those activities in a project that nobody wants to do for some reason. When these things come to surface, the self-managed teams starts to crumble.
Well, to say the truth, I encourage the self-managed team organization, but I also think it’s somewhat naive to think it’s fully appliable. There must be a responsibility definition, not to rule, but to lead, to help solve conflicts, to be a reference in the team… and sometimes to rule (lol). I say this because a leader only exists by the relation it has with followers… and not everyone will be unanimoulsy enlisted as follower of one person in the team. So, to non-followers, the leader aproach doesn’t work – he/she has to be a boss in these cases/moments.
Opensource products already changed from an anarchy to a more ellaborated approach, with well-defined responsibilities. Which is a good hint that 100% self-organized efficient teams is a myth.
But in a factory the things are a little different, since the relations are spread through fields, with different teams, losing the leader connection – at least the larger or more successful ones. This is a good lead on how the absence of responsibiliy is a destructive problem that has to be handled.
Causality vs. Culpability
The main cause (not the only one, obviously) to the feeling of failure in the software factory model resides, IMHO, in the responsibility sharing (or, should I say, guilty transfering). When, for example, a Requirement Engineer delivers a documentation to the next involved in the lane thinking “good riddance… it’s not my problem anymore”, the communication channel is closed and the attempt to prevent an incident (or solve it promptly) is lost. In a short period of time, that kind of behavior contaminates the other lanes and soon everyone is focused on getting rid of the tasks in hand… In no time, the software itself, which should be a solution, becomes a problem. Then, when something needs to be fixed, a dance of guilty transfer takes over all involved until the root of the incident is found and much time is lost before anyone assumes responsibility and the measures start to be taken. By that time, probably the client is aleady immersed in the culture that software is a problem.
I’m pretty sure software factories are not effective, as most developers I know do. But I find the main ingredient to its failure to be cultural rather than procedural.