I've been a small cog in a team that seemed (from my perspective) to work exactly like Ronald Finkbine described, in the mid 1980s. Now I'm an academic (and I still work with industry), I don't personally feel especially out of touch with the reality of software development.
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? All the best Stuart ================================= Dr Stuart Watt School of Computing, The Robert Gordon University, St. Andrew Street, Aberdeen, Scotland, AB25 1HG Email: [EMAIL PROTECTED] / [EMAIL PROTECTED] Tel: +44 1224 262723; Fax: +44 1224 262727 URL: http://www.scms.rgu.ac.uk/staff/sw/ -----Original Message----- From: Derek M Jones [mailto:[EMAIL PROTECTED] Sent: 21 August 2003 01:01 To: [EMAIL PROTECTED] Subject: Re: PPIG discuss: (no subject) All, >> First, languages can be complex but programs should be simplified >> according to the Chomsky hierarchy of languages. The systems analyst ... >I really do not believe your traditional hierarchy management model of >systems development is either workable or worthy of research. Systems I thought the writer was simply providing a good example of how out of touch academic research is with reality ;-) >Success in a project is more easily obtained when everyone takes >ownership of the problem directly. This is certainly one of the thinking being some of the current trendy methodologies. However, it lacks as much experimental supports as most of what went before it :-( >Software development is a human inspirational activity not a mechanistic >physical activity. I would not go to either of these extremes. The interesting thing about source code is that most of it is very similar and outwardly quiet non-interesting. I think developers do a lot of things mechanically and are not aware of it (and yes, I have as much proof of this claim as everybody else has for theirs). > Anyone studying software development must, must, >must lose the connection between software development and production >engineering. Lets not forget the fact that software development is one of the few professional activities where the most junior and inexperienced staff get to write most of the important parts of the product that the customer actually uses. derek -- Derek M Jones tel: +44 (0) 1252 520 667 Knowledge Software Ltd mailto:[EMAIL PROTECTED] Applications Standards Conformance Testing http://www.knosof.co.uk ---------------------------------------------------------------------- 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/ ---------------------------------------------------------------------- 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/
