Metaphysics of Software Development
Some insights on the software development craft, from a philosophical viewpoint.Wednesday, January 27, 2010
Functional separation
As I have said in another post, the division of software development in activities is methodological and not ontological. As such, there is little point in creating functional silos, each one responsible for a specific part of the whole process. Besides being a brutal violation of common-sense (because it tries to force a theoretical model upon the real world), there is at least one harmful consequence: the task oriented mindset.
When tasks are assigned to different, non-communicating teams, according to their "specialties", some people tend to perform dull tasks, while others do all the hard thinking, yet becoming somewhat limited to put their ideas into practice. Consider the far too common separation between developers and deployers; in theory, developers should be focused on creating a running application while deployers are supposed to adapt the application, as needed, to the working environments. In practice, however, the deploy task is usually assigned to system administrators, who are often very good at keeping the infrastructure up and running. But system administrators in general have no knowledge whatsoever of the details of the application and how it interacts with its environment.
Since someone has to take care of this kind of issues, the burden usually falls in developers' hands. But, to complicate things further, according to a common policy, developers do not have acesss to the working environments (not even the development environment, in some cases). The consequence is ridiculous: developers sitting side-by-side with deployers, with ther formers telling the latters step by step what to do. And this ritual is performed everytime some deployment work needs to be done. Even if some deployers learn to do the job, they will not be able to cope with the slightest change in the interaction between the application and the environment.
Variations on this example can be produced for data administrators, testers, webdesigners and so on. When people are told that their main concern should be executing a certain task, they will naturally ignore the context in which the task is performed. In a software project, people should be focused on the project goals, not on the tasks that are needed for achieving it. People working under the task oriented mindset tend to behave as labourers, not professionals, as Uncle Bob would wisely say. As such, they cannot contribute to the project with creative ideas, better solutions for known problems and so on.
This consequence seems to be fairly predictable, since there is a tacit assumption among most software project managers that software development is a manufacturing activity. But, as every developer working on the trenches know, developing software is a creative process, more like writing a book than executing repetitive tasks on an assembly line. The communication between people working on the project (no matter what tasks they are performing) is essential to its sucess. And functional separation presents a huge barrier to effective communication. Despite all these obvious observations, several companies still insist is separating people according to the tasks they are supposed to execute and encouraging them to be short-sighted, believing that separation will speed up the development.
Labels: commitment, functional silos, multifunctional teams
posted by Otavio Macedo # 8:24 AM 
Archives
January 2010 February 2010 March 2010 August 2011 November 2011
Subscribe to Posts [Atom]
Post a Comment