Slashdot Mirror
Dealing with Difficult Development?
"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?"
If you've hacked something together you may well get more money to spruce it up afterwards; a working site may be upgradeable to a better schema or whatever, although it will cost. It sounds like the company doesn't care so much what it costs, so that might work.
But if you can't see any plausible way to do it right now, you should walk.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"But as the parent said it might take too long to familiarize youself with the tool for it to be effective.
If there's literally zero time for anything but unit testing -- if the customer is saying, "you must deliver perfect code in this agressive timeframe" -- then the project is doomed. (Can you put it to them that way?) Find some way to accept the job without being seen as responsible for its inevitable failure.
You can't do "big design up front." I'm sure there's no way you'll get detailed immutable requirements. You're going to need lots of unit tests and lots of automated tests. (If you're description of the other trends is accurate, it's a given the customer will change their minds during this project. You already know you'll make mistakes and have to recover from them. That means you're going to make changes to working code, and will need to ensure your changes didn't break anything.) It's also a small project.
Extreme Programming isn't a good choice for all projects, but it sounds as if it might be for this project. If you look at the twelve practices of XP, most of them seem applicable.
Some of the practices won't apply. You can't "pair program" if you're working by yourself. I don't know how close you'll be to "on-site customer." The call for acceptance testing is one you'll need to deal with no matter what process you follow. (This is not the right setting to discuss 40 hour work weeks, so let's not concentrate on that one.)
On the other hand: Small releases and the planning game will get the most important work done first (i.e., when the schedule slips, it'll be less catastrophic than it might otherwise have been). Automated unit tests can speed development, and they are (XPers hardly ever say this) useful design artifacts in their own right.
Having said that, let me say this. Some of these practices take some time and experience to master. (Personally, I can't yet say I really "get" XP-style automated unit tests. I often run into cases where I can't find "the next test" that leads me in the right direction.) You won't be able to pick up Extreme Programming Explained (Amazon.com, BN.com) today and be a good Extreme Programmer tomorrow. Using a new process, even a good one, is like using a new programming language (even a good one): you'll be slower when you're climbing the learning curve. You may not be able to afford that on this project.
Finally, if you turn the job down, do so in a way that doesn't involve burning any bridges. Perhaps say you don't think anyone could succeed under the specified terms. You may yet be called in later if (when?) the first developer hired can't make it happen.
Good luck!
Stupid job ads, weird spam, occasional insight at
Several years ago when I found myself on an understaffed tightly (insanely) scheduled project I, and several others on the project, read _Death March: The Complete Software Developer's Guide to Surviving "Mission Impossible" Projects_ by Edward Yourdon.
/. comments. Basically to know what you are getting into and do it with eyes wide open. There are both reasons to do it (money, foot in the door, etc) and reasons to run away, but your most important time to negotiation is before you say "yes".
Summary from Yourdon's site
I see a lot of Yourdon's advice in these
The customer demands.
I explain that the simpler, better, working implementation I just showed them is really what they want.
The customer re-iterates demands.
The project manager capitulates, and I get stuck writing extensive logic in a scripting language (!) to do something completely tasteless that will only dismay the customer when the lousy repercussions of their demands hit them in the face.
"Welcome to software consulting" says the project manager.
The fact that I held true to my ethics and tried to dissuade the customer is cold comfort.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
They have the look and feel developed before they have something to look at and feel? This one is doomed, kinda like trying to build a car under the paint job that is already complete.
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.
My experience is that we only get called into the most disastrous situations. If these were well-managed companies, with cheerful, friendly, helpful, intelligent, introspective employees, they wouldn't need us in the first place.
Free lancers are asked to solve the problems caused by lazy, inept, and cruel managers, and are forced to interact with lazy, inept, rude, and hateful employees. That's just the way it is.
Rise above it: Be kind, considerate, helpful, industrious, and talented, and, in the long run, people will remember you for it. Or at least that's what I'm hoping.
PS: Above all else, KEEP YOUR MOUTH SHUT! Nothing foments a torch & pitchfork peasants' rebellion quite like publicizing the obvious blunders they've made in their work.