As Russell suggests, developers need tools in order to be able to develop code. The question about why people choose the tools they do come down to issues that are more complex I think than the reliability of the platforms that those tools run on. Russell goes deeper than this when he suggests "that knowledge and skill and experience of the quality programmer are not yet understood sufficiently to make a tool to come anywhere near full support of the human let alone replacement of the human" but I think we have to go deeper still. What are the different contexts in which developers work and what impact does this have on the tools they use? Does it make sense to talk of 'the developer' or does it make more sense to talk of categories of developers? What categories does it make sense to talk about? For these categories of developers, what makes them choose one set of tools over another?
Clearly some of the reasons are outwith the control of the developers themselves (e.g., company wide policies, company license agreements, availability etc). But the more interesting and difficult issues are the ones that I think the PPIG community probably has a lot of valuable input, such as discovering the aspects of work that make some set of tools more applicable and usable than others. For example, what is it about the way that Linux developers work that makes them favour Linux and Unix based tools (outwith of the quasi religious fervour for Linux and Unix based tools, which isn't shared by all developers who happen to use these tools). With a much better understanding of the way that developers work, we'd be in a much better position to deliver tools that work well for different groups of people, rather than trying to foist our own biases and opinions on people. To address concerns Derek, Frank and Russell raised about the impact of PPIG research in industry, as a usability engineer working on the Visual C++ product at Microsoft, I've been trying to use the cognitive dimensions framework in my job to address some of these issues. But what is its scope? Does it address all of these issues? Indeed, what are these issues? As an example, for some developers, it seems that the language they choose to develop is almost irrelevant - it's the availability of rich and powerful frameworks and class libraries that determines the language and tools they will use. How do we apply the cognitive dimensions to class libraries and frameworks? Or is there some other tool/method that is more applicable? I'd really be interested in hearing from anyone who is working on these sorts of issues and has some interesting research that they'd be willing to share. Steven -----Original Message----- From: Russel Winder [mailto:[EMAIL PROTECTED]] Sent: Saturday, October 27, 2001 7:19 AM To: [EMAIL PROTECTED] Subject: Re: PPIG discuss: Capitalist goals. (Was: Similarity andcategorization) Derek, Frank, I refrained from joining this debate till now as I would have ended up writing lots of very large emails -- there were so many points being made that were "buttons" for me. Although I have missed the opportunity to "sound off" of many points I would have like to, I finally felt I had to dive in now. Sorry if this gets too long. It is clear that in architecture and electronic engineering the arrival of support tools helped the good practitioners get better and the bad practitioners be as bad as ever. In any design arena people of quality (high skills, lots of experience and very professional) are needed and tools can help them, the tools cannot replace quality people (at least for now, perhaps in 2482 thjngs might have changed). The obsessive desire of some management to dispense with quality staff so that they can employ cheap graduates since they know that there are tools that can replace the skill set of the quality staff is clearly a crassly stupid position and indicates the lack of management skills of the offending management. Frank said: > Better software development helps everyone, businesses included; even > badly run ones who think that the road to success is built by cutting > costs. Far too many businesses are run on the lines of "cut costs now" as a mantra because they do not actually understand that the real rule is "create better returns on investment and improve overall profits".=20 Stupid managements that do not invest in the skill set and experience of their workforce must clearly have studied Taylorism without actually understanding what he was really about. (I actually disagree with the Taylor approach but most people don't try and get behind the sound-bytes that people offer on his work.) > I don't think it's any surprise that a significant number of programmers > that I would call 'good' (experienced, skilled in the art and > intrisically motivated to do good work) are now working with software > produced outside conventional business models, such as Linux. I also > don't think it's any surprise that software like this is actually > having a widespread positive impact, especially in business. I am not at all sure that the rise of Linux and the rise of new business models are directly related -- associated certainly but not causally.=20 In some domains, e.g. embedded systems development, far too many people are stuck with dreadful Windows-based tools because many tool vendors think that everyone uses Windows and that there are no other operating systems. Those that are not stuck in the quagmire generally use systems like Linux when they can because Linux works and Windows is a pain in the rectal region. The rise of Linux is partly a quasi-religious/social phenomenon but mostly to do with speed and efficacy not just of the operating system but of the process of development supported by the operating system and the flexibility it offers compared to Windows. Note that most developers I know when forced to use Windows load Cygwin (the UNIX toolkit for Windows). Although this could be seen as a quasi-religious thing, i.e. UNIX at all costs and damn Windows, it is actually much more about having the right tools for the job. The obsession Windows has with IDEs (forced really by the environment) can make some tasks faster but restricts flexibility in such a way that it really hinders development. The alternative obsession of UNIX with the classic software tool philosophy can lead to some problem of integration but provides so much more flexibility that overall productivity is significantly enhanced. I don't think this is simply a matter of mind set either but I don't have anything other than anecdotal evidence to back up this view. The rise of new business models (at least in software arena) is really connected with the final (hopefully) demise of the view that the waterfall model actually has any relevance to the way that software is constructed. Standard project management techniques may be applicable at the top-most levels of large projects but the stupidity of trying to use these techniques to manage a 2-month software development project is generally self-evident to any quality project manager -- but not to the tool vendors. The rise of the self-directing team philosophy in projects across a wide spectrum of work can be seen as being echoed in the rise of RAD, especially DSDM, and techniques such as Refactoring -- I hestitate to use the term eXtreme Programming here since that is often seen as hacking for hackers by people who don't understand what is behind all the XP hype -- and there is a lot of !"=A3=A3$%^& written about XP by both the people for and the people against. Computer Science departments across the world and Software Engineering book authors, pick the three obvious ones, need to extricate themselves from 1960s software development paradigms and get with 1990s and later management approaches. > (I dare you to start a discussion in the linux-kernel mailing list > about how the kernel needs to be re-written so that Joe I-Can-Spell-C > can muck about with it using some do-my-thinking-for-me tools his boss > foisted upon him as part of some corporate methodology.) No point, unless you want 100MB of hate mail per day. Also of course, no-one has yet built a tool that can reason about non-determinstic, asychronous concurrency which rather rules such tools out for working on an operating system, Windows even let alone Linux. Could it be that Micro$oft hired Joe I-Can-Spell-C to write Windows95/98/NT/2000/XP?=20 Actually anecdotal evidence has it the WindowsXP may finally have=20 concurrency management that doesn't crash three or four times per day. The issue here is that knowledge and skill and experience of the quality programmer are not yet understood sufficiently to make a tool to come anywhere near full support of the human let alone replacement of the human. Moreover, the mathematics is not yet developed that is usable as a tool by practitioners. The gulf between practical machine architectures and programming languages and the theory of computation, semantics and non-determinism is still a very large yawning chasm. With luck there will be convergence but=20 Derek wrote: > > Yes, automated tools will remove the need for 'good' programmers. Sorry Derek but this is just carp. Automated tools will just make good people better -- poor people won't be able to the use to tools effectively. Frank replied: > No, they won't, any more than automated tools will remove the need > for good writers, architects, doctors, teachers, hairdressers or > any activity that's more than just a mechanical process with people > in the loop. Tools just change what talent and skill can be focussed on. Absolutely. We have seen this already with software development. How many people still use paper tape and manual punch to enter their programs. But note though that although we have seen developments in programming languages Fortran, Pascal, C, C++, Java (shows my bias!), many people still work in assembler because they have to. Tools have a cost and if the cost of the tool is unacceptable then another tool must be used. Derek said: > > But the purpose of software development is not to create a cadre > > of good programmers, but to make money for their employers. I think this statement misses the point and lines up too easily the statements Frank made. However, I think Frank's comments also missed the point. Frank replied: > The *purpose* of software development is to develop software. That > business currently finds this useful is a bonus, and helpful to > those who'd like to earn a living from it. Even if business didn't > find it useful, it's still an interesting and legitimate field of > study and research, for many reasons. But the purpose of > software development is certainly not to make money, any more > than the purpose of, say, the performing arts is to make money, even > though they can be used for that. The purpose of any software development within a commercial/industrial context must be to further some aspect of the business. This can be either internal or external: internal stuff is to improve the business in some way, external stuff is creating product to sell in some way.=20 All the talk of "making money" over-simplifies the situation and therefore makes the debate fruitless. Also whilst creating software is a human inspirational activity to try and connect software development and performing art seems detrimental to both since it implies metrics on both that are totally inappropriate. Derek said: > > If psychology of programmer researchers were a bit more in tune with > > these capitalist goals they might find their research more widely used > > within industry. They might also find it easier to get funding for > > projects. Frank replied: > If there are any researchers on the list who've stayed with us > this far :-) , they might care to speak to this point. But the point is, for all the study of PsychOProg, what have been the outcomes? Certainly there is some data from experimentation but has there been any technology transfer (via tools and/or work practices) or is the field still in the data gathering and no theorizing phase? HCI still appears to have no structured input into systems development. Most user interfaces are developed by geeks like me and my staff on the basis of what we think is cool. Or UIs are developed by copying others -- WindowsXP appears to exhibit more Macintosh envy than ever before, but with round corners and pastel shading. The issue then is either work continues and is funded because people want to and can convince others to allow it (the arts argument:-), people can learn things to the benefit of mankind (the science argument) or it can show deliverables (the commercial argument). EPSRC and others, I suspect, are now obsessed with the commercial argument and have lost sight of the science argument. So where does PsychOProg sit on this? What I want (as a professional software developer and manager of a team of people) is for a better understanding of how we work at software development so that we can develop and use tools and work practices that maximize our achievement and enhance our enjoyment. Self-directing teams/RAD etc. are helping but this only deals with gross management. What I need are results that apply on a day-by-day, minute-by-minute basis for software construction. I could go on a lot more but I think this pseudo-essay needs to terminate sooner rather than later! -- Russel. ==================================================================== Dr Russel Winder Chief Technology Officer OneEighty Software Ltd Tel: +44 20 8680 8712 Cygnet House Fax: +44 20 8680 8453 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 - Automatic footer for [EMAIL PROTECTED] ---------------------------------- To unsubscribe from this list, mail [EMAIL PROTECTED] unsubscribe discuss To join the announcements list, mail [EMAIL PROTECTED] subscribe announce To receive a help file, mail [EMAIL PROTECTED] help This list is archived at http://www.mail-archive.com/discuss%40ppig.org/ If you have any problems or questions, please mail [EMAIL PROTECTED]
