Subj : Re: Tools for software-developement
To   : comp.programming
From : Jonathan Bartlett
Date : Thu Oct 06 2005 03:14 pm

Christof Köhler wrote:
> Hello,
> for a project in my school i'm writing a report about tools for
> software-developement in a team.
> 
> I divided the hole process up into 5 points:
> - corporate planning and scheduling (e.g. resource planing ERP)

I've never seen any such thing used successfully.  You wind up with the 
same problems you had without them.  The only difference, perhaps, is 
that the time to completion is a calculated guess off of speculational 
data, rather than a speculated guess off of speculational data.

> - development (incl. IDE and VCS)

cvs
emacs
make

> - groupware for (team-) internal communication and todo-list

bugzill
sourceforge

> - quality management (e.g. bugtracking, issuetracking, tech.
> documentation)

same as above
documentation -
javadoc
DocBook
quality management -
JUnit (I believe the generic product is called nUnit)

> - external relations (customer and partner relationship CRM etc.)

I usually use people for this.  Then they are plugged into the groupware 
system.

> As fart as i found out it seams to be quite common to use a combination
> of different tools to fulfil the above points.

Yes, though real-life software development is a complete mess no matter 
what tools you use.  The biggest problem with software development is 
the differential between what is reasonable for the developer and the 
company being developed for.

On the developer side, programming is a creative and unpredictable 
exercise.  Schedules are essentially meaningless for development.  You 
can make predictable schedules, but usually you can only do this when 
you are so far committed to the project that you can't back out even if 
the schedule says you should.  In truth, programmers should be paid by 
the hour spent thinking, and schedules should not exist provided the 
programmer works.

On the company's side, they are looking for a tool to get the job done. 
  Anything less than a simple schedule, a solid list of deliverables, 
and a firm price is unfair.  They need to know before they commit 
resources what the timeline will be, what to expect, and what it will 
cost.

The waterfall method sounds nice, but it is unworkable.  In order to do 
enough analysis to come up with a predictable schedule, you basically 
have to pseudo-code the whole system.  A developer can't do such a spec 
with the company possibly turning down the work, so they would have to 
charge regular rates to do it.  But again, the spec work does not take a 
specified amount of time.  The company, though, probably doesn't want to 
spend the money for the spec work unless they know that it will be 
cost-justified in the end.  But they won't know that until after the 
spec work is done.

> / combination. If you could say: tool A and tool B work together and in
> conjunction they (partly) fulfil the points ...  would be great. :-)

The best thing to do is use small tools which do their job well, and 
then they don't have to work together.

Jon

.