Complete PHP development environment

[Luke Redpath]

Originally Posted by sweatje

I would see that as the crux of the negotiation, however, the trust part is key. Perhaps it would work better for you on a second project with an existing client who already has some trust in you and confidence in your delivery.

HTH

Well, again, to quote our financial director "no company in their right mind would ever agree to an open-ended contract". Our FD is very experienced and works for the government. You can say its about trust, but companies want total assurance that things wont go wrong or that it wont cost them more than they have been told. They aren't going to commit to a job purely based on "trust" - they want things want things in writing. Would you really sign a contract based on "trust" that it wont cost more than you've been quoted? Clients will say, why should they take the risk that we've estimated incorrectly?

[sweatje]

Originally Posted by Luke Redpath

Clients will say, why should they take the risk that we've estimated incorrectly?

Because there is no estimate to go wrong. The trust is that you are at least as compentant as any other practitioner they are going to hire, and that each iteration you are working together with them to identify the top priority goals. Each iteration you are then working on these goals and delivering them. You continue until they declare the project done to their satisfaction, and their risk is limited becuase you are delivering working iterations (abet with much smaller scope) under much shorter timeframes.

I agree it is a different mentality to work under, and if as you quoted above, the management at your firm does not believe in the process, I don't see how your entire organization can project the coherant face to the client requried to get them to believe the same. Perhaps you have to start with getting alignment internally prior to trying to work with the end clients on this issue.

[Luke Redpath]

Originally Posted by sweatje

Because there is no estimate to go wrong. The trust is that you are at least as compentant as any other practitioner they are going to hire, and that each iteration you are working together with them to identify the top priority goals. Each iteration you are then working on these goals and delivering them. You continue until they declare the project done to their satisfaction, and their risk is limited becuase you are delivering working iterations (abet with much smaller scope) under much shorter timeframes.

This is still something I do not understand. How on earth can a company agree to start a project with no idea of what its going to cost? Its not about trust, its about business pure and simple. How do you budget for something when you don't know the cost?

I am genuinely interested in hearing how people have managed to get their clients to get on board with this. I'm just trying to play devils advocate and think of the sort of questions that any normal client would ask. How do you answer these questions. I honestly don't feel that "you have to trust us" is a good answer. I wouldn't hire somebody to do that. If I got a plumber round to fix my drains and I asked how much it will cost, and he said "well I charge x per hour and it will be done when its done." Its all very well being able to pull out after an iteration, but then you've ended paying for an incomplete product/job.

Then you have the issue where there are several companies competing for a contract. Now, I agree that a fixed-price contract is likely to include a premium to cover risk (but this is likely to be transparent to the client), however if one company says "we can do this for you and it will cost you £10k" and another says "we charge £400 a day and it will be done when its done", then the company is surely going to go for the company offering a fixed cost. I know I would.

[kgun]

Originally Posted by sweatje

working iterations

Very important.

Start by writing tests. May be new to some people. It will seem unproductive in the beginning.

XP in practice.

1. User story card.
2. Engineering Task Card.
3. Class (Responsible, Collaboration).
4. Splitting Business and Technical Responsibility. Roles of people.

[sweatje]

Some things that might provide inspirational reading on the subject of agile programming and contract negotiations:
http://www.martinfowler.com/articles...formation.html
http://www.martinfowler.com/bliki/ScopeLimbering.html
http://www.martinfowler.com/bliki/RigorousAgile.html
http://www.martinfowler.com/bliki/IsAgileForAll.html
http://www.martinfowler.com/bliki/FixedScopeMirage.html

[Luke Redpath]

Originally Posted by kgun

Very important.

Start by writing tests. May be new to some people. It will seem unproductive in the beginning.

XP in practice.

1. User story card.
2. Engineering Task Card.
3. Class (Responsible, Collaboration).
4. Splitting Business and Technical Responsibility. Roles of people.

Whats that got to do with anything? Sorry, I know how XP works, I'm questioning how it works with clients who want a fixed price, and why clients would go for anything other than a fixed price contract.

[kgun]

Originally Posted by Luke Redpath

