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

golden consulting rule: Learn when to "No Bid"

[ubiquitin]

Sounds like you need to take a look at the Golden Rules of Consulting. The relevant rules are: be the professional's professional, know when to "no bid" and know your customers. It sounds from the description that you need to provide some assistance with not only execution of the project, but give advice on what is a reasonable methodology and/or time frame for it. Advice to adjust goals is hard to give diplomatically, but often the most needed.

Have you tried telling them this?

[Klaruz]

Make them understand the site needs to be designed, written, and tested. If you leave out the design and testing part it will suck. Lots of books written by people smarter than me will back this up. If they say they can bring in somebody else who can write the code right without a design/test phase, they're lying to them.

Despite tough times, things still need to be grounded in reality. They need to get over it and do the right thing, or can the project. The customers aren't going to care about the site reflecting bad on YOU, it'll reflect bad on the COMPANY.

If you do it, do it properly...

[arb]

...or at the very least, know which are the right corners to cut. No matter how tight the deadline, you have to do some design work. Before you agree to take this job on, sit down with the client and explain to them the (very real) risks of not doing any design or testing. Make sure they are very clear on this. Then, if the client still insists on such a tight schedule, suggest a staged deployment.

What functionality is absolutely vital to the project? What can be delayed until a second release? Do not accept the client's initial response that all the functionality is of equal importance. No matter what the project is, there is surely some features that can be delayed slightly. This will open up some breathing room in the schedule.

Once again, make sure the client knows exactly how much of the project you will be delivering at each stage, and get them to sign a document outlining the deliverables for each stage. If you don't get the client to sign off, you could be screwed over down the track.

If the client is still insistent on tight deadlines and minimal or no testing and you are crazy enough to take this on, make sure you get them to sign a document stating that the decision to do minimal testing is theirs and that they are aware of the massive risks they are taking. Do not start this type of project without making it perfectly clear that it could go to hell in a handbasket if the system is released to production without adequate testing.

