The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Dev Project Sanity Check

I need a second opinion.

I have been assigned the task of writing an ERP package
from the ground - a completely greenfield project.

I will be the only developer.

This project will contain all the functionaility of a
typical accounting package (AR, AP, PO, SO, IN, etc).
It will also contain functionality to handle shipment
logistics and scheduling and CRM.

The only real restrictions I have been given is that
the user interface must be browser based and that no
MS dev tools be used.

Project timeline? Two years.

Realistic?

My current plans involve Python, PHP, Apache, Postgresql,
and XML-RPC.

JVR

Wednesday, January 04, 2006
 
 
I hope you have reams of documentation, or a good agreement about incremental development (XP-style).  Two months is probably too long for a sole developer to go off and work in isolation, let alone two years.
Timothy Mark
Wednesday, January 04, 2006
 
 
I'm currently at about 8 months or so on a slightly smaller but similar project.  Just released an early beta but I probably have another year of work ahead of me.  2 years isn't that bad -- I have tonnes of other requirements that stretch things out (must be "skinable" for one).
Almost H. Anonymous Send private email
Wednesday, January 04, 2006
 
 
This will be nothing but trouble. Any customer who says anything like "no MS dev tools be used" is going to be awkward. They want a solution they can brag about as being non-MS or open source, not the best solution possible. I'm not saying the best solution would be MS, but they have potentially ruled out the best solution before the requirements/design phase. Also, your plans appear to just be a list of tools.

Imagine if you asked a carpenter to build you a table. You told him not to use a table saw and all he told you was that he was therefore going to use a band saw and a drill. Would you pay upfront assuming you will get the table you want? Would the carpenter even attempt to build your table?
Itching-for-a-fight
Wednesday, January 04, 2006
 
 
"I hope you have reams of documentation"

Nope. No requirements documents as of yet. No use cases,
nothing.

Only an existing system kludged together from a mainstream
accounting package, some other third party apps and a bunch
of VBA embedded in MS Access and MS Excel.

JVR

Wednesday, January 04, 2006
 
 
I forgot to mention that, at the same time, I will be
managing our Asterisk based PBX, rolling out a wifi
project for the warehouse, mounting terminals on forklifts,
and managing our one PC support guy.

JVR
JVR
Wednesday, January 04, 2006
 
 
Are you responsible for gathering requirements then? How long do you have to finish this phase before you start the 2 year development phase? Will they be allowed to change the scope ad lib as time goes by? We don't have enough infomation to advise you.
Art Wilkins
Thursday, January 05, 2006
 
 
>>
This project will contain all the functionaility of a
typical accounting package (AR, AP, PO, SO, IN, etc).
It will also contain functionality to handle shipment
logistics and scheduling and CRM.

Project timeline? Two years.

Realistic?
>>

Short answer: No.

Consider an off-the-shelf accounts+CRM package that does all that. Estimate its total development time in man-years (yes yes I know). Is your answer: Less than 2; About 2; More than 2; Much more than 2?

What's your domain knowledge like? ie, how much do you know about accounts, shipping, scheduling, CRM? Think you can learn enough in 2 years?

This is a clear case of buy, don't build.
Larry Lard Send private email
Thursday, January 05, 2006
 
 
"Are you responsible for gathering requirements then? How long do you have to finish this phase before you start the 2 year development phase?"

Requirements gathering is included in the two year timeline.
I like an iterative approach though I lean more toward
RUP "lite" than XP.

JVR
JVR
Thursday, January 05, 2006
 
 
"What's your domain knowledge like? ie, how much do you know about accounts, shipping, scheduling, CRM?"

A lot. That concerns me far less than just having the
actual hours to get it done.

JVR
JVR
Thursday, January 05, 2006
 
 
Two years have been allocated to develop this, yet the actual requirements haven’t been done.  This is a red flag.  It sounds like two years was just a number somebody pulled out of their ass.

Do the requirements gathering first.  Then, estimate how long it will take.
John Senior Send private email
Thursday, January 05, 2006
 
 
Why do this from scratch?

Aren't there (1) existing systems that could be customized, or (2) source code packages, open or otherwise, that could be used as a starting point?  For that matter, and existing system could even be used to jumpstart and guide requirements.

I agree w/ Larry -- I don't understand the benefit of "build" here.
D. Lambert Send private email
Thursday, January 05, 2006
 
 
I'd strongly recommend getting existing products. Look at SugarCRM, that has far more than 2 man-years of development. Accounting has some tricky rules, and I don't think you want the risk of ending up in jail if you don't implement some accounting rule correctly. After Enron, "oops, I didn't know that" won't get you any breaks from the cops.

Re: Dev Project Sanity Check
Does not sound sane as described.
Peter
Thursday, January 05, 2006
 
 
I see ... dead people.
Sassy Send private email
Thursday, January 05, 2006
 
 
As others have said, two years is probably not enough given that you haven't even started the requirements gatering phase yet. But certainly two years should be enough to get "something" out the door. The question is, will it be considered a complete working solution that can fully replace everything they have now? Probably not.

I don't see what the big deal is about management putting a two year limit on the project up front. They are probably doing a simple man-hour cost calculation and comparing it to the cost of buying. Two years with one developer costs about $200K. They are pretty much saying that if they can build it for less than #200k then go for it. Otherwise, they would probably buy. It's up to you now to tell them what they could get for two years worth of work. They may come back and be willing to foot the bill for a third year if you are clear on what will and won't be delivered.
anon
Thursday, January 05, 2006
 
 
"This is a red flag.  It sounds like two years was just a number somebody pulled out of their ass."