This is still something I do not understand. How on earth can a company agree to start a project with no idea of what its going to cost? Its not about trust, its about business pure and simple. How do you budget for something when you don't know the cost?

How on earth can a company agree to start a project with no idea of what its going to cost?

[kgun]

Originally Posted by Luke Redpath

Whats that got to do with anything? Sorry, I know how XP works, I'm questioning how it works with clients who want a fixed price, and why clients would go for anything other than a fixed price contract.

I know how XP works.

Do you?

[Luke Redpath]

Originally Posted by kgun

I know how XP works.

Do you?

Yes, I know the ins and outs, it just seems that your posts are complete irrelevant to what I'm saying.

[Luke Redpath]

Originally Posted by kgun

How on earth can a company agree to start a project with no idea of what its going to cost?

What an outstanding contribution, thanks.

And Jason, thanks for those the links, the second one was especially interesting.

[kgun]

no idea of what its going to cost?

[lastcraft]

Hi...

OK, here are two things that I have found absolutely true so far from personal experience...
1) A new client will agree to nothing except a fixed price contract.
2) There is no such thing as a fixed price contract.

What actually happens is a client asks for bids. The companies bid low to get the deal, but they know rule 2, so they add on a penalty cost for changes. The client sees rule 2 and realises that they had better get the requirements correct up front, because of the cost of later additions. Thus they put in everything except the kitchen sink, which in turn raises the estimate and reduces to zero the chance that the requirements are correct. The supplier illadvisedly accepts this much larger deal, because now the project has become so large they cannot estimate it accurately anymore.

Work begins, but runs late because it's such a huge project.

Faced with massive lost opportunity cost within the business domain, the client goes back and renegotiates some essential work that can be done fast. They get stung in the renegotiations, of course, but by now they are desperate as they have had nothing to show.

Once the minimum functionality is done, either the business doesn't take off in which case it withers into recriminations, or it does take off and no one complains, but the extra work just hangs around unfinished.

Other failure modes include the project becoming irrelevant by the time it's delivered, the extra functionality never being used, or simply that such a large amount of new technical infrastructure is too much to take advantage of when it does arrive, so they carry on using the old system.

I wish I was writing a caricature, but sadly I'm not. I've *never* seen a fixed price contract work unless it was less than two months work. Not as the supplier and not as a client.

How to break the deadlock? Split the project into milestones, say four of them for a six month job. Only agree to be contractually obliged for the first milestone. Explain that there will be no change penalties between milestones when they try to stack everything into the first one. The milestone technique is not ideal, but is a step in the right direction. You can bet you won't be doing four anyway.

I always found my favourite clients were the ones who had already been burned by someone else, the clients hated most by other vendors. You can actually charge a premium if you are known for delivering on what you say. Businesses usually like taking risks even less than they like spending money. They just don't see the fixed price contract as high risk unless they are at least a little enlightened.

These days I mostly work in-house .

yours, Marcus

[arborint]

Originally Posted by Luke Redpath

Whats that got to do with anything? Sorry, I know how XP works, I'm questioning how it works with clients who want a fixed price, and why clients would go for anything other than a fixed price contract.

Marcus say it much more artfully than I could. The fact that most all facets of software development are counter-intuitive before you see the light is the biggest problem. And you end up doing fixed price anyway. Sometimes it is only after going through "the usual" as Marcus describes does the clent start to see the light -- ah well. The hardest thing about Agile for people to accept is that Agile merely acknowledges the reality of software development and attempts to fine-tune that reality. Old school methodologies tried to impose an impossible reality on us.

I usually start client education in the very first meeting by tying Agile methods with Cost Controls. Most business people know how projects go out of control -- they just don't know how software projects go out of control (yet).

[dagfinn]

For anyone who wants advice on XP, I would recommend the Yahoo extremprogramming group. It has real XP experts like Ron Jeffries.

[lastcraft]

Hi...

I went to a talk today by Tim Lister (London XPDay 2005) on risk management. He was talking about contracts and reducing risk, with iterations and prototypes. In particular the fixed price contract being an embrace of death. He was describing a relative who was having a swimming pool built. I'll try to capture the New York tone/style, but I don't think I'll do it justice...

