The Reason
The ReasonThis is a pattern based on my First Principle (see SevenPrinciplesOfSoftwareDevelopment). Please give feedback at the bottom.
Author: DavidHooker
Pattern: The Reason It All Exists
Problem: Making decisions during software development is hard.
Context/Forces: You are constantly faced with decisions during all phases of a software development effort. These decisions often include such things as "Which methodology?" "Which language?" "What are the requirements?" "Who's the target user?" You want to make the best decisions possible, so that the project is a "success". You (or a group) has a definition of what "RealValue" is.
Solution: A software system exists for one reason: to provide value to its users. All decisions should be made with this in mind. Before specifying a system requirement, before noting a piece of system functionality, before determining the hardware platforms or development processes, ask yourself questions such as: "Does this add RealValue to the system?" If the answer is "no", don t do it.
Resulting Context: All decisions will be the correct decisions, and only those things having RealValue will be in the resulting system.
Feedback Section
Not all correct decisions can be attributed to providing value to the users as your solution implies. Often the choice of methodology or tools is (or should be) driven by the needs of the developing organization, not the end user. What makes it into the resulting system should be driven by the real value question. How you get there (tools, techniques, etc) are organizational questions:
I guess I consider the developers of the system as users also, just a different type. They "use" the architecture / design / code / tools / etc... during development. Someone (I can't remember who right now) said:
A good architecture is one in which developers like to work.(or something like that 8-) I also think that RealValue encompasses the development organization: if we don't ourselves derive RealValue from the system we are developing, it is that much harder to provide it to the end user. Examples of this derived RealValue are artifacts like patterns, frameworks, and documentation.
With XP and other highly iterative processes, I think you can change this to say that you produce something of "real, demonstrable, immediate" value. It's not enough to be working on infrastructure and architecture for months. You need to build the real functionality. Otherwise you have no feedback loops to see if you're doing it right, and nothing to show your project's shareholders.
XP answers this question differently. We don't try to do something of value: we do what the customer asks us to do. Customers estimate value, developers estimate cost.
I have no trouble getting people to do valuable things, but I do have trouble getting them to stop practicing AnticipatoryDesign? in the sense of components they'll "someday need" in direct opposition to YAGNI.
I've found a protopattern TimeForUs that you all may find obvious and/or useful.
The problem with this is that developers will always tell you that their proposed change will offer RealValue. You need to have a measure of RealValue and you need to pick the things that have the most. But it is very hard to measure RealValue. Therefore, let the customer decide. But people can't pick what they want the most unless they know the cost. Therefore, developers have to tell the customers the cost of each change, and then the customers can pick the ones they want.
As written, this is too vague to be a pattern. Just asking yourself "Does this have value?" will not work. A pattern should be written in such a way that readers know what they are to do. -RalphJohnson
I'd say that "value to the user" is "close, but no cigar". In most cases this works, but the sad fact is that it is "value to the owner of the software" that is key. When "owner"=="user" it makes no difference. But if I'm a user intent on cracking a password to read someone's EMail, or a user setting up a clandestine WWW site to sell drugs and porn... then the user's value is opposed to the owner's. In these cases you need AntiUseCases? where the software must guarantee to stop a user doing them, rather than permitting the users to do them. ---DickBotting
Building products of "value to the user" seems as blantantly obvious to me as "buy low, sell high" might to any investor. But how does one determine what's of value? Do customers really know what they want? I'm thinking of DisruptiveTechnology, which might have been of no obvious value to existing customers, but enabled a new space of customer which could not have been anticipated. InnovatorsDilemma was an excellent book on this sort of technology by an author who's name I can't recall. -- DeanBurson
One of the larger examples deals with hard drives of smaller form factors that were being developed by newer companies. These were ignored by those manufacturing hard drives of traditional form factors whose customers had no use for them. Instead they concentrated on increasing the performance/capacity of their existing products. Then PCs became mainstream and the smaller form factor rapidly gained market share. -- AnonymousDonor
After some decades in the corporate trenches, I suppose the thought that occurs to me is this: Invent any notion of metaphysical goodness that strikes your fancy, however vague; but at all costs do not tell the managers about it, or you will find yourself filling out a RealValue justification form every time you want to purchase a box of paper clips. Hmmm... suggests a new topic: AntiRigor?.
Fancies are not sayable to your boss. It spoils them. The fancies, that is.
The Reason for No Value in IT anymore:
Real-World Federated Pizza Deployments featuring NitroX for Struts, Eclipse Edition - Download FREE
Translation: There Is Nothing To Do Anymore That Anyone is Willing to Pay For.
Also see RealValue.
EditText of this page
(last edited December 25, 2010)
or FindPage with title or text search