In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes > >Anyway, several points from a combination of personal experience and >academic reflection: > >(a) It only *seemed* to work like this: many of the important processes >relied on external contacts and interactions that extended beyond the >apparent roles of the participants. Coffee machines and water >dispensers help the software development process immensely. >(b) There is evidence for this, in, for example, Janet Rachel's >ethnographic study of a software development team showed a complex >pattern of social interaction that didn't follow the job or team titles >and roles. >(c) I hated it so much I was looking for a new job within four months. >And the turnover rate (for programmers) was very high - average duration >of employment was about a year. Analysts and managers stayed longer, and >they were paid and respected more. > >One story: on one occasion I had a meeting with the department manager, >with my boss. The manager would not talk to me: he only spoke to me >through my boss. On another occasion, the manager of the design team >conducted a complex system design personally, because he was responsible >for the team, not because he had any design experience (he didn't, >although he had several highly experienced designers at his disposal). >The result: the development team spent ages tracking down and resolving >the design errors. I've seen similar interactions on quite a few other >occasions: people's roles can create incredibly dysfunctional software >processes. > >Since then, I've worked both in small and large companies and software >teams, although academically, I've worked as a social scientist as much >as a computer scientist. The hierarchical model looks simple and >effective, and it works to some extent for some parts of the process, >but the flexibility that the individuals build to make it workable needs >to be respected and supported by ensuring that contact outside the >formal roles and relationships isn't deprecated and restricted. > >Science is in many ways similar - so academics can see something of >this. The same (semi) hierarchical structures are there, and a few I've >met even treat PhD students with about the same respect that I received >as a programmer! And there is the same discrepancy between the way >people describe processes and the way they are actually conducted in >practice. > >Finally, I'm trying to think of a single product where most of the >actual construction process was *not* carried out by junior or >inexperienced staff. Architects don't lay the bricks and mortar, cars >aren't assembled by designers! Is software that much different?
Yes. Although there are analogies to be drawn between physical and informational engineering, it is easy to bump into the limits of those analogies very rapidly. Unlike car manufacture, in software the designers are responsible for the development of the system: programming is part of design not something separate from it. What constitutes the analogue of construction in software has been automated: depending on how you view it, the 'production' or 'manufacturing' stage is collapsed neatly into the acts of either copying of executable files or the compilation from code or other notation. What comes before the 'manufacturing' stage is design, which is a skilled activity no matter what level or angle is taken. Some design activities may be quite abstract, eg sketching a high-level architecture or relating general elements of the problem domain to mechanisms in the solution domain, whereas others are quite concrete and relate to the final formal and detailed specification of a system, ie code. Clearly aptitude for design varies across individuals, some are narrow and some are broad, some favour problem detail and some favour solution detail, and so on. But they are all skilled designers. Of course, skill varies with individual, and some are significantly more skilled than others. However, the notion that skill correlates well with job title I do not believe has been proven. So, the act of coding is not some menial job that can be dished out to low-skilled workers. Forget this and you end up trying to apply scientific management (a term whose whole contradicts its parts) to software development, incurring high costs and high staff turnover rate, and a certain amount of ingenuity by these skilled individuals working around the strait jacket of an overly hierarchical structure. This seems to match with your personal experience... as well as most of the rest of the development world. Prescribed and linear development processes of this type do have their place, but they are specific to certain domains rather than being generally applicable. Kevlin ____________________________________________________________ Kevlin Henney phone: +44 117 942 2990 mailto:[EMAIL PROTECTED] mobile: +44 7801 073 508 http://www.curbralan.com fax: +44 870 052 2289 Curbralan: Consultancy + Training + Development + Review ____________________________________________________________ ---------------------------------------------------------------------- PPIG Discuss List ([EMAIL PROTECTED]) Discuss admin: http://limitlessmail.net/mailman/listinfo/discuss Announce admin: http://limitlessmail.net/mailman/listinfo/announce PPIG Discuss archive: http://www.mail-archive.com/discuss%40ppig.org/
