Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Sincerely ask for your suggestion on our project

18 views
Skip to first unread message

shuisheng

unread,
Feb 26, 2007, 1:19:47 PM2/26/07
to
Dear All,

We major in computational electromagnetics. Our research object is to
develop efficient algorithms to model electromagnetic waves in complex
media. After years of reserach, we developed some good algorithms. We
tried to commercialize our research. So we started a software project
a year ago.

We hired two guys. One worked on GUI, and the other on Kernel. We
hoped to finish the project in three months. But the results was not
as we expected. Even now, the project is not finished. We just have a
coarse version to run some simple cases. And the code is full of bugs
and bad smells (repeated code, switch/case on type id, large classes,
large functions (some have more than 1000 lines), no consistent coding
style ). In fact, the code size is not very large. It is about 60,000
lines. And we think it can be compressed into less than 30,000 lines
if removing the repeated codes.

Now we are reading some project management and software design books.
And we found that our project in fact has no management. We are just
coding, repeatedly give a task deadline and ask the developers to
finish it, though the deadlines can never be met. There is no
requirement analysis, no system design, no testing, and so on.

We don't want the project fail. What should we do in the next step?
Modify our current ugly version, or renew one and do it accroding to
what the software project books teach us (we still have no experience
on it)?

We appreciate your kind help!

Shuisheng

Dmitry Melanchenko

unread,
Feb 26, 2007, 3:19:03 PM2/26/07
to shuis...@yahoo.com
Hi,

As I understood from your post main part of the task was already done..
It means that you already have good algorithm for your project.

My recommendation about software part of the project is:
1. Review quality of the algorithm implementation. Because nobody needs
you program w/o the part.. i guess
2. Make analysis of already done work. You need to understand what tasks
already implemented at least partly.
3. Prioritize all the implemented functionality.
4. Estimate performance of your developers
5. Estimate time required to finish each task. Take your estimation and
multiply by 3.
6. Establish testing for your product. I propose automated testing for
core and manual for GUI part
7. Make detailed plan for your project development.
8. Track your project according plan and update all the estimations
And etc.

One of the main problems of all endless projects is: Unstable scope of
work. You want something new all the time.

Anyway.. i recommend you keep all the already done code at least for
first few iterations. As soon as development process will be established
in your project you may start refactoring of your "bad smells" code.

Fill free to contact me if you need any other recommendations and
directions. May be my post is not really useful because of lack of
details :-)

--
Dmitry

H. S. Lahman

unread,
Feb 27, 2007, 11:37:38 AM2/27/07
to
Responding to Shuisheng...

> Now we are reading some project management and software design books.
> And we found that our project in fact has no management. We are just
> coding, repeatedly give a task deadline and ask the developers to
> finish it, though the deadlines can never be met. There is no
> requirement analysis, no system design, no testing, and so on.
>
> We don't want the project fail. What should we do in the next step?
> Modify our current ugly version, or renew one and do it accroding to
> what the software project books teach us (we still have no experience
> on it)?

You already have a 300% overrun on schedule with no end in sight. You
have identified the problems as (A) lack of managed development process
and (B) lack of a reasonable design methodology.

At this point refactoring the existing application is probably not going
to solve the problem. Things like 50% redundancy are symptoms that the
fundamental structure of the application is ka-ka and you can't fix that
with refactoring. So my advice would be:

(1) Pick a design methodology from one of the books you read and get
everyone trained in it. It doesn't matter which one; the differences in
methodologies are second order effects compared to the step function
between practicing vs. not practicing one. [By training I don't mean
everyone reads the book. Get a consultant in who specializes in the
methodology and have him provide training and mentoring.]

(2) Pick a set of process tools (e.g., requirements specification, peer
reviews, IID, etc.) from one of the books you read and put them in place.

(3) Start over and do the development right.

BTW, according to your numbers you would expect the application size to
be ~30 KLOC without duplication and you have 2 developers. Back in the
'70s premier hackers would produce 100 KLOC/year but is was garbage code
(been there, done that). Today 15 KLOC/yr/developer of high quality
software would require very good developers. So I think the original
estimates were unrealistic.

[Anecdotal data point. Where I worked before retiring the productivity
ranged between 4 - 7 KNCLOC/yr/developer. (1 NCLOC ~ 3 LOC, depending on
language and commenting practices.) That shop produced 5-Sigma R-T/E
applications at rates that were integer factors greater than published
data from Major Players in the industry for comparable applications. But
that shop was very top-heavy with superstars.]


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
h...@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
in...@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH

0 new messages