Building a system, Quality is irrelevant, as long as it does what was asked for!?

[Boolean]

The last contract I had, I produced a quality system delivering what the client asked for. I even introduced additional pieces of logic, that would stop the system from crashing in a few months down the line where I anticipated certain problems.

It occurred to me that if I had built a worse system I would have stayed in the role longer. The client doesn't even know the difference.

In future is it best to forget about Quality, and just do as asked!? Even though what they are asking for is not the best approach, or an ill considered plan?

Yes I am a naive newbie.

[TheMonkey]

Quality is essential.

If you consider a triangle - at each point you have Quality, Cost and Time. You can draw a dot anywhere in that triangle to describe the project from your perspective. Explain this to them and try and get them to draw a dot right in the middle by balancing the quality, time and cost.

Also, keep it simple!

[Fleetwood]

Do what the customer asks, but also suggest enhancements which you can program therefore creating more work for yourself. Sorted.

[tacpot]

Quality is your gift...

Never give less than you are able to give.

The client may not know the difference, but you do! Even if your code is never looked at by another pair of eyes, you should leave knowing that it was your best.

Your are the quality of your work.

[funkyd]

I work on the basis that you deliver exactly what they asked for (function spec / business requirements) and no more. If they don't ask for an e-mail when the service stops then don't give one.

When the system is deployed and the service stops they will realise they need an e-mail to tell them - so you modify it to do just that - and so the process continues.

Always deliver 100% in terms of quality and meeting their needs but never go further. If you spot something that they have obviously missed then point it out and adjust the project plan accordingly - ask them if they want it done now and the schedule change or do it after - but make sure it goes on the plan.

[ASB]

Quality is not absolute. It's about fitness for purpose. An Escort and a Bentley are both quality cars. Not everybody is after the Bentley.

I think one has a duty to point out flaws and pitfalls in a design or implementation. I think a client should listen to that advice. However they have no duty to take it, just to be aware of the possible consequences.

[funkyd]

I think one has a duty to point out flaws and pitfalls in a design or implementation. I think a client should listen to that advice. However they have no duty to take it, just to be aware of the possible consequences.

I agree! Point things out, indicate that time-scales and costs might change and let them decide what to do. As long as you keep a record of such things, the client can never say the software was not fit for purpose - or the opportunity to fix thingns was never given.

No client will appreciate you turning their 1 week project into a 6 month monster that does a million things they never needed - that's what off the shelf systems are for.

[meridian]

I work on the basis that you deliver exactly what they asked for (function spec / business requirements) and no more. If they don't ask for an e-mail when the service stops then don't give one.

When the system is deployed and the service stops they will realise they need an e-mail to tell them - so you modify it to do just that - and so the process continues.

Always deliver 100% in terms of quality and meeting their needs but never go further. If you spot something that they have obviously missed then point it out and adjust the project plan accordingly - ask them if they want it done now and the schedule change or do it after - but make sure it goes on the plan.

Sooner or later this may come back to bite you on the ar$e, though. I've worked on a number of projects where the clients themselves were not too sure exactly what they wanted, and they could have used the advice and input of the developer before the functional spec was finalised, or at the latest during development.

In the example you've given above, the client may be a little pi55ed that you could have advised them that an e-mail facility was required before it got to deployment, thus saving them additional development and testing time.

Just my 2p as a tester, I've seen too many developers just code exactly what the spec says without even questioning whether it's right or not.

[funkyd]

I've seen too many developers just code exactly what the spec says without even questioning whether it's right or not.

If what you've been told is wrong then that's not your fault is it? If they say data from A must be fed into system B when in fact it should go to C well that's their fault imo.

If however, we are talking along the lines of "Yes, but what happens when the sql server crashes - how should the system respond?" then yes - clients don't think of these sorts of things and they have to be reminded.

You can't tell people what they need. You can advise and recommend but ultimatly it is up to the client. I get a bit nervous when a client says they want something to do something but not exactly sure what it should do.

If your at the stage where the client isn't able to accuratly tell you how their business functions then you should call it a day perhaps?

[XLMonkey]

If your at the stage where the client isn't able to accuratly tell you how their business functions then you should call it a day perhaps?

True-ish, but you also need to bear in mind that the law regarding software has changed significantly in the past few years. The courts are moving progressively towards the same sorts of standards that apply in the building industry... meaning that the client has a lot more protection than they used to.

If you are providing software development services (i.e. outside IR35) then you are under a series of legal obligations to act professionally and to be liable for the quality of your work and advice. The most important of these are:
- that the software has to be appropriate for the customer's need (so you can't just develop what they've asked for if it is obvious that it isn't the right solution)
- that it has to be fit for the desired purpose (this means that if the customer specified the requirement poorly -- you are under an obligation to clarify it, not just develop as specified)
- that you have to inform the customer of the predictable consequences or limitations of what they have asked for (this means that if it is obvious that they will need an additional interface in order for it all to work, you are obliged to tell them in advance).


of course, if you're inside IR35 then none of this counts -- this protection is one of the benefits that clients get from operating on proper B2B terms.