Dealing with Difficult Development? 61
"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?"
Is this a trick question? (Score:5, Insightful)
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.
golden consulting rule: Learn when to "No Bid" (Score:5, Informative)
Re:golden consulting rule: Learn when to "No Bid" (Score:1)
Give your customer what they want, not what they think they want.
This is the whole point of consultancy, to aid the customer in finding the solution that best fits there needs, which is quite frequently not fully what they wanted to start with.
I'm currently working on a nightmare project, were giving the customer what they asked for, even if there are contradictions. I don't think the multinational I work for's ever thought of consultancy.
If you can't do it properly... (Score:4, Insightful)
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... (Score:1, Insightful)
Have you tried telling them this? (Score:5, Informative)
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.
The Contractor's Creed (Score:3, Funny)
Ours is not to question why, ours is but to bill them high.
Re:The Contractor's Creed (Score:1)
Several options (Score:5, Insightful)
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."
Re:Several options (Score:5, Informative)
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.
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.
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.
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.
And above all (Score:2)
And as every developer knows it's the polishing off that turns a almost finished project into a finished project that takes the time.
Either backen first (so that the client doesn't get there hopes up) or make sure you explain that the polishing off takes time.
Re:And above all (Score:2)
The original poster said the "look-and-feel" (the easy part) was already done.
In other words, he's fucked, 'cus someone already pulled this stunt.
- If there's a logic error embedded in the sequence of events in the "look-and-feel" navigation, he has to redo it
- If there's sections that have to be redesigned, he has to redo it
- He has to explain why the plumbing (which isn't visible) takes SO much more time than the visible stuff
My advice - tell them you'll take a certain amount of $$$ to evaluate what can be done. Look for a few mistakes - you'll find them - and blame whoever did the easy shit for the longer time you'll need to finish.Someone else's sig says it all - software is like a child - make one mistake, support it for life. This fuckup has the potential to be a long-term gig, esp. since you get to blame the people who did the easy stuff (you KNOW they couldn't do the back end, and whoever hired them knows that too. Remember this. You're already better, in the clients' eyes, than the people who did the initial design).
Good luck.
Re:Several options (Score:4, Interesting)
But as the parent said it might take too long to familiarize youself with the tool for it to be effective.
hmmm (Score:2, Funny)
- Ask
/.
- ???
- Profit!
but seriously, take the $$$ and run.time? (Score:5, Funny)
rigo
Log everything. (Score:2, Insightful)
Do that, and keep praying.
me? (Score:2, Insightful)
Maybe walk away, maybe not (Score:3, Interesting)
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.
Use prebuilt components (Score:2, Insightful)
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 [postnuke.com]
if you are aiming for a LAMP solution.Please don't work for free. (Score:5, Insightful)
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.
If you do it, do it properly... (Score:5, Informative)
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:If you do it, do it properly... (Score:1)
let me reword this for you... he absolutely needed to be able to TELL SOMEONE THAT HE HAD the app in place by midnight on Dec 31 1999.
He needed it to be the real app, then he would have needed to know that it was working too.
Re:If you do it, do it properly... (Score:2)
No. He needed the app in place. It needed to run at midnight - which it did, although a couple of issues surfaced later. The client didn't need to be able to tell someone, he needed to be able to demonstrate it working.
Re:If you do it, do it properly... (Score:1)
Then he was lucky it worked well enough. I don't say you were lucky, you probably had to work and had to worry like hell. He was taking a risk that it would not work, and often, that gamble doesn't pay off.
I probably should not have shot from the hip... I don't know the project, I surmise that some Y2K flaw was understood and had to be addressed. So the bugs were bound to be less disruptive than no solution at all.
No doubt my comment was 3/4 projection... I have seen many times decisions made because someone has to tell someone something happened. If the product is called X, and is installed on Y, then some guy feels fine saying, "hey, we have X installed on Y, we have a few things to work out".
Re:If you do it, do it properly... (Score:2)
We worked our butts off and got it done in time. A few bug fixes in the first week and the thing has been working fine since with nary a hitch. If we hadn't got the client's signature absolving us of any responsibility for serious bugs due to lack of testing/design though, I wouldn;t have touched the job at all.
What to do (Score:3, Insightful)
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..
Tell them... (Score:3, Informative)
Do it right now or re-do it later.
Heres what (Score:1)
(2) Your reputation is more important, and this is especially true during times of recession.
(3) Do your best, keep awake more hours on it. Drink more Coffee.
(4) Profit!
People underestimate the need for leadership. (Score:4, Insightful)
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.
Re:People underestimate the need for leadership. (Score:2, Informative)
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.
IMPORTANT COROLLARY - (Score:2, Interesting)
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.
Make the missed deadlines their fault (Score:2)
um...I think.... (Score:2)
"Oh no! You din'non tell the Cap'n how long it will rrreally take??!!"
This might be a good time to apply XP (Score:3, Interesting)
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 [xprogramming.com], 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 [amazon.com], BN.com [barnesandnoble.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!
Re: This might be a good time to apply XP (Score:2, Informative)
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 [oreilly.com].
Re:This might be a good time to apply XP (Score:2)
Then implement the features in order of priority. If you think that feature X requires that feature Y gets written first, try to think of a way around it. Most (not all) dependencies are imagined.
If this is like projects I've been on, there are a lot of things that can be shipped later. And since it's a web project, it's very easy to roll out a new version of the project whenever you want.
Also, you might want to leave the hardest-to-change things for last, like a relational database. Can you go for a while just serializing your data, or using a flat file or something like Prevayler [prevayler.com]? If so, you won't have to spend so much time changing the schema. And you might find (gasp!) that you didn't need a database in the first place.
Cut the scope (Score:3, Insightful)
Tell 'em it will be finished when it's ready (Score:2)
If the plan is for a long lived site then the first few teething troubles shouldn;t present too much of a problem.
Make sure you are contracted for the months *AFTER* the deadline too [or don't fix the inevitabel bugs]
What you will usually find is that once you have finished it, no-one wants it like that any more anyway.
Keep your head, don't panic. Tell them -no one dies when a website is down. They aren't losing money because if it doesn't work it doesn't work.
BE UP FRONT. Don't tell 'em "Yeah it's going great" when it isn't and don't say "it will never be finished".
good luck.
yup, just gotta have 'em (Score:2)
_Death March_ by Yourdon (Score:2, Interesting)
Summary from Yourdon's site [yourdon.com]
I see a lot of Yourdon's advice in these
XP and the onsite customer (Score:3, Informative)
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
Hire more people? (Score:2)
(1) Simplicity, (2) Simplicity, (3) Release often (Score:2)
I highly recommend you read about either Extreme Programming [extremeprogramming.org] or Agile Software [agilealliance.org]. Both of these schools of thought have come to the realization that you never want a big design up front. Keep your design as absolutely simple, dumb, and difficult to screw up as possible. Yes, those all go together. It's the ONLY way to design stable, quality software. No object-database wrapping engines, no XML Soap Servers, massive new framework. If you can possibly get by with some PHP scripts accessing a MySQL database in a weeks worth of time to get 50% the functionality, do it!
Let me say this again: If there is any way to make it simpler, do it. Stop whining, just make it simple.
Refactor your code later, only when needed. By keeping your design simple, you'll save time and those defects you were worring about will be minimal. Testing should be done either through unit tests or simple procedures.
And here's the most important part: give them WEEKLY releases. Never "postpone" a release. This lets them know where you are at in the project, and there will be no surprised or misleading estimates or anything. Never give estimates further out than a week, and always break down tasts into smaller tasks that will take less than a week.
And stop your bitching about not having enough time for a "top bottom" design. Top bottom designs are categorical failures.
Living in a watered-down version of this now (Score:3, Interesting)
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.
Run fast, run far (Score:2, Interesting)
SCRUM? (Score:1)
In addition to the comments on using XP to solve all your problems, you may want to consider searching the internet for:
How about, get some extra help? (Score:2)
And that means you need to get extra programmers working with you. Do a little sub-contracting if necessary.
That could easily speed up the process. Especially if you write modular code.
--Zuchini
Sig sigga.. who stole the keys to ma beema!
Rescope the project and restrict requirements (Score:1)
While your clients may have a list of features the database/web front end needs to have, they will have some key requirements that are more important that anything else. If they say all their requirements are manditory, they're lying - evaluate their business, their market position and decide for them which features their business needs most.
Then offer to deliver only these features within the time required - and because you've left enough time to fully test the key features, you should come out with your professional credibility intact.
You may need some assistance in negotiation skills, to better explain the development position to the client - try
Rosette, A.S., Kopelman, S. & Thompson, L.L. (2000). High-performance contract negotiation skills. Product Management Today, 11 (7), 38-41.
Best of luck, [K]
triage (Score:2)
Looks like the project is in triage before it has really begun. Step one: identify the reletively free standing sub projects. Likely, one or two parts will be keys that the rest depend on. Try to determine what would be 'substantial functionality' and try to convince them that that would be phase one and that phase two will have to be late. See if you can bring in help to work on some of the sub projects. While the man month truly is mythical, if the pieces are independant enough, the communication overhead (between programmers that is) shouldn't be too bad.
Ultimately, your decision will be based on how they respond to the bad news. The last thing you need is to be holding the bag if the project fails. Especially if that means they don't want to pay you or it reflects on your reputation.
IFF they are willing to accept that only a portion of the project can be completed by their deadline (and sign off on that plan), it could be a good thing. If not, it can only be a disaster.
hire more people (Score:2, Funny)
Well who sets the parameters (Score:1)
I say these are real difficulties because they are typically the areas where many software developers throw up their hands and declare their utter distaste for those parts of the work. However from a business perpsective these are the key parameters.
The average customer of software systems has about as much interest in language wars, the utility of schemas over DTDs, VB vs EJBs, XP and OOP as a car buyer has in the the underlying crystalline structure of the steel in his car.
Ergo, If you want to educate your customer as to the challenges presented by his/her schedule and functional demands couch it in terms that they have some hope of grasping. What is the purpose of the site, what is the impact to first time viewers of untested components, how will it be supported over the long term, what is the expected lifetime, what are the budgetary constraints, what are the resource constraints.