Ron, > I didn’t realize that ALL ideas from the past have been discredited. I > must have missed that. I still choose to use a QWERTY keyboard. Maybe > we should revisit the past with things that have worked in the past > and try another development lineage. Total discredit? Not worth even > looking at again? Doesn’t sound like science at work to me, more like > religion.
That is not what I said. I said that 1960s 1970s views of software development process and practice have proved unable to provide an appropriate structure for good software development. In fact my company is founded on a software architecture idea from the 1950s that everyone else in the world ignored / threw away / thought was not trendy. History and the past are clearly the backdrop of all knowledge. Issue of science versus religion are very interesting but not a topic for this list I think. > I would think that most developers would invite some method of showing > (proving) their software is correct if it were in a usable/doable > tool/methodology. DFA’s seem to be that form of computation model. > But this depends on what type of REAL development you seem to be > talking of. Small systems can be coded by small teams, large systems > are more problematic. Small teams coding large systems with very > limited interaction (or no interaction as you seem to subscribe to) > leads to the embarrassing admission from Microsoft that this fall they > are going to reduce their company-wide automatic > software-patch-installers programs from eight to two (one for apps and > one for the OS). How does a overall very successful company allow > eight different programs do effectively the same thing? Eight-fold > duplication!! Sounds like someone needs to be talking/coordinating > with others. DFA / FSA / FSM are already a major tool in the system design arsenal. I am not sure what it is you are proposing. Your point about Microsoft clearly shows that their organizational structure needs refactoring. I think there are many companies in the same situation. > If you object to the term system analyst, why not just have the > configuration management (CM) person coordinate the test cases. Same > difference, just different terms. Who does the system architecture for > the whole system, one team of 2 who code 8 hours a day? Someone higher > on the education/experience curve has to write the system-wide test > cases. Thirty programs do not make a workable system without > coordination. It wasn't the terms that worried me it was the implied relationship between role and status. Coordination and checking are clearly important and is probably the role for the more experienced. Actually writing the tests doesn't have to be done by the most experienced and then handed down. Less experienced people have to learn and the best way is to try and then get feedback from the more experienced. So the tests should be written by the less experienced people and then the more experienced review, check and feedback. I know this sounds like a middle ages journeyman scheme but then system design and programming remains a craft skill. > In some system, provable is a requirement not a luxury. Heart monitors, > aviation software, and DSP do not do well with the GOOD ENOUGH > mentality that most programmers/companies have today. Just ship it, > we’ll fix the bugs later…… I am not sure about heart monitors but I know of far too many safety critical systems that have been constructed in ways that mean I refuse to use such systems. It si definitely the case that we need new ways of constructing safety critical systems. The issue here is that no matter how many Z / VDM / etc. specifications you write, unless the specifications are properly proved and are directly translated into native code and the translator is proved then there can be no "proof". This is perhaps the biggest silliness of the whole "Common Criteria" systems of safety / security validation. I know of a couple of systems that show promise but they are still in research and not really yet ready for full production use. > >Success in a project is more easily obtained when everyone takes > ownership of the >problem directly. > > Unless of course you have a weak team, maybe a bright office worker > moved into the coding department. You cannot always have smart (top > 25%) personnel to build into sharp teams. Some > countries/industries/companies don’t have an oversupply of bright > folks with the right educational background and experience ready to > move into the next big project. > > Software development methodologies and tools need to work with AVERAGE > programmers which, silly me, I thought this group was about. I am not sure I see the causal relationship. Just because a person hasn't got a first class degree doesn't mean they cannot be part of the team and take joint ownership of the problem. Actually I thought this discussion list was about psychology of programming which includes good, average and poor. On reflection all my comments have really been about social structures and management so I guess they are all off topic! > No final authority on a project? No UNIX guru in the lab helping people > or would having one be too divisive? I suppose too much knowledge in > one person dispirits the rest of the staff. Again I don't see the causal relationship in your comment. There is a final authority and that, at least in an industrial / commerical setting, is the relevant director but more usually their nominated delegated authority. However, as a management structure this individual can work with the development team so that the decision has buy in from the whole team. There will of course be differences in experience and knowledge throughout the team and most will have a guru -- sometimes a Windows guru of course as not all developments work with UNIX (even though they should and Windows consigned to the bin :-). Divisiveness and demotivation are serious issues where there is a range of knowledge / skills / experience in a team. The management skill is to avoid it happening or, if necessary take the disruptive element out of the team. The balance is whether 8 average people can do more than 8 average people and a disruptive superb person or more that the superb person on their own. > This discussion is depressing. Like much of what passes for computer > science research today (look up words like [agile | extreme] with > software on Google), everyone has a new methodology or new tool that > no one else will use or will only work in small amounts. We discuss > and argue, words just chase each other around the page, getting > nowhere fast. I don't think the discussion is depressing but the general state of Computer Science research probably is. I think this is one of the contributory reasons for me leaving academia and moving into a software development company. Kent Beck and co came up with eXtreme Programming as a result of their work practice, it was not research in the university sense it was evolution of a working process in a working context. The fact that the whole thing has been over-hyped out of all proportion is silly. Further comments on the state of CS research and the stupid pressures on academics and research are definitely off topic for this list so I will not write the 2000 word essay. -- Russel. ==================================================================== Dr Russel Winder, Chief Technology Officer Tel: +44 20 8680 8712 OneEighty Software Ltd Fax: +44 20 8680 8453 Cygnet House, 12-14 Sydenham Road [EMAIL PROTECTED] Croydon, Surrey CR9 2ET, UK http://www.180sw.com ==================================================================== Under the Regulation of Investigatory Powers (RIP) Act 2000 together with any and all Regulations in force pursuant to the Act One Eighty Software Ltd reserves the right to monitor any or all incoming or outgoing communications as provided for under the Act
signature.asc
Description: This is a digitally signed message part