"...so they have way too much money. You can tell that they have too much money, because they want a swimming pool.

They plan out the pool in meticulous detail. They plot the outline of the pool with little flags, the outline of the patio as well. They make drawings and copy them, and then invite contractors around to bid. The contractors visit, ask a few questions, are handed a ring binder with all this stuff and told to come back in ten to fourteen days with an estimate.

The third contractor comes around and he's really old. I mean they cannot believe it, he must be seventy eight or something. Turns out he's been building swimming pools for years. They give him the ring binder and he reads some of it and asks a few questions. They ask him to go away and bid.

He says "no".

They say "what"? He says he cannot bid.

"Why not?"

"I can't bid unless you can tell me what's under the ground. If it's just topsoil I can use a digger and dig out the swimming pool in six hours or so."

He points up at the mountains and says "if it's just eight inches of topsoil, and underneath is solid rock, then I haveto blast with dynamite. This needs permission, you have to warn the neighbours...", and so on and so on. "It pushes the cost right up."

"What I can do, if you have a digger, is for $200 I can dig some test holes. I'll make you a deal. If you select me as the contractor afterwoods, I'll refund the $200 as part of the deal."

This all makes perfect sense. All the couple could do is look at each other and ask "what the hell were the other contractors doing when they just walked off to take an estimate?"

Guess who got the job?"

Lister is such a great speaker.

yours, Marcus

[kgun]

risk management. He was talking about contracts and reducing risk, with iterations and prototypes. In particular the fixed price contract being an embrace of death.

reducing risk, with iterations and prototypes. = XP

[demosfen]

Originally Posted by madwax

(and here we have the single most important reason why I rarely re-install my computer - because it takes days to configure everything ).

I think your setup lacks Acronis

[melancholic]

What I find sometimes is that when applying the Penalties for changes, the client looks at you as if you were a scheister or something - like you're trying to rip them off.

uhk :: shudder :: I usually make the decision to drop them after the project there and then when they look at me funny.

I can't be bothered explaining why I'm charging extra for work that is outside the scope of the initial quotation.


'gards,

'cholic

[Dr Livingston]

The trust is that you are at least as compentant as any other practitioner they are going to hire, and that each iteration you are working together with them to identify the top priority goals.

For a while now, I no longer have a contract - in writing - with a number of clients, purely because I've done work for them for a while now, and there is trust between myself, and the clients.

I get a request to script something, and I give a near approx. to how much it'll cost to develop. Since I've developed the bulk of the work for them previously, this is a bonus for me since I know my way around my own scripts, etc and that can save a bit of time...

The clients understand that, and I'm sure they appreciate that fact as well. I think that that is an important point, as if someone else had to come along and start, then costs are obviously going to increase.

When you start to develop with something done by someone else, it is difficult to predict, with confidence anyways, the development time scale and cost. Regardless of that though, one way to build trust is to sustain the extra cost yourself, if you go over the quote...

In the event, the project may well run over, but it's at no cost to your client - who you want to retain I would think? You don't want to hamper your profit margin simply by throwing the client out because of a misunderstanding.

With that kind of attitude, it's not good for business - you need to take responsibility in so far, yourself as well

[littlejim84]

Does anyone recommend using Zend Studio (standard version - i ain't got much money to spend)? I think it's about $99. I'm from the UK so that works out about half that in pounds! (...well, something like that.)

I've heard good things about Zend Studio, but another option I was looking at was Eclipse (with the PHP plug-in)... It's free! But is it any good either? ...I've got a dial up connection, so I wondered what others thought about these IDEs for PHP? I've had good advice from you lot on this forum, so I trust your judgements and views. (...on the whole! )

Recommend any other IDEs to use?

I'm using a G4 Mac Powerbook, but want an IDE that works across Windows, Mac or Linux... Just incase I have to switch platforms, for any reason.

Thanks for the help. Great thread so far!
James

[akrabat]

I use and like Zend Studio. I've also played with phpEclipse and Trustudio and they are definitely usable, but where on earth did the default keymap come from for Eclipse?!

No idea what performance of either is like on a Mac though.