The Spirit of the Requirement
It's time for software developers to quit doing what we're told and start thinking. We're not robots. We're intelligent individuals who can consider context and produce results beyond the handicapped communication of a formal requirement.
It's the software developer's responsibility to ask questions, listen to the answers, and do whatever it takes to understand the problem and it's symptoms; ultimately capturing the Spirit of the Requirement. The Spirit of the Requirement can be likened to the Spirit of the Law, where the focus is placed on intent; not literal definition.
For example, it's a terrible idea to spend hours styling an Adobe Flex application to match an HTML mock-up. Everyone, including the developer will be disappointed. If the customer wanted HTML, they obviously could have done it themselves. Think. Interpret. Provide value.
This problem is more common than you might think. In fact, if you haven't witnessed similar situations, then chances are that you've unknowingly participated in them. Consider an experience where you had done exactly what was asked of you, yet it wasn't good enough?
It's time we open our eyes, lift our hands from our keyboards, and be more than requirements transcriptionists.
I’m not sure who this is aimed at since people who are interested enough in their craft to read blogs about it don’t need to be told this but . . . yeah, I’ve seen way too many people hide behind a requirement document, do what they think is asked of them and defend their failure by saying the requirement was incomplete.
Problem is, these people often do this because they’re not interested or lack the social skills to push back on the business. Identify these people in your organization and make sure there’s someone to be their proxy for requirement work.
Yes, it is a pity that we still have to explain to some people that it doesn’t work to “specify everything up front” and let some cheap programming slaves implement those specs.
On the other hand it nearly never works out well when a software developer says: we don’t give the customer what she wants, but what she needs. In the end it’s up to the customer what provides value, not to the developer. /Asking/ and /listening/ are the central points.
I find requirements to be sadly lacking in most projects. The coder really has to understand the problem domain to properly engage it. The better you understand the environment of the field/position that will be using the software, the better the software will be. It all depends where you want your project to be. The spectrum goes from “Requirement in. Product Out.” on one side, and creative engagement by a gifted craftsman working with the most intelligent and demanding user of the function, on the other. You get what you pay for…
The one wrinkle in this philosophy is when the project that you are working on is outsourced. We recently had the pleasure of offshoring a lot of our work, and the last thing we wanted was for the coders to interpret the requirements in their own way. This was because of their total lack of familiarity with the problem domain, though. I agree that if you have developers who understand the business rules and goals of the client/user of the application, then you’re handicapping yourself if you don’t allow the programmer to explore better solutions to the problem at hand.
Well, it depends at what level you develop. If you happen to be a developer of a large team and your task is to develop certain functionality, read the requirement and finish it off, maybe you might not neet to know the whole scenarios behind this.
If you are a developer developing certain modules, or components, then you might have to consider many dimensions and views of how the component or module might be using.
Most of the time, the people who define requirements might not know the technology and you might be able to suggest new ways of doing things that might be more productive and cutting edge. You might also want to develop them in such a way that future integration or expansions are flawless.
My personal view is that the requirements investigation has to be taken up case by case. In anycase, an solid architecture and design should be in place before starting developing the actual system.
ME: Excellent point about having someone “proxy” the requirement work for certain types of developers. I’ve seen developers “hide behind the requirement document” when they are:
1. truly oblivious to the intent of the requirement or unable to read beyond the text. This is seems to be a comprehension or personality issue. The Wikipedia article on the Spirit of the Law discusses the mismatch with the Authoritarian personality type.
2. being spiteful. The developer understands, but is only doing the bare minimum; potentially make a point.
MANUEL: I agree. It doesn’t work when the developer independently determines value. Asking and listening are the central points. Capturing the “Spirit of the Requirement” is really a goal that is met through open communication so there is a common understanding of the what the customer values. Everyone needs to be aiming at the same target.
I knew that someone would touch on the scenario of coder’s as skilled laborers. The truth is that this posting is a third attempt at conveying my thoughts on the subject as a whole - the others were long and boring reads. The shortened version you have read focuses on the “Spirit of the Requirement” at the developer level. The “Spirit of the Requirement” should really only be applied at the layer of the development team that interacts first hand with the customer. I described it at the developer level because I believe that is the most productive, successful place for requirements to be gathered - but that is an entirely different topic.
MIKE D: It sounds like what you are providing your coders is not customer requirements, but individual concrete tasks that you and your team have identified as the parts to completing a customer requirement as a whole. Any interpretation of intent has already been done and broken down into tasks prior to the hand-off.
ZAHARAN HALEED: It really does depend on what level you develop. If someone breaks requirements into tasks for you, then it isn’t crucial for you to know the whole problem domain; but then there’s very little room for craftsmanship. This is probably a very common scenario that can work well, but leaves your best developers thirsty for more. Increasing the number of layers between the customer and the developer has a similar outcome to playing “telephone.” Capturing the “Spirit of the Requirement” is a common goal that can be applied to all requirements investigations at the level of customer interaction.