I was in the situation where we had to design, build and implement a system in a very short time frame. (Y2K project, started in Nov 1999!) The client was made aware of the risks, and my supervisor almost came to blows with him over the issue of testing. My supervisor was insisting on putting testing into the project plan. (Okay, his idea of testing was pretty scary - run the app and punch in some dummy data. No real methodology behind it, but at least it was something...) The client freaked when he saw that the project would take 3 months, thus pushing the release date to Feb 2000 - obviously no good. The client then made the decision to do no testing (apart from developer's bench testing) and he wrote a memo to that effect. as it turned out, there was one nasty bug that crept into the system, but the client was happy to wear the cost of fixing it and out butts were covered. He absolutely needed the app in place by midnight on Dec 31 1999, so he was willing to accept a potentially buggy product.

Take the time to document the requirements. Take the time to design the system. If the client wants to accept the risks of reduced testing, fine, but make them sign something to that effect (and then do even more unit testing as you are coding than you normally would) to CYA.

If in any doubt, don't take the job.

Re:Several options

[Twylite]

This is the best comment I've seen so far. While turning down the customer, "making them understand" the need for design, or "pick to of the usual" are nice in theory, it comes down to earning an income, and sometimes you have to compromise.

Having been in similar situations for various reasons, I can offer some pointers.

• First, realise that design, even a little bit of it, improves your speed of delivery. If this is not the case, you're either a genius or don't have sufficient design skills. Design allows you to forge ahead with development without doing unnecessary work, or rework because of mistakes. It also allows you to reduce testing if you have to.
• Gather some requirements. This may sound obvious, but it is often neglected when time is tight. You don't need a detailed requirements engineering process -- a page of important functions or descriptions of how the user should experience the software is enough.
• Exercise the requirements a little: role-play through a simulated interaction with the user. Did you remember access control and error handling when the luser is being stupid?
• Use CRC cards to design and plan your project simultaneously.
  Start by identifying the significant components in your system, and write each one on a card. In conjunction with exercising the requirements, flesh out each card with the component's responsibilities, the data is has, the data is needs, and make a note of which other components it interacts with.
  You now have a collection of components to be developed, along with a description of each one. If any components are particularly large/complex it is best to split them into logically cohesive sub-components if possible (for the purposes of planning, even if they will be implemented as one component).
  Work to a project plan by going over each card and estimating the amount of time it will take to develop the component.
• Flesh out the design before implementation. No, really. Define the APIs to your components, and try your hardest to avoid changing them. If necessary add additional API methods, but try not to change the existing ones (this prevents rework). At worst, change the implementation of an existing method to call a new, improved method.
• Now comes the trick of fitting the development into the timeframe. The first course of action is to go over the CRC cards again and cross out any non-essential functionality. Your priority is to delivery a functional system conforming to the minimum requirements.
  As suggested in the parent comment, try to break delivery into phases. Even if the customer does not agree to a phased delivery, plan for it anyway! If you're going to overrun your schedule, at least have something ready on time - it is a strong negotiating tool.
• Don't underestimate the usefulness of hiring a few extra hands. If you're expecting trouble getting payment out of the customer for late delivery, and you really can't afford to drop the contract altogether, consider getting an extra developer to assist you. You could offer a salary, contract, or profit sharing, and if you've used the methods I outlined above the plan the project, its easy to farm out components to developers.
• Reduce your testing burden by getting it right first time. I know this is not as easy as it sounds, especially with web development, but using techniques like Design By Contract (or at the very least asserts with documented parameter ranges) you can avoid a LOT of common programming errors.

By doing a bit of design and planning, and being careful to use bug-avoidance techniques during implementation, you can significantly reduce your development lifecycle in order to meet a tight deadline.

Tell them...

[FreeMath]

That it is not possible to deliver the requested product in the timeframe given, while maintaining a minimum level of quality.

Do it right now or re-do it later.

XP and the onsite customer

[PinglePongle]

A previous poster has already mentioned XP - personally, I think the idea of gtetting your customer to do acceptance tests is pretty powerful in this case.

If you have someone from your customer working alongside you, helping you make prioritisation decisions, seeing the progress you're making day after day, you stand a far better chance of having the schedule discussion in a fruitful way.

Most companies have been bitterly disappointed by development projects, and web projects seem to be particularly contentious. Most business folk aren't stupid - but they have been told so much bullsh*t by technical types that they are unlikely to believe you when you say "Trust me, I'm a professional, I alone have the magic mojo to know the future". They need to see first hand that you are someone who delivers (regular small deliveries are far better than a big release after months of frantic coding), who understands their business (user stories and the planning game establish your credibility) and who delivers quality solutions (unit testing and acceptance testing).

It sounds like your prospect has been burnt before - how did they end up with a front end but no back end ? - so the best thing you can do is establish credibility not through making statements about what is and is not possible, but by explaining your doubts and saying "I'm gonna take this job, on these conditions : 1. we look at the deal in a week, and both parties can walk away if we're not happy. 2, someone from your business comes to work with me as an acceptance tester and business guru. They tell me what is and is not important, and tell me when it's good enough". You should be able to make decent progress in a week (if your project allows, 2 weeks would be better...), and at the end your onsite customer will understand the realities of the situation. You can then look at the schedule again using "yesterday's weather" (the easiest way of estimating how quickly you're going to get through your work is to look at progress to date) as the measure of likely success. If you have worked hard, but completed too little of the project to be likely to finish on time, you have a leg to stand on.

The XP principle of building only what you need to get today's tasks done is esp. going to help you out - one problem of database design is that it's very easy to get tied up in beautifully elegant schema designs which almost, but not quite, work.

2 final points : invest in a bug tracker, even if it's a spreadsheet or card index. By using bugzilla or something similar, you can allow your customer to contribute bugs and see the bug list - and you won't forget to fix a little shortcut later.
You also want to make sure you're going to get paid ideally in advance. When development projects go wrong (and let's face it, this one doesn't look too promising regardless of the collected wisdom of /.), suppliers usually end up not getting paid. You may not be able to afford to turn down the work, but can you afford to work without getting paid ?

Re:People underestimate the need for leadership.

[Anonymous Coward]

It regularly happens that customers do something self-destructive or ignorant.

In my experience it also sometimes happens that customers are intentionally self-destructive or ignorant, for various internal political reasons.

It's a mistake to assume that the project's success is the goal of the customer. Quite frequently, espeically when deadlines are very short, consultants are brought in so that they can find someone to hang the blame on.

And from what the guy has said, this has all the makings of such a project. Some manager probably got this '75% complete' project dumped in their lap and was ordered to finish it. So, he spends lots of money on well regarded consultants as political cover.

Furthermore, while 'leadership' is important, it's a very fundemental mistake to think that you can be an internal political player. If they are set on failing this project, you aren't going to do much to change that.

If I were this guy, I'd be looking at the following:

+ Make sure that this is profitible, even if you get fired. No use doing a bunch of free work if they are still going to hate you.

+ Get NDAs signed to protect your reputation.

+ Make sure the acceptance criteria is spelled out, and includes everything in your post, and do everything possible to ensure that you get paid and not sued.

+ Work your ass off and hope the political winds change directions and you get more time.

Re: This might be a good time to apply XP

[mh_cryptonomicon]

As a FYI... if you don't want to run out and buy the XP books, you can view them online at O'Reilly's Safari website.