Computer programmer : the cornerstone of high-tech software industry
As they get their first job as a programmer, I noticed that most people want very soon to manage their own team or become "software architect", though they do not have yet the slightest experience on the job.
Why that situation - a system analysis:
---------------------------------------
I suspect the main reason is that "computer programming" is not at all considered as a job to be proud of: in the classical view, it is often synonym to a lower working class of the high-tech industry, editing trivial code chunks for a large system that has been designed by an elitist architecture team.
The main drawback of this situation is that skilled experienced programmers almost always get demotivated and stop doing what they do best, to choose between two main career paths:
- specify what others should do through large documentations
- manage programmer teams as appointed leaders
The resulting situation is that nearly 80% of the programming population is composed of beginners, mediocre programmers or uncontrollable geeks.
Alarmed by this constatation, the top executives naturally credit them with poor credibility and empower other layers in the organization for thinking in their place, like design architecture teams, Quality Assurance teams and middle management.
As a consequence, in the shared mental model of most organisations, these layers soon own all the "noble" jobs that every sensible computer programmer should seek to succeed in his career, whereas the programming folk is dangerous and should be highly controlled by responsible thinkers.
A cancer for software edition
-----------------------------
This reinforcing process generally goes unnoticed and lowers the capability of an organisation to produce high quality software.
It especially results in a complex machinery where every single need goes through several translations handled by as many different teams before getting to the programmers. Traditionnally we observe a minimum of 4 steps:
1- decomposed in several pieces of functional requirements by a Product Line Management team,
2- analysed by the architecture team to produce the detailed technical design requirements
3- developed by programmers, following the constraints of a heavy QA process
4- tested by a dedicated team, at the very end of the development stage
Apart from the considerable waste of energy of such a process, I think the number one issue appears in the lack of the programmer team involvement on the 2 first stages: the programmers are the ones in charge of the code production, and thus own the real expertise of the inner details (potentials as well as risks) ; furthermore,a clear vision of the needs in the actual implementation stage would enhance the rate of success, by focusing on the real added-value.
This kind of organisation strongly favors a discrepancy between the concerns of the team and the concerns of the rest of organisation.
XP: a new breath of air
-----------------------
XP gives back to the programmer its central role in the software production.
The bet is to create a new kind of reinforcing feedback process to motivate the talented programmers keeping an active role in programming teams as they get more experienced.
In a mature XP team, everyday issues constitute as many opportunities for personal improvement, and the potential of each member is used to the best for the project accordingly to his (her) insterests.
Why that situation - a system analysis:
---------------------------------------
I suspect the main reason is that "computer programming" is not at all considered as a job to be proud of: in the classical view, it is often synonym to a lower working class of the high-tech industry, editing trivial code chunks for a large system that has been designed by an elitist architecture team.
The main drawback of this situation is that skilled experienced programmers almost always get demotivated and stop doing what they do best, to choose between two main career paths:
- specify what others should do through large documentations
- manage programmer teams as appointed leaders
The resulting situation is that nearly 80% of the programming population is composed of beginners, mediocre programmers or uncontrollable geeks.
Alarmed by this constatation, the top executives naturally credit them with poor credibility and empower other layers in the organization for thinking in their place, like design architecture teams, Quality Assurance teams and middle management.
As a consequence, in the shared mental model of most organisations, these layers soon own all the "noble" jobs that every sensible computer programmer should seek to succeed in his career, whereas the programming folk is dangerous and should be highly controlled by responsible thinkers.
A cancer for software edition
-----------------------------
This reinforcing process generally goes unnoticed and lowers the capability of an organisation to produce high quality software.
It especially results in a complex machinery where every single need goes through several translations handled by as many different teams before getting to the programmers. Traditionnally we observe a minimum of 4 steps:
1- decomposed in several pieces of functional requirements by a Product Line Management team,
2- analysed by the architecture team to produce the detailed technical design requirements
3- developed by programmers, following the constraints of a heavy QA process
4- tested by a dedicated team, at the very end of the development stage
Apart from the considerable waste of energy of such a process, I think the number one issue appears in the lack of the programmer team involvement on the 2 first stages: the programmers are the ones in charge of the code production, and thus own the real expertise of the inner details (potentials as well as risks) ; furthermore,a clear vision of the needs in the actual implementation stage would enhance the rate of success, by focusing on the real added-value.
This kind of organisation strongly favors a discrepancy between the concerns of the team and the concerns of the rest of organisation.
XP: a new breath of air
-----------------------
XP gives back to the programmer its central role in the software production.
The bet is to create a new kind of reinforcing feedback process to motivate the talented programmers keeping an active role in programming teams as they get more experienced.
In a mature XP team, everyday issues constitute as many opportunities for personal improvement, and the potential of each member is used to the best for the project accordingly to his (her) insterests.
posted by Pascal at 8:24 AM
1 Comments:
I wonder if the "cancer" situation you describe is just a french phenomenon. Are there developers from other countries out there that could share their experiences on this subject ? And if it is not restricted to France, isn't this phenomenon a natural result of the typical mindset and goals of big enterprises ?
Shouldn't software be created in small design agencies, as is the case for instance with companies like Fog Creek or 37signals ?
Post a Comment
Links to this post:
Create a Link
<< Home