Comments on: Software requirements do not change

By: J

Mon, 28 May 2007 12:31:10 +0000

“Likewise, clients do not project their false view of software into their final product and instead, trust the better judgment of a more trained practitioner (ideally).”

I would like to have your clients. Mine just demanded a /different/ database schema two weeks before delivery. I’ll leave it to the philosophers whether it was a new schema or the same one with some grubby patches on it.

Speaking of philosophers, I just read … um… Kant?, who claimed it was immoral for one generation to bind the next into a contract. Not exactly relevant, but an amusing coincidence for me.

Hmm… when I change my mind, is it the same mind, or a completely new one that just looks a bit similar?

– J (Ex banana bender)

By: Paul

Paul — Tue, 02 Jan 2007 12:40:54 +0000

You’ve merely redefined the term “requirement” in a manner that makes it useless for talking to actual customers about their problems. “We don’t sell sprockets anymore so you can remove that from the software requirements.”

“I’m sorry: I can’t remove that requirement. Requirements never change and are never removed. You COULD add a new requirement that says that it is now impossible to buy sprockets, but that would put the total requrement set into a state of contradiction. Therefore you must continue to sell sprockets.”

By: Andrey Khavryuchenko

Andrey Khavryuchenko — Sun, 24 Dec 2006 10:22:56 +0000

While, formally, you’re correct, I wonder what’s the point in the distinction between “software requirements changed” and “we need to develop a similar product with slightly different features”?

As Dave pointed above, softdev clients don’t think in terms of software (or lambdas). They think in terms of “business problem” that requires a specific “business solution”. When the business solution, they envision, includes a software component, they go to, say, us and ask for a development service. When a business problem (or understanding of a business problem, which are quite the same things) changes (e.g. the solution is thought up in more details) then they ask to develop a little bit different.

So, I don’t see quite much of added benefit in your distinction. Where I can use it? In communication with a client? They simply won’t understand us. Besides we already invested much effor explaining that if they request something new or changed, the whole development plan (and budget, of course) should be changed.

Use to communicate within a team? We already know that what we develop is a seria of snapshots from requirements to the tests to the code. If something changes, we have to make a new snapthot(s)

Please, explain?

By: Dave Neuer

Dave Neuer — Thu, 21 Dec 2006 22:58:24 +0000

You should really just write an article about referential transparency and how functional languages are better, instead of dressing it up in confused philosophical arguments. When we say “the requirements changed” we don’t mean “the definition of the concept ’sum two integers and add four’ changed” we mean the client no longer thinks that concept applies to their business situation, and please make sure that computation is not performed for them.

By: Tony Morris

Tony Morris — Fri, 15 Dec 2006 22:14:40 +0000

I agree, except even more so. If you have broken the contract with your clients, then it is not “just a new library”, it is entirely new software. Did you know that Java 1.5 is an entirely new programming language?
Your qualification of “more seriously” is not necessary - it already is serious. The problem is defining the bounds of the client contract. In a leaky language like Java, it is entirely possible that renaming a private class field breaks contract - since clients are free to perform logic based on that name. Even changing a class from non-final to final or adding a different return value for some given inputs e.g. throwing an exception.

Your perspective of “new library” - that I assume aligns with my existing definition of “new software” - is an extremely important aspect of writing software across the axis time. This lack of decomposability of the “software”, when written in poor languages, is exactly the reason why there is now a general tendency towards more powerful (no not Lisp PG! (or Ruby/Python for that matter)) programming languages for expressing that software. I just hope that this tendency reaches a large extreme before one of the big players come along and halts it (as they do) with something like F#.

By: Ricky Clarkson

Ricky Clarkson — Fri, 15 Dec 2006 01:11:33 +0000

“you have broken your contract to all clients of your software”

Using the same logic back at you, the clients should not assume that a new version of your software is compatible with an old version - it is not just a new version, it is a new library. It is entirely coincidental that much of it has remained compatible.

More seriously, it’d be interesting if it was practical to use more than one version of a library simultaneously from the same codebase - I expect with the OSGi model it is.