A question to experienced Pythoneers

[Rony]

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 basicaly have 'carte blanche'

One of my plans is to introduce Python as development tool.
They mostly develop back-office software, and at the moment they do it
all in C with MFC.
Another new requirement they have, is that the new product should run
on Win & Mac.

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.

What do you think of this ?
Another point of attention is that the software isn't Open Source, it
is a commercial package. So protection of sources is important.
Now I know that anything can be decompiled, even C. The only question
is, how hard is it and how much effort must someone do to decompile
and retro engineer code to understand it.
I think by putting all program logic in Pyd files that I would be
quite secure ?
On a side note : Is it harder to decompile PYD files then PYC files ?

I allready had a meeting with the developpers and did a presentation
of python with wxwindow, mostly with an open source project where I
contribute to the development. They didn't see any big problems to
learn Python fast and they allready know C.

All opinions, advice here is welcome

Tia

Rony

 

[geremy condra]

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 basicaly have 'carte blanche'

One of my plans is to introduce Python as development tool.
They mostly develop back-office software, and at the moment they do it
all in C with MFC.
Another new requirement they have, is that the new product should run
on Win & Mac.

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.

What do you think of this ?
Another point of attention is that the software isn't Open Source, it
is a commercial package. So protection of sources is important.
Now I know that anything can be decompiled, even C. The only question
is, how hard is it and how much effort must someone do to decompile
and retro engineer code to understand it.
I think by putting all program logic in Pyd files that I would be
quite secure ?
On a side note : Is it harder to decompile PYD files then PYC files ?

I allready had a meeting with the developpers and did a presentation
of python with wxwindow, mostly with an open source project where I
contribute to the development. They didn't see any big problems to
learn Python fast and they allready know C.

All opinions, advice here is welcome

1) Don't take this the wrong way, but get in the habit of using proper
grammar and spelling. Especially as a consultant. It will make the job
of convincing people to take you seriously that much easier.

2) Use the tools at hand. If your developers don't know Python, you
could wind up wasting a lot of talent turning a top-notch C developer
into a bottom-tier Python developer, assuming you don't lose them
altogether.

3) Don't rewrite critical code in a new language unless you have
somebody who really knows what the hell they're doing. All you've done
is turn programming's usual first-order ignorance into a much harder
second-order problem.

4) Don't fool yourself into thinking that your code can't be
decompiled. Odds are your code isn't worth decompiling, but it isn't
hard, and a surprising number of people have the requisite skills. It
certainly isn't 'secure'.

Also- in my experience when people say 'I don't see a problem' to a
consultant, what they really mean is 'I don't think you'll be around
long enough for this to be a problem for me', but you may have the
tools to deal with that.

Happy hunting,
Geremy Condra

 

[Rony]

1) Don't take this the wrong way, but get in the habit of using proper
grammar and spelling. Especially as a consultant. It will make the job
of convincing people to take you seriously that much easier.

I don't take it the wrong way but have an answer
I'm French and doing my best to write understandable English...

Thank you for your answers.

Also- in my experience when people say 'I don't see a problem' to a
consultant, what they really mean is 'I don't think you'll be around
long enough for this to be a problem for me', but you may have the
tools to deal with that.

I'll keep this in mind

Thank you

Rony

 

[Lawrence D'Oliveiro]

In message

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.

<http://groups.google.co.nz/[email protected]>

 

[Rami Chowdhury]

Here's the story :
I've been hired by a company as a consultant to reorganise there
development department. [snip]
One of my plans is to introduce Python as development tool.
They mostly develop back-office software, and at the moment they do it
all in C with MFC.
Another new requirement they have, is that the new product should run
on Win & Mac.

[snip]
2) Use the tools at hand. If your developers don't know Python, you
could wind up wasting a lot of talent turning a top-notch C developer
into a bottom-tier Python developer, assuming you don't lose them
altogether.

3) Don't rewrite critical code in a new language unless you have
somebody who really knows what the hell they're doing. All you've done
is turn programming's usual first-order ignorance into a much harder
second-order problem.

+1 to both of these, personally. If the developers are used to C and
MFC, but you need to make the product run on the Mac as well, have you
considered C / C++ GUI frameworks like GTK, WxWidgets, or Qt? Porting
your GUI to those might be a better use of time than porting the
software to Python...

 

[Stefan Schwarzer]

Hi Lawrence,

In message


<http://groups.google.co.nz/[email protected]>

I can't get the page; all I get is an error message:

"""
Not Found

The requested message, [email protected], could not be found.
"""

Can you please give a part of the message to search for or
even better, an URL that works?

Thanks,
Stefan

 

[Stefan Schwarzer]

Hi Rony,

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

 

[Rony]

It looks like I forgot to specify that the product is a totaly new
product build from scratch, not an upgrade from an existing product.

Interesting answers !

Rony

 

[Bruno Desthuilliers]

Rony a écrit :

It looks like I forgot to specify that the product is a totaly new
product build from scratch, not an upgrade from an existing product.

Still the advice to first find out what went wrong with the previous
project is a very sensible one. Technical problems do exist, but from
experience they rarely are the main source of failure.

 

[Aahz]

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.

Keep in mind that the real problem may have been that upper management
forced a completely unrealistic deadline. They may also have had
difficulty translating "development effort" into Real World Timing [tm].
(For example, when I tell my boss that something will take three days of
development effort, I also make clear that between support and production
issues that I need to help with, not to mention meetings, mentoring other
people on my team, etc -- those three days will almost inevitably expand
into six business days BEST CASE.)

Try to have some quiet, off-campus discussions with developers to gather
information.

NOTE VERY CAREFULLY: if you promise to keep a conversation private, KEEP
THE PROMISE.

 

[Martin Gregorie]

Rony a écrit :


Still the advice to first find out what went wrong with the previous
project is a very sensible one. Technical problems do exist, but from
experience they rarely are the main source of failure.

And be sure to look into the estimation and costing methods the company
is using. IOW are you sure whether design/build/test phases are
overrunning a sensible estimate or if the initial costing and estimation
is underestimating the project size?