Dealing with Difficult Development?

jjwahl queries: "I've recently been handed a funded web development project, and in an industry where almost any paid work is good work this is a welcome opportunity. This database intensive site basically has the look and feel developed but none of the plumbing. I have been given the job to create the database and write the code to make the site work - all at a reasonably good rate and with a time and materials payment structure (i.e. this is not a fixed cost project). Sounds like good news, right? Not necessarily." The company wants the work done in a timeframe that prevents a well thought out design and pretty much eliminates a decent testing phase. How would you handle working on such a project?

"Why [is this not good news]?

The project timeline is insanely short given the complexity; there is nothing of substance developed yet - no schema, nothing; given the timeline, all schema development will have to be done on the fly - no time to sit down, take a holistic view of the project and develop the schema properly; and there is also no timeline for testing - other than the ad-hoc testing a developer does, there is no time for formal testing at all. All of this means that I'm basically going to develop this site on the fly which means that I'll eventually make mistakes, and won't have a proper testing cycle during which I could catch them -- the public will catch them, instead and complain.

I'm afraid that despite my heroic efforts to bring this site to fruition, this job will look sloppyand reflect badly on me. Have any of you been in a similar situation? How did you deal with it? Should I just turn the project down?"

Comments

Is this a trick question?

[Neck_of_the_Woods]

Everyone has been in this position!

What, never heard the saying:

Good, cheap, Quick: Pick 2.

State your concerns now. Clear the air and let them know your issues. Do this NOW!

If your scared they will drop you, well that is something you need to think about. Not saying anything is going to make look sloppy or a dolt.

So are you a dolt, or do you have the brass balls to let them know this is unrealistic. Either way make a choice and let them know. Let them make a decision or shut up and grab a paycheck with both hands.

Good luck.

If you can't do it properly...

[Anonymous Coward]

Don't do it at all!

Having been in a similar situation recently, I would strongly suggest you turn the offer down. The risk of delivering a failed project, either over time, over budget or simply not working is far too great. Unless they plan to pay you an ungodly sum of money to offset the risk (the old risk/reward balance...), it is probably not worth the stress and frustration.

During the project I had the misfortune to be involved in (after it went down the drain), the project manager had a very firm committment to the delivery time and essentially decided to forego testing altogether. The day the site went live, it took all of five minutes for the whole thing to crash horribly. When I was called in to clean up the mess, I discovered an enormous amount of sloppiness, security holes and "shortcuts" which made it almost impossible to fix. The developers who delivered this site were clever guys and had successfully implemented similar projects, but the time and budget constraints made it impossible for them to deliver decent work.

From the question, I take it that your concerns are the same in this instance. The answer should be that if you don't think it can be done with a reasonable support framework of decent design and proper testing, it is not worth the exposure.

Tell me about it...

[jeneag]

Working as a contractor, developing banking software, where more then 50% of the calculation and security build with JavaScript (!), I asked my manager, what the hell are you guys thinking? He said, as long as it looks good, client will buy it. Plain and simple.

Several options

[rkwright]

1) Do you have any rapid development tools at your disposal? Depending on the technology involved, you could leverage certain tools like Visio or any of Rational Rose's products in order to quickly generate the database scripts and/or skeleton code; however, for this to actually be useful, you have to already be familiar with these tools in the first place (and thus not spend half your time looking for the right menu options or diagram shapes).

2) Could you perhaps break up the functionality into phases? Sometimes the best way to do it is to give them some initial functionality sooner, then deliver the rest as a "phase 2". This will give you the chance to deliver a more solid "phase 1" that both you and the client will be satisfied with.

3) If the client is not willing to work with you on the timeframe (or they are not willing to negociate a solution in the above idea), then definitely state to them that you cannot accept the project, and that furthermore you want to give them a little advice that whomever does accept the project will probably deliver a shoddy solution, given their rigid timeframe.

I deal with this quite a lot at my company; however, I've found that our business people and our outside clients are actually rather receptive to a phased release schedule, especially if you can deliver their important features earlier and then leave the less important features to a "phase 2."

Log everything.

[TheSHAD0W]

Keep a chronological log of every change you make to the database. If there's a serious bug that corrupts the data, you'll be able to rebuild the thing from your log.

Do that, and keep praying.

me?

[DonFinch]

Deliver a poorly designed, untested system on time, or let them know it will be past due, they pick.

Use prebuilt components

[mosabua]

Depending on the specifications you will gain quite a bit by using systems that are already out there.

E.g. you can use the an open source content mgt system for the basic site and write a plug in for the specific needs. Try e.g. Postnuke

if you are aiming for a LAMP solution.

Please don't work for free.

[Inoshiro]

"and in an industry where almost any paid work is good work this is a welcome opportunity"

If you work for free, or undervalue your work in a consulting situation, you are putting other people out of work. I don't mean writting GPL code. I mean that just because you are unemployed and collected on it, does not mean you should help people with problems without billing them. If you do work and are not paid for it, you are merely volunteering.

What to do

[GoRK]

If you're short on time, why in the hell are you wasting it asking slashdot? By the time you get any answers from the masses, you'll have blown a day or two of good work.

If you can do it in the timeframe and feel confident that you can deal with the problems that will occur down the road due to the initial rush, then go for it. If you don't want to, then don't take the job.

Jesus, you're supposed to be someone that people hire when they have problems they cannot solve, yet you seem unable to grapple with a simple diliema such as this..

People underestimate the need for leadership.

[Futurepower(R)]

People vastly underestimate how much leadership is necessary to make something good happen. It regularly happens that customers do something self-destructive or ignorant. The main job of a consultant is not to write good code, it is to provide excellent guidance.

A common answer to this observation is, "I'm a programmer. I just want to program. They should do the management." This makes sense, but doesn't seem to be the way the world works. The reality is that there is a severe shortage of management, especially technical management. You will be expected to provide some. It is like a party held during a famine; everyone is expected to bring food.

Leaders are people who try to resolve conflict. It is the job of a consultant in the situation you mention to understand the customer, including the customer's psychology, and provide whatever is necessary to do a good job. If you know better than the people around you, you are the leader, even if you are not the acknowledged leader. If the customer is self-destructive, that means that you are the leader. Otherwise you are just accepting craziness and filling your life with it.

Often an impossible deadline is just an expression of hidden fears that programmers cannot be trusted. Often an impossible deadline is a symptom of ignorance about how to manage a technical project. Sometimes people think that by encouraging other people to work 12 hours per day they will get more useful work for their money; that is not actually true because of mistakes and fatigue.

Underestimating the need for leadership is a symptom of a larger misunderstanding about life. People regularly underestimate the minimum complexity of life. In actuality, people are usually doing crazy things; craziness is happening all around you. If you look closely, it is very likely you will see that the example you gave is just one of many crazy things happening at the company that is suggesting the impossible deadline.

Cut the scope

[lux55]

When the deadline of a project is shortened, your human resources are capped, and you can't cut back on the quality (any further), there's nothing left but scope. Tell them to take their pick, or make recommendations. Tell them you'll have to push some of the functionality back into a "phase two".