Yes, that would be the CEO that came up with that
number. However, I have a choice between playing ball
or leaving the company.

JVR
JVR
Thursday, January 05, 2006
 
 
Well, then it looks like you have about 2 years (more or less) to find a new job. Take your time finding the right job while you're trying to do an impossible task.  Just don't work yourself to death trying to actually complete it within the given timeframe.
RocketJeff Send private email
Thursday, January 05, 2006
 
 
"This project will contain all the functionaility of a
typical accounting package (AR, AP, PO, SO, IN, etc).
It will also contain functionality to handle shipment
logistics and scheduling and CRM."

Even if you were the single best programmer on the planet, I would be very reluctant to trust all of these business functions to a single application that you developed and tested in two years or less.

Among other things, it also means that you'd have me by the short and curlies.  What do you think will happen next?  Yep, that's right - I will make your live miserable by adding requirement after requirement all designed to make sure that you, as the developer, don't have any control over the application you write.  What control you do have, I'll make damn sure you're liable for it.

Okay, okay, I'm probably exaggerating a bit.  But I agree with the others - he's probably thinking he can "buy" a solution like this for less than $200k, and its your job to persuade him there's a reason those solutions cost more than $200k.

If he still persists in believing he's right, you owe it to yourself and your career to start looking for a better opportunity.
Anonymous Coward
Thursday, January 05, 2006
 
 
I think that if it is up to you to gather requirements on an accounting package and you are not a licensed CPA, then you are engaging in malpractice. I think you will be held legally liable for all errors and consequences. Sarbanes Oaxley stuff means that unqualified persons are not allowed to do this sort of work. Then again, maybe you are a licensed CPA.
Art Wilkins
Thursday, January 05, 2006
 
 
"Accounting" is a very loose term. So are AR, AP, IN, etc.. I work in the Point of Sale industry and we do this stuff all the time. Yet we have no actual CPA's on staff.

I find it hard to believe that it would be considered malpractice if the company agrees that he/she is fit for the task. It is the company's responsibility to find suitable personnel (which may include hiring a CPA to help). It is not the programmer's responsibility to inform the company that he/she may not be qualified.

As a side note, I know two CPA's. And I wouldn't trust either of them to do my taxes. It must not take a whole heck of a lot to be a CPA. Just like it doesn't take a whole heck of a lot to be a programmer. Yet if you find a CPA or a programmer with specific domain knowledge and years of experience, they are worth their weight in gold.
Turtle Rustler
Thursday, January 05, 2006
 
 
"It is not the programmer's responsibility to inform the company that he/she may not be qualified."

In some industries, this is against Federal laws. However, for the sake of argument, "be qualified" is considered equivalent to "received appropriate training."

For example, the Nuclear Regulatory Commission (responsible for certifying nuclear reactors in the United States) will immediately reject any "safety" related software you write and fine you extensively for using it unless you can prove that you've at least read their requirements for quality software (quality in this case is synonymous with defendable and unlikely to cause injury or health issues).

I imagine the US Securities and Exchange Commission have similar regulations governing software written for Wall Street.

I agree that the programmer is not required to ensure they are qualified.  However, they do have a legal obligation to raise any suspicions to management and ensure that they are indeed qualified.  If management at that point chooses to proceed despite the lack of qualification, the programmer is no longer considered...  liable.

It is the same as my saying to you, "Yes, I'm aware you do not know how to use an arc welder, nonetheless, I am ordering you to seal that boiler full of flammable materials."
Anonymous Coward
Thursday, January 05, 2006
 
 
Check out http://www.plex.com

It sounds like it's already got what you want, and instead of waiting two years you could be up and running in two months.  By way of full disclosure, I used to work for this company, and I helped build part of that system (although good luck finding any of my code in it now, five years later).

It doesn't meet the "can't use Microsoft" requirement, but I don't think that your boss will balk too much when he gets what he wants a lot faster.

I can also vouch for these guys as having huge amounts of domain knowledge (one owner was a forging engineer for 10 years, the other owned several forging and machining companies).  They're also decent people that aren't going to try to rip you off.
Clay Dowling Send private email
Friday, January 06, 2006
 
 
JVR,

I don't think you have enough time for this, unless you are a  real super coder or can get off the shelf modules for much of what you are doing.

Also, don't forget about Perl. Python is the "in" thing but I still think you can get work done faster in Perl.
dot for this one
Friday, January 06, 2006
 
 
I'm moving an existing pascal based wholesale distribution program to MS SQL and Windows.  I'm using the existing program which the client loves as the model.  I am buying rights to source code for an exisiting program which does about 50% of what I need.  I have given myself 2 years to do the project. 

If you're writing it from scratch I would say it is nearly impossible to do in 2 years.  My client asked me to do it from scratch and I told him it was impossible to do it from scratch in less than 4 years. And this is using his existing program as the model.  I think 2 years is possible because I wrote the original and understand it fully.  But even I am insisting on using a MS SQL based accounting source code as the base upon which to build my conversion.

If he allows you to do this and expects you to be done in 2 years he's very deluded.  I can almost guarantee you will be late.  But hey, if he doesn't care why should you?
Donald Adams
Monday, January 09, 2006
 
 
Why not try Compiere ( http://www.compiere.org ).  If the reason for developing this software from scratch is custom features, it would be easier to integrate them into an existing open source project.

Here's my two cents:  every time I've seen this done, the project was a failure ... to effectively use any new tool, a business' processes must change.  When a company pays for an outside (and fixed function) tool, there is an incentive to change these processes.  When it is an internally developed product, there is no impetus to change business processes ... all issues become changes to the software.
Steve Moyer Send private email
Tuesday, January 10, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz