Fog Creek Software
Discussion Board




contract penalties for below-par performance

Following on from the excellent job-ad linked elsewhere. How about this for a contract clause.

"You are hired as a professional. We will treat you as such for as long as you maintain that standard. If you fall below the standard of a professional we will provide remedial training and mentoring to assist you in maintaining your professional standard. Such mentoring and assistance will be charged to you at a rate determined by the following formula
(your equivalent hourly rate) - (the current rate for a three-star MacDonalds employee * 1.1)"

WoodenTongue
Monday, August 16, 2004

And how about the corollary...

When I present an Invoice to your esteemed Accounts department with all of the necessary paperwork you have deemed necessary and you fail to pay on that Invoice by the prescribed date the following penalties will apply.

1.  2% interest will be charged per thirty days.
2.  The rate for all work will be increased by 5%.
3.  No further work will be undertaken without a 10% deposit.

Simon Lucy
Monday, August 16, 2004

The problem with these clauses is the ambiguous nature of the requirement. 

How do you measure what a "professional" is?  Let's say it is producing good quality work on time and on budget.  OK, who defines 'good quality' for the work? 

If the user doesn't like the GUI, does that mean it is low-quality?  Or it is high-quality (ie it 'works', doesn't crash, does what it is designed to do) BUT it just doesn't match what the user 'had in his head'?  In that case, who pays? 

Is it the developer, who did the best he could do with what he was given?  Or is it the user, who wants their GUI 'fixed', 'modified' or the worst -- 'done right the first time'.

For me, these are the central issues with software development right now.  As long as we do not have an un-ambiguous way to describe GUI's, requirements, what the software must do, we are going to have to incrementally develop software. 

That means specify some, develop some, deliver some, then fix it so it matches what the user wants (which is usually different from what they specified).  AND do this in such a way that it's not the developer who pays all the time.

It may not be POSSIBLE to have an unambiguous way to describe these things, but the current approaches certainly have not removed the ambiguity yet.

AllanL5
Monday, August 16, 2004

Sure there's an un-ambiguous way: spec the shit out of it.

By which I mean, create mockups of EVERY screen, attach a few paragraphs describing the expected behavior of EACH control, the calculations that are done behind the scenes, transactions in the database, etc, ad nauseum.

Yes, this will take a LONG time, but I'll put money that in most cases it will take a good deal less time than incrementally developing the software through 7 or 8 iterations to get it *mostly* right, which STILL may be something the client only settles for, because really he wanted that first screen to be laid out much differently, but such change doesn't fit into the architecture you just spent 9 months incrementally creating.

I think both the OP and the post following are excellently worded and ought be taken seriously as good examples of the sort of things that should appear in any development contract.

muppet
Monday, August 16, 2004

The problems with extensive specifications for contracted software is that:

1) developing an extensive, detailed spec is generally not willingly paid for by the client.
2) A "full" specification can be so deep that it costs almost as much as simply performing the work.

Most clients will either want to bypass an extensive specification (on a fixed price contract) or will expect T&M development to be "organic". In the former case the client expects to shift all risk onto the contractor. In the latter case the client expects brilliance to arise on an ongoing basis.

This disconnect is why "XP" techniques have been embraced.

I've heard a quotation as follows: "the software IS the specification". I think this is true. IE: behind a well specified user interface you can still have crisp, or buggy behavior. Just how deep do you go with a spec? Rhetorical question. I've never heard a good, concise answer.

I don't think this type of work is amenable to strong, bulletproof specification or contract language. You either trust the consultant or you don't.

Bored Bystander
Monday, August 16, 2004

Having only worked on two independant projects, I guess that I'm extremely green.  However, I don't think I'd accept a project whose sponsor was unwilling to support (financially and theoretically) a comprehensive specification of at the very least, the UI and it's expected behavior.  That's all the client really cares about anyway, so long as the math is right.

muppet
Monday, August 16, 2004

This is the grey area. If the client is intelligent and wants to work with you, it's possible to create a working understanding of the functionality of software without creating a large documentation burden.

The problem I've often had is that the client doesn't want to exert any effort to review the consultant's understanding of the problem - until delivery.

Bored Bystander
Monday, August 16, 2004

Developing a "deep" specification is important, but it should only be undertaken as paid-for work. It DOES take a lot of time and effort. Also, if you simply deliver it for free, there's nothing stopping the client from taking your free labor and shopping it around. (It's happened to me.)

Some of the larger consulting shops will do the spec up front for free, but before it does so, the company has to make a significant up-front invenstment providing access to exectives for a week or more of off site meetings, etc. Also, the effort is ONLY undertaken for large project (> 3M) in order to justify the business aquisition costs.

The usual formula for pricing jobs is based on risks. If the vendor assumes the entire risk (fixed price, no specs up front) then the vender charges a premium for accepting the risk. (Note: Any vendor who does this is nuts.)

On the flip side, if the client hires the vendor on pure T&M, then the client assumes all the risk.

I prefer a shared risk model. Client pays a reduced fee to have the specs developed up front (fixed price, significant client comitment of resource, etc.). Then, a subsequent negotiation to identify fixed price and T&M deliverables, again based on risks.

Real world example: Billing system migration. Customization and implementation was all fixed price, except for the high risk data migration phase. That was T&M.

Tom

Tom
Monday, August 16, 2004

Definitely the way to go. I'm going to try it out. For my lawyer, no more paying if we lose a case. Unprofessional. For my doctor, I pay for top health. If any of my family get colds or scrapes, I will be deducting fees for non-professional performance.

For my managers, any fall in share prices, any bad press, any unwanted departures of good staff - all will result in witholding of pay until I get professional performance.

Which all goes to show what turkeys some programmers are to even entertain reduced fees.

Management material
Monday, August 16, 2004

T&M..?

muppet
Monday, August 16, 2004

Clearly "Professional" will have to be defined as a series of metrics.  Even if it's a leaky metric, it's better than none.

muppet
Monday, August 16, 2004

T&M == "time and materials". A basic shorthand in the contracting world.

It means billing for hours instead of results.

Bored Bystander
Monday, August 16, 2004

"Spec the shit out of it" --

Muppet, I'd agree with you here, except I've had experience with several major projects, and some minor projects.  It is a simple answer that does not work in practice -- much as I wish it did.

Yes, when a GUI is involved I've now gotten to the point where I take screen shots of every screen.  Since a medium complexity application (10,000 LOC web site for automating change requests and work assignments) can have more than 200 screens, each with 5 to 10 controls on it, this is a lot of paper.  It is a moderate amount of work just to design these screens  It is a larger amount of work to design the work flow that requires the existence of those screens.

It is not really possible for one human being to completely specify all 200 screens, and the controls on them, and the behavior they want, without doing the entire project.  If only it were.  The customer tends to take the point of view that they tell you the process they want implemented, and YOU (the developer) come up with the screens.

Then, when you have satisfied the guy who hired you with your screen designs, HIS BOSS now wants changes before he will approve payment.  If you are lucky, there is only one boss whose approval you need.  Typically there are three to five.  Not to mention the users who will be navigating your 200+ screens on a daily basis, and their comments.

You have hit the nail on the head, though.  This situation is caused by the difference in point of view between the people who think you CAN 'spec the shit out of it' successfully, and those who have tried very hard to do so without success.  Unfortunately, the first group tend to be customers, and think they have done their job.  The second group tend to be developers, who get criticized and condemned by the first group when the ambiguities are revealed.

AllanL5
Monday, August 16, 2004

+++The customer tends to take the point of view that they tell you the process they want implemented, and YOU (the developer) come up with the screens+++

Well, of course as a developer, your job is to take their initial business requirements and transform them into a specification, complete with mockups, etc.  This should be part of the process, you should be paid for it, and they should need to review your complete spec and sign off on it before you will start coding.  Changes they request "on the fly" should require an addendum or amendment to the spec with a new round of signatures (or just one signature for a small change) and for a very large change, a meeting.

I don't understand why so many contractors don't push back on these points.  Are they so desperate for work that they are afraid to insist upon proper conditions for the success of their project?  I would think that you might build a positive reputation for yourself, that way.

muppet
Monday, August 16, 2004

The spec (which had better have been sign-off by the stakeholder - i.e.; the guy who pays the bill) establishes the baseline for the project.

Any deviation from the spec requires a change order (signoff by the client project manager) and an additional charge. That's the way it's always been in the construction industry. Just try changing the color of a bathroom after it's been painted, never mind a major change like relocating a wall without a change order and a bill.

It's called "scope management". Nothing will kill a project faster and deader than "scope creep".

Tom
Monday, August 16, 2004

In all the years I've worked the amount of times that a client has been willing to pay properly for the specification process I can count on fewer digits than I possess.

You can get reasonable agreement, not by having a detailed specification with every form and piece of behaviour specified but with a conmprehensive set of requirements agreed and with an incremental delivery plan.

Simon Lucy
Monday, August 16, 2004

There could be some basic ground rules, some things you just don't do...

I mean, I believe your incompetence warrants others' compensation when you go so far overboard as to design someone a small scale CRM sort of app and the database has not a single primary or foreign key, nor any naming convention to make the creation/identification of such relationships intuitive.

We just had a system like this given to us by a contractor. If it were me handing someone a P.O.S. like that, I think I should be sued. I hear that gentleman is now planning to get out of the programming business though.

I've seen at least one other blunder just as big on a contractor's part in the last two years. My employer has the mixed blessing of an ample budget and scarce techno-savvy within its management. It makes things interesting....

Chance
Monday, August 16, 2004

>> It is not really possible for one human being to completely specify all 200 screens, and the controls on them, and the behavior they want, without doing the entire project.  If only it were.

Amen.

And once again: my experience with one man/small consulting shop assignments is that it's VERY difficult to get informed client buy-in on lengthy specifications. IE, they won't read them if they're over 10-20 pages. Sometimes not even if they're fairly short.

Most clients wrt smaller projects expect you to hit the bulls eye without much, if any participation from their end. They often tend to feel that they have no obligation to do anything until delivery.

Also, there is always the danger that the client considers the work done when the user interface appears done. So if you do mock ups (for instance) they may expect you to charge very little beyond that because they dont' appreciate all the work required beyond laying out screens.

Consulting is about managing expectations.

Bored Bystander
Monday, August 16, 2004

Oh and I never do mockups, prototypes (other than paper ones which are drawings not visio or screen captures) or anything else which is not part of the process.

If you spend the time prototyping, spend it developing instead.  There isn't enough oxygen left in the life I have left to breathe it to waste on doing things that don't actually do anything.

Simon Lucy
Monday, August 16, 2004

+++Oh and I never do mockups, prototypes (other than paper ones which are drawings not visio or screen captures) or anything else which is not part of the process.+++

It's not part of the process to define the stated goals of the process?  You're ready for management!!!

muppet
Monday, August 16, 2004

Ummm I've been involved with management as well as development for over twenty years.

And no, prototypes are not part of the discovery process, still less the design process, they are a waste of time and energy.

Simon Lucy
Monday, August 16, 2004

"By which I mean, create mockups of EVERY screen, attach a few paragraphs describing the expected behavior of EACH control, the calculations that are done behind the scenes, transactions in the database, etc, ad nauseum."

This is SOP in my practice, and it works out well.  The client and I go back and forth until they agree that what is on paper is EXACTLY how they want it to look/work.  If it's not in the spec, it does not exist.

I've had to educate some clients, definitely.  Sometimes it does take longer to spec it properly than it does to just write it - but if you don't spec it properly, you don't know what to write.  Better to spend more time up-front and avoid re-work, and re-work is by it's nature open-ended.


"Then, when you have satisfied the guy who hired you with your screen designs, HIS BOSS now wants changes before he will approve payment.  If you are lucky, there is only one boss whose approval you need.  Typically there are three to five.  Not to mention the users who will be navigating your 200+ screens on a daily basis, and their comments."

If you find yourself in this position, you've made an error somewhere along the line.  UNless the client was downright evasive in the kick-off phase of the project, you should have known that your contact's boss (or bosses) had feature approval, whihc means they should have been providing feedback on the spec all along, not just at the last minute.  Sometimes you have to cast your net wide in order to make the right people a part of the team.


"I don't understand why so many contractors don't push back on these points.  Are they so desperate for work that they are afraid to insist upon proper conditions for the success of their project?  I would think that you might build a positive reputation for yourself, that way."

I do push back on these points.  Clients do not want to buy line sof code - they want to buy the solution to a problem.  It is my job to ensure that my client receives that solution.  They hire me because I know how to get those results.  When clients refuse to allow me to do what they've hired me to do, the entire relationship then becomes moot.

This rarely happens, though.  I think I've lost 1 client in my entire career because they wanted to cut certain corners and I refused.  I'm all for driving unnecessary expense and inefficiencies out of a project, but there are some corners you just can't cut without a negative impact following closely behind.  Functional specs fall into this category.  Being able to tell the difference between what you can do without and what you must keep is vital to the success of a project.

It is my personal experience that a well-spec'd project costs less overall than an on-the-fly project.  Even if you're doing it XP style and spec-ing only one feature at a time, it's still better than completely winging it and going through iteration after iteration to dial it in.

www.ChristopherHawkins.com
Monday, August 16, 2004

The difference in approach between prototype and incremental developing is the idea that developing is some kind of stone carving where mistakes can only be carved away and that you can't start from scratch.  The feeling that development is expensive to do and prototyping is cheap because it can be thrown away.

In truth the opposite is the case.

Software development is plastic.  If I develop a unit which involves a few forms, changes in the state of data and so on, so long as I follow the rules of designing interfaces I can rework whilst still providing a working application. 

And I can do that pretty much from day one on the project.

Simon Lucy
Monday, August 16, 2004

Another truism that gets misunderstood.

Joel has said in the past that so far as the user is concerned the UI is the application.  And this is true.

But this is also true, for the developer the UI is absolutely _not_  the application. 

Successful development and successful interaction with the stakeholders requires both views to be held simultaneously by the developer.

Simon Lucy
Monday, August 16, 2004

Simon, I'm not following you.  Are you sharing our reality, or are you off in your own.  What has maintainable, agile code got to do with specing?  They are both important.  Of course you should write agile code, but if you haven't got a detailed spec, you're going to get many, MANY opportunities during the course of a project to find out JUST how agile your code really is.

muppet
Monday, August 16, 2004

I'll give you chance to catch up.

Simon Lucy
Monday, August 16, 2004

Bored,  you're making some good observations in this thread.  But I have to comment on a couple of things:

"And once again: my experience with one man/small consulting shop assignments is that it's VERY difficult to get informed client buy-in on lengthy specifications. IE, they won't read them if they're over 10-20 pages. Sometimes not even if they're fairly short. "

This is a client education problem.  I've found it is useful to write specs that cover 1 particular task end-to-end, and only from the functional perspective.  Let them get used to reading the 3 - to -6 page specs before you try to bring them in on the longer ones.

Remember, a lot of your clients have never been exposed to anything resembling an engineering project.  While I don't mean to drag up the old argument of whether constructing software is truly engineering, I use the term to illustrate the amount of attention to detail needed in any software project.  Don't be afraid to be patient but persistent with your clients.  They don't need to be exposed to everything, but they definitely need to be involved enough to help you define what needs to be built.


"Most clients wrt smaller projects expect you to hit the bulls eye without much, if any participation from their end. They often tend to feel that they have no obligation to do anything until delivery. "

They do, they really do.  And again, casting a wide net and making the right people from your client a part of the team is a necessity.


"Also, there is always the danger that the client considers the work done when the user interface appears done. So if you do mock ups (for instance) they may expect you to charge very little beyond that because they dont' appreciate all the work required beyond laying out screens."

Now this is very true.  I've gotten in the habit of using Visio to draw screenshots.


"Consulting is about managing expectations. "

You get ZERO argument from me on that one!  ;)

www.ChristopherHawkins.com
Monday, August 16, 2004

Christopher Hawkins, a question:

How, exactly, do you approach the issue of being compensated for prototypes, mockups and plans?

That is a substantial investment in a project that may or may not come to light.

I am interested. I'd like to do it that way but I never seem to be able to get back the client's desire to make all the stuff that makes their head hurt go away....

Bored Bystander
Monday, August 16, 2004

get back ==> get past

Bored Bystander
Monday, August 16, 2004

Way to skirt the challenge, Simon.

muppet
Monday, August 16, 2004

No, not skirting anything, it just seems tedious to repeat everything written in separate chunks to make exactly the same point.

1.  I did not say that specifications were unnecessary.  I said that good agreed requirements was the basis. 

2.  Specifications from those agreed requirements can be as detailed as it is economic to make them.  A few clients I've had are willing to pay for that, most are not.  Though its interesting to note as a side issue that those public projects which are specified to the nth degree are also more likely to fail because the time taken to produce the specifications renders the requirements out of date.

3. I stated that prototypes are a waste of time.  They are.  This is a simple fact.

Simon Lucy
Monday, August 16, 2004

>> Specifications from those agreed requirements can be as detailed as it is economic to make them.  A few clients I've had are willing to pay for that, most are not.

At least I'm not imagining things.

Christopher and Simon, you guys are telling it like it is. Perhaps arriving at different conclusions/methodologies but confirming things I've seen.  Thanks for the commentary.

Bored Bystander
Monday, August 16, 2004

Then it's a case of client education.  If the client is not willing to allow me to succeed, then how can I do any work for them?  I'd look elsewhere.  Why tarnish my reputation again and again by playing lapdog to the semantic vagaries of a client who won't commit a comprehensive description of his needs to paper?

muppet
Monday, August 16, 2004

>> client education

Muppet, you're hitting a nerve there. "Client education" can often be interpreted as pushiness or intrusiveness. It's generally not billable and you can't let the client know that you know that they don't know something.

My concern is that I'm being asked to write software to solve a problem, and not evangelize.

Bored Bystander
Monday, August 16, 2004

+++and you can't let the client know that you know that they don't know something. +++

If the client does not acknowlege that they hired me because they needed my expertise in the first place, then I'm already doomed to fail.  The rest follows as I've posted above.

muppet
Monday, August 16, 2004

Bored,

Specifications are a normal part of the project, and are billed as T&M like everything else.  If the project is a rescue effort where I've been brought in to right a failing project (which happens a lot), I spec it out feature by feature.  If the project is for new development, I'll invest a few hours into gathering sufficient information to put together a proposal, but it's always high-level - the view from 30,000 feet.  If the client signs on, then we start spec-ing things out in sufficient detail to build from.  That part is billable.


"My concern is that I'm being asked to write software to solve a problem, and not evangelize."

Right.  And to write software that solves a problem, you need a certain level of detail or the project will fail.  This is not evangelizing.  This is doing the work.

Clients need to be educated, but not preached to or evangelized.  You simply request the things you need in order to make the project a success.  Don't allow yourself to be put on the defensive - of COURSE you need certain pieces of information in certain levels of detail.  Act as though it is the most natural thing in the world.

Very few clients have seen a development project.  Fewer still have seen it done right.


"If the client does not acknowlege that they hired me because they needed my expertise in the first place, then I'm already doomed to fail."

Very true.  And sadly, there are a lot of clients like this, who want a 'command and control'-style relationship with their service provider.  These are the kind of clients I try bery hard to avoid.  Nobody wants to get into a situation where there are many ways to lose, but no way to win.

www.ChristopherHawkins.com
Monday, August 16, 2004

To the original poster - that seems like a smelly (and patronising) contractual clause to me.

It's too hard to define a standard of professionalism with regards to contract SW development. I mean, professional what? Professional coffee-making? Professional clothes? Professional language?

Get them to be specific because anything that is loosely based on subjective criteria without measurable specifics puts you in a vulnerable position.

TheGeezer
Monday, August 16, 2004

Can't you use terminology like 'industry standard' though?

Things like variable names having some sort of nomenclature to them... that's industry standard right?

I guess you could even go so far as to demand certain things. Like demand they use hungarian notation for variable names or something. Demand (minimally) comment blocks that describe the purpose and function of each class object, things like that.

I mean, I think there should be some things that you can legally expect and demand. I haven't ever been on the buyer's side of that equation though, so I guess I am biased.

standardized mess
Monday, August 16, 2004

Simon Lucy - I accept your terms. Professional relationships go both ways.

AllanL5 - I can measure professional quality & behaviour using various well-defined criteria. Not least the code of practice/conduct of the BCS or IEEE, the accepted standards for the professional grades for those organistions and if it comes to it, an expert witness. I agree that there are ambiguities. There are ambiguities in medicine and the law too and ultimately they rely on peer review. If your professional peers say its crap, then its crap.

Muppet - my you got in there fast. Have you ever worked on a *really* big system ? At some point your spec becomes so big its never finished.

Management material- you missed the point. Yawn.

TheGeezer - I refer you to my earlier answer. What is a smelly clause ? Is that a legal term ?

I guess my point is if you accept a job where it has been made clear to you that we want a *professional* then you had better act like one. Maybe software development should go all-certified - acadmically that is, not commercially certified.

WoodenTongue
Tuesday, August 17, 2004

Hey, nice troll at the end there.  We all know CS grads are the only competent programmers, don't we?

muppet
Tuesday, August 17, 2004

Gosh, this has been a good thread.

Wooden Tongue -- thanks for the clarification of what you meant when you said "Professional" -- I think it is a pretty good definition.

My point was that I have never been measured as a 'Professional' against the standards you point out.  Nor has the quality or lack thereof in the products I deliver.  Being a studious engineer, who reads and applies many quality standards in my work, I believe I would be measured as a 'Professional'.

Instead, my customer measures my products, and by extension myself, against what they have in their head.  It may be a very informed understanding of the difficulty of producing quality software.  It may be a very ignorant 'software is simple / how hard can it be / it shouldn't be this hard / my way is the right way' point of view.

My point was, and remains, that when you include the term 'Professional' or even 'below-par performance', you have opened the door to very simplistic definitions of these terms, where the developer loses. 

AllanL5
Wednesday, August 18, 2004

*  Recent Topics

*  Fog Creek Home