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
PGP signature
