From: Dave Thomas <Dave@...>
Date: 2002-01-03T05:10:09+09:00
Subject: [ruby-talk:30076] Re: Ruby/Python: Software Engineering

noone <nanotech@europa.com> writes:

> I interpret you as saying: Methodologies are customized to one's
> tools.
> 
> Is this fair? If so, when beginning a project do I "assemble my
> toolbox" and then ask "Ok, now, how do I go about building this
> thing using these tools?" Would it be better to think about how I
> want to build it and then look or even create the tools necessary to
> work that way? Would not this be the more productive way? How do
> improvements in processes occur when the focus is on the tools?

The reality is that some things are fixed and some can be
changed. Some of these things are tools, and some are methodological
(if that's even a word). For example, a project might be constrained
to use Java (tool), to use Tomcat (tool), to have a business analyst
proxy for the customer (methodology), to have a maximum of 6 people
(methodology), and so on.

The team's job is to look at these constraints and fill in the blanks,
both in terms of tools and in terms of methodology, in such a way that
the project stands a hope of succeeding. For example, having decided
to use Ruby/Python/Smalltalk, a team might then say "ok - we need to
make sure we do thorough unit-level testing to make up for potential
problems introduced by a lack of compile-time type checking". Here, a
choice on the tool side affected the methodology.

Alternatively, the methodology may call for continuous integrations,
so the team would want to ensure they include source control and
automated build tools into their toolkit. (Of course there are other
reasons, but...) Here the methodology affects the tool choice.

Ultimately it's a non-linear optimization problem: the best way to
solve these is to iterate: start off with a good guess and see how it
goes. Then change something and see what happens.


Regards



Dave