client has long standing relationship with company X who have been providing them with application Y for the past 20 years.

client commissions you to create a web interface to application Y.

asking company X to change the API of application Y, and the client to pay for those changes = client goes somewhere else.

"hafta" cannot be dismissed so easily.

...as in "you hafta deploy this to the live environment by next Tuesday, otherwise you'll hafta cough up umpty thousand per day in penalty charges. Before we've even paid you for the work. Oh, and by the way, some numpty of a minister or senior civil servant who knows bugger all about it says you hafta change this bit of the system specification YET AGAIN, because he once almost managed to balance his bank account using MS Excel (with help from his 9-year old daughter) and so thinks that he is now some kind of expert on these computer thingies."

Been there, had to do that, not as easy to avoid as we would all like. And yes, I know that it's down to a spectacular failure of contract/bid/project management that this kind of thing should happen in the first place, but it's always the design and engineering teams who have to pick up the poopy stick when it does inevitably happen.

That's a fair point, the rules change when you're talking about making demands on the gold-owning client. Ultimately it's their project, they can have the bread buttered around the edge if they want: as long as it's in writing that they're going to have greasy palms afterwards.

Having said that, a client relationship isn't (or shouldn't be!) totally one-sided. You need to be able to push back a bit.

So, you are agile if you don't compromise, and build a perfect system, but not so perfect that you do unneeded work. And no advice on how to achieve the nirvana of perfect design.

I now publically cry "bullshit" on the agilists who say "if you are agile, you do it perfectly, and if you don't do it perfectly, you obviously weren't agile." People like this should not be allowed to blog, let alone design important software.

Real software developers should stand up on their hind legs and laugh at agilists, unless they cough up some actual advice on how to do a good job. And I don't mean saying, "Be agile." I mean what, when, where, why and how kind of advice.

All I've read of agile design by people with actual advice to give would cause agile teams to compromise heavily so as to begin earning value quickly. If an awkward API caused issues, it would be cleaned up incrementally, not by an extended design process.

What's up with this contradictory advice?

Yes it is all very professional indeed.

1. you develop a system on time.

2. on budget

3. with required functionality

4. according to the requirement spec

5. that YOU created - together with the client.

6 classify this as success

7 find out by coincidence that there is a difference between client and user.

8. resulting that the 'succesful' agile development process helped to create a system that is not being used.

9 Conclusion: 'great' (?)

...write the Program's Bible--and stick to the D*MMED BOOK!

It's only *after* the initial work is over and there's time leftover can they indulge in building extra features. That's the "agile" part that the retards in Mgmt/Design that just don't get 99% of the time.

The Program's Bible is there for a reason.

Unless you're developing some system that is completely stand alone, and you get to pick all the design/implementation criteria, the hafta method is what you hafta use. Most of the time, you need to interface with some third party package, or some existing system. Couple that with corporate standards regarding hardware, operating systems, languages, methodologies, etc., you're in the hafta realm.

I've seen places where everything is built using the ideal world, but, what you wind up with is a bunch of stand alone systems that don't work together and are unmaintainable.

Jim: Yes and no. Yes, no-one said it would be easy. But when you're dealing with sub-par interfaces, those are the times when it makes sense to rattle the cage even louder.

I really didn't follow your second point: In an ideal world you wouldn't want unmaintainable systems that don't work together. So if everything is genuinely built using the ideal world, you'd end up with the opposite: maintainable systems that talk to each other nicely.

It's called a "compatibility layer", kids.

Think of it this way. You have the Ugly API, covered in warts, black as pitch and sin, controlled by some other group you have no control over.

Then you have your new project. You want to build your project as perfectly as possible, but you've ALSO got to work with the Ugly API, and you can't ruffle the feathers of the group that owns it.

What do you do?

You write your software the way you WANT to, with exactly the interface you think is best.

THEN, you pick the most irritating member of your team and you make him write a compatibility layer between the Ugly API and your beautiful API. You must pick the annoying one because he's going to be having meetings with the Ugly API team and you want to get at least some karmic revenge out of the deal.

Whenever you have to interact with the Ugly API, you use the compatibility layer.

When you interact with better APIs, you can use better approaches.

THAT'S how you do it. :)

Paris, because she'd put a bodyguard (or three) between herself and a hideous pub-goer, which is similar in spirit.