Re: (OT) Team programming tools
From: Bret Comstock Waldow (bwaldow_at_alum.mit.edu)
Date: 08/22/03
- Previous message: Antonio Rodr: "where is the place to enable agp gart in kernel 2.4.21?"
- In reply to: Benedict Verheyen: "Re: (OT) Team programming tools"
- Next in thread: Shri Shrikumar: "Re: (OT) Team programming tools"
- Reply: Shri Shrikumar: "Re: (OT) Team programming tools"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
To: Benedict Verheyen <linux4bene@pandora.be> Date: 22 Aug 2003 16:37:19 -0400
On Fri, 2003-08-22 at 13:02, Benedict Verheyen wrote:
> Op do 21-08-2003, om 19:20 schreef Bret Comstock Waldow:
> > On Thu, 2003-08-21 at 04:23, Benedict Verheyen wrote:
> >
> > This is a little difficult to grasp. How does your team handle versions
> > of it's work now? And what language/environment are you coding for?
> >
> > The idea that management won't let an existing team use tools makes me
> > think there's some other background here, and we need to know that in
> > order to give sensible answers. Is it rather that there is an existing
> > tool set in place already that isn't useful for your group?
> >
> > A manager too dumb to allow a programming team to organize their work
> > defies sense.
> >
> > Bret
>
> Well, we are a rather small company (25 people) and of those 25 people,
> we have 5 programmers, including me. Everytime we sell a project
> management starts whining about time. In other words, they sell
> sollutions but don't really take good guesses at how much time it would
> take to produce the software.
> Allways whining about time, time, time, sigh.
Ah, yes. Professionally I am a Software Quality Assurance Analyst.
I've been specializing in automating test systems.
If half the airplanes fell out of the sky, or half the bridges fell
down, would we be so quick to keep the management that controlled that
process? Half or so of all software projects are not delivered.
Incompetent managers should properly be fired, but it's easy to pretend
with software. It's intangible.
> So basically we do not get time to study these tools because they don't
> see the need for versioning and so on. If we would use it and we
> wouldn't lose time implementing such a system, management wouldn't
> complain. That's why i asked for a quick and easy way to start using
> something like that.
The SEI (Software Engineering Institute) at Carnegie-Mellon University,
among other things, keeps track of the results of different process, and
the experiences of groups that try different processes. Their reports
show a 400 - 800% return on investment for every dollar spent improving
process.
I think your approach (sneak something in) may be the best one in your
case. Just do it.
> Additional problem is that one of the programmers hate's commenting his
> code and doesn't like to use tools like a cvs.
It's nice not to have to be responsible isn't it? Nice not to have to
clean up after yourself, communicate to other people. Very convenient.
If this programmer doesn't communicate design decisions, then your
validation system (testing?) ends up making the design and marketing
decisions, and they've not vetted by the oversight of the design team.
Clever.
One of the first questions I put to management is "is it more important
that the code the programmers create be good or the code that I create
be good?" After all, it's the (test) code I write that decides when
their (product) code is good enough to ship...
It's difficult to change something when one doesn't have control over
it. People do what the person signing the paychecks wants, even if the
perons signing publicly says something else, people will do what that
person really backs. Managers who don't understand software development
process cost companies quite a lot of money. Having been a programmer
does not mean understanding software development - there are lots of
hackers.
GNU/Linux manages hacking just fine - there's no deadline, and little
cost. Iterative process works fine for free software. (Iterative
process is not the only process at work in the free software approach,
there's peer review, inherent communication due to the use of email,
web, and cvs repositories, etc. Overall, free software development does
quite well. But not on a schedule.)
But Code-And-Test is one of the least reliable and predictable
development processes there is - so it's nasty for companies.
But it doesn't require any understanding or thought.
> We would actually be developing faster (reusable code) with these tools
> but somehow they aren't convinced of that.
A phrase I thought of - "The Arrogance of Ignorance". Another way to
say it is a phrase we used at my alma mater - "Proof by lack of a
counter-example". I got away with it this time...
Pretending is the cheapest way to be "right". You are up against
people's egos - and people don't like to admit their ego is the basis
for their choice - they want to pretend objective reality backs them, so
they don't have to admit their ego. Egos are the root cause of all poor
software, IMX.
Good luck,
Bret
-- bwaldow at alum dot mit dot edu -- To UNSUBSCRIBE, email to debian-user-request@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
- Previous message: Antonio Rodr: "where is the place to enable agp gart in kernel 2.4.21?"
- In reply to: Benedict Verheyen: "Re: (OT) Team programming tools"
- Next in thread: Shri Shrikumar: "Re: (OT) Team programming tools"
- Reply: Shri Shrikumar: "Re: (OT) Team programming tools"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
