A question to experienced Pythoneers

[Stefan Schwarzer]

Hi Rony,

On 2010-08-20 10:16, Rony wrote:
> Here's the story :
> I've been hired by a company as a consultant to reorganise there
> development department.
> The actual situation is :
> The manager of the development has been fired, main reason (what they
> told me) is that they have big big troubles in keeping deadlines ! For
> there last product, for which they estimated 3 man years of
> development they had 9 months extra effort, and the product was
> delivered a year to late.

I guess the most important issue will be to find out what
was wrong with the development process and fix the problems,
i. e. don't repeat them. Keep in mind that "what was wrong"
can mean any number of reasons.

Until you haven't dealt with this, thinking about changing
the programming language in my opinion makes little sense.

> I basicaly have 'carte blanche' :)

Um, yes ... with the corresponding responsibilities and
risks. :-)

> So, my strategie would be :
> - Use Python and wxpython for the GUI
> - Develop critical routines in Pyrex or in C and make PYD's from it
> which will be imported by the main Python programm.
> - Distribute with py2exe on Win & py2app for Mac.

You plan to change a process (and people) used to developing
with C to developing with Python and the associated tools.
For a developer experienced with both C and Python, using
the latter usually will result in faster development. On the
other hand, switching to a tool you (i. e. an individual
developer) never used before adds some risk (-> uncertainty
in effort estimation).

If the project you're dealing with now is based on the
project you mentioned above, you better not start from
scratch in a different language. Very likely the existing
code will have subtle though important fixes for subtle
problems which were encountered during development. If you
start from scratch you risk losing these fixes and having to
re-discover the problems and fixes which can take a lot of
time. Even if you have all programmers of the old team
available, it's risky because they might have forgotten the
parts of the code or they may no longer be around when
you're about to implement the functionality of these
critical parts of the code.

If you haven't already, I recommend to read these books:

Steve McConnell
Rapid Development
http://www.amazon.com/x/dp/0072850604/

Tom DeMarco, Timothy Lister
Waltzing With Bears: Managing Risk on Software Projects
http://www.amazon.com/x/dp/0932633609/

Stefan