Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I find that some software developers are very adept at this, and often times are praised for their ability to deliver a working concept with abstract requirements. Frankly, this drives me crazy, and I don't like "making it up" as I go. I used to think this was problematic, but I've started to sense a shift, and I'm wondering if I need to adjust my thought (and programming) process when given very little direction. Should I begin to acquire this ability as a skill, or stick to the idea that requirement's gathering and business rules are the first priority?

share|improve this question
2  
A situation to avoid. Only thing is, you can't. And I've rant about it few weeks ago... –  Yannis Rizos May 29 '12 at 1:22
61  
It's both, sort of like operating a fire extinguisher. –  Ben Brocka May 29 '12 at 2:47
3  
If you fail to plan, you plan to fail. These projects built without requirements may or may not meed the customer's expectations when they leave the shop but they almost certainly hide a multitude of sins that mean that when the requirements change (and they always do) a world of hurt awaits the person who has to make the necessary changes. Programmers who write without formal requirements shouldn't be praised, they should be reprimanded for failing to be prepared for the long term future maintenance of the project –  GordonM May 29 '12 at 6:47
8  
Obligatory Dilbert: dilbert.com/strips/comic/2006-01-29 –  Dan Neely May 29 '12 at 12:32
4  
Sometimes, the customer doesn't know what they want. They want you to run "experiments" to determine what they want. I once wrote a commission system where the only requirement was to pay commissions. The percentage and items to pay commission on were to be determined by experience with the experimental commission system. –  Gilbert Le Blanc May 29 '12 at 14:36

10 Answers 10

up vote 73 down vote accepted

The skill isn't to write software without requirements. It is instead to elicit requirements from the project owner regardless of whether there is a formal requirements documentation or not.

Gathering requirements is definitely your first priority, but you don't necessarily need to get all of the customer's needs noted up front. The risk is of course is that you might miss some vital piece of information that renders your system architecture useless if you haven't managed to have the right sort of conversations with your customer, however it is not unusual to define a product and even get much of the development out of the way, while deferring the major system architecture decisions until the last possible moment. This is a lean development approach which is meant to ensure that you don't commit to a potentially incompatible architecture too early in your product development until you have more solid information. In the situations the OP has described in his question, this lean approach would be quite important IMHO to avoid major rework and cost blow-out later on, which is when you've finally managed to learn what it was your customer really needed.

Yes, you do sometimes need to crystal-ball-gaze a little to get to the heart of what it is the customer really is asking for, which is where prototyping spikes and the slow - and yes sometimes painful - incremental drawing out of requirements requires that you really develop good customer relationship skills, and also the patience to realize that with any complex software idea, that in the beginning the customer doesn't often know much more than you about what the software actually needs to do. Most often, the customer calls you in early to depend on your expertise to define their requirements as the customer doesn't always have the necessary expertise or knowledge of the software development process.

share|improve this answer
21  
"The skill isn't to write software without requirements. It is instead to elicit requirements from the project owner regardless of whether there is a formal requirements documentation or not." This is also something I've been thinking a lot about. It's almost like being a good detective, or knowing how to interview someone and ask the right questions. In this situation I find the question, "Can you tell me what you want to do?" works much better than "Can you tell me how it should work?" –  Brian Reindel May 29 '12 at 2:52
5  
@BrianReindel I sometimes start with a combination Mind-Map/Binary-Tree of the customer's thoughts. I ask "What is the idea?", then use word association to see what each idea brings to the customer's mind. From there I build a picture of what the customer is thinking, and I start to define requirements from there. Each requirement evokes questions which need to be asked. Usually "Why" questions get me a better response than "What/How" questions, as they give the customer an opportunity to think beyond the basics. It's basically an art in using psychology to get the customer revealing needs. –  S.Robins May 29 '12 at 3:02
3  
Part of the skill is knowing the order in which to do things and to avoid "perfecting" things that will get ripped up anyway. That way, you can meet with the customer/manager/whatever, show them what you have so far, and adjust as you go along. You need to know how to take the big steps in the right general direction first. –  David Schwartz May 29 '12 at 6:59
4  
One way of eliciting requirements is to give them something basic, and see which parts they complain about. For example, create a paper prototype (amazon.co.uk/…) and run through the interactions with them. –  deworde May 29 '12 at 7:57

This is very ambiguous …

Two things I can say:

  1. There are a lot of very gifted technical people whose careers get halted because they wait for perfect requirements. Or they play the, "Sorry, can't do it, wasn't in the requirements." The reality is requirements writing is very difficulty. The precision required for good requirements is unlike anything most business people have ever created. There's a bridge between technology and the business, and people who make the others come 100% of the way to meet them usually lose.

  2. There are software people who learn the domains as good or better than their customers. These people are worth their weight in gold, even if they aren't 100% the best developers. I have seen software people anticipate the quantitative marketing needs of the best brand managers in the country. They weren't the best at coding all the solutions, but they were heroes because they could cross the bridge.

Life's not about black and whites though. If you draw a narrow box around yourself, you'll limit yourself. On the flip side, an organization that dismisses what's needed to create technology is also limited. You'll have to see where in the gray you prefer to be.

share|improve this answer

Requirements are the steps in the journey, a vision is the direction

For many applications a highly detailed technical specification is just too much up front since a quick discussion could render their carefully typeset document useless. Instead, start with a vision. If everyone understands the overall picture then the requirements can get filled in along the way through discussions.

As a developer you must learn to use these discussions to trawl for requirements. This means asking the customer leading questions that get them thinking about how their decision today fits into the overall vision. The earlier these more detailed discussions take place then the quicker the overall vision will solidify into a coherent design.

You should keep track of the outcome of these discussions in some kind of issue tracker so that others can comment on them if they missed the original discussion. And so that you have a record you, or other members of your team, can refer back to should you need clarification.

So, learn to code against the vision, but be ready to trawl for those requirements when the time comes.

share|improve this answer
    
+1 for "Requirements are the steps in the journey, a vision is the direction" –  user May 30 '12 at 2:23

Steve Jobs believed that customers cannot describe exactly what they want the future products to look like, so it is your job to deliver them. So, unless you deliver custom software all the time, forget formal specs and start by creating prototypes and letting the customers play with them and tell you what they think. You have got to put the right person doing the prototyping, and they need to have help. I say this from experience - I am the prototyping monkey who loves creating intuitive interfaces and I teamed up with someone in product who understands what the clients want and can explain things on paper or using Excel.

Neither of us are geniuses, but we think alike - you can almost say we have got chemistry and have had a huge impact on which things are being built and how. Now, only a mid-to-large team can afford to have a prototyper and a non-coder who develops product exclusively, but it is well worth it. Prototyping is the cheapest stage in the software development, so it only makes sense to get the UI and the apparent behavior right. I have not read Code Complete but I think there is something like that written in that book.

Specs are nice to have, but they are never perfect. There exists a theorem about that. You cannot prove that the spec is complete and you cannot prove that the tool has no bugs or that it will halt :)

Yet, software companies do ship software all the time despite these imperfections in the process. The spec will never be perfect. The spec is also UNNATURAL and outdated. A spec to a prototype is like logarithm table is to a single graph - a spec is essentially a boring brochure meant to be printed whereas you could interact with a tool / graph instead. Check out http://www.i-programmer.info/news/112-theory/3900-a-better-way-to-program.html for inspiration.

Now, spec is good if you must have a contract to cover your ass. But a spec should still come after a prototype, not before. It is your job to figure out how to make prototypes cheap.

share|improve this answer
    
+1 for the spec never being perfect, but -1 for the spec being unnatural and outdated. Think of requirements as a list of features a client wants, and a Spec being the list of behaviours that define what the customer needs. Essentially a contract of sorts defining how the system functions, instead of what the system is. Big up front design and specification is problematical, yet like all big problems is easier to do when broken down to be done a bit at a time. Prototyping is also rarely cost effective if you have no idea WHAT to prototype. This is where specs offer a starting point... –  S.Robins Jun 7 '12 at 0:12
    
... however, specs shouldn't necessarily be written in stone. Prototyping (essentially spiking problems) are most valuable when they feed new information back into the spec and where the spec is permitted to change to accommodate the things you have learned from the prototype. Without the spec, you risk simply making things up as you go, which isn't always in the best interests of the client. Clients expect you to fulfill their needs, and you risk less friction when you can provide evidence that you have agreed to something, even if only tentatively. –  S.Robins Jun 7 '12 at 0:16
    
@S. Robins, a doctor (client) might say something as simple as "I want to see a family tree with corresponding estimated cancer risk for each family member." Since there are many different ways to present this information and worry about large families that span multiple pages, I think it would be absurd to start documenting this as a spec right away. We understood what the doctor said, but we want to get more precise. An interactive prototype that displays random numbers and names that a doc can say yay or nay is more natural than an incomplete 30 page spec that attempts to describe the same. –  Job Jun 7 '12 at 4:33
1  
I understand where you're coming from, however what you suggest is usually an expensive approach. Obviously I'm not suggesting the prototype is a complete product, but anything you build where there is any interactivity will require time to develop. A less costly option is to stand at a whiteboard, sketch out a few ideas, and ask targeted questions to help you narrow down your criteria. I'm also not advocating for creating a large spec. Outline documents, or even test code templates, produced iteratively and as needed, are usually simpler and cheaper than prototyping first. –  S.Robins Jun 7 '12 at 9:57

A bit of both. You need to satisfy your clients, which means that you need to know what they want. On the other hand, clients are notoriously bad at communicating what they really want.

So you want to avoid scenarios where you don't know what clients want, but you will inevitably run into a scenario where the requirements are 'squishy' at best, and deceptive at worst. A good real world programmer requires adaptability.

share|improve this answer

It is not possible to write a program without requirements. Even the 'Hello World' has the requirement: to produce output. So, I think you're asking about formal requirements, in form of some big stack of something UML-like. And regarding those, I've met 2 kinds of people:

1) People that need formal requirements. They need to be exactly told what to do, and at best how to do it. They love the sentences like The procedure A taking the argument B will output C, and they hate those: The program should make the work of our deparment more effective. They are usually corporate animals.

2) People who are the oposite to 1. They hate to be told what to do and how to do, they love to be told what should be achieved. They like to talk to the client, analyse what they say and then develop their own solution. They are usually freelancers and don't fit good to corporation.

I won't say which of those is better. Both have their pros and contras. They are simple adequate for the other conditions.

share|improve this answer

I've often found that in some situations I need to act as a business analyst, discovering exactly how the business currently works, how people think it works (often very different things), and how they would like it to work.

I've found success by always being clear about the decisions I'm being forced to make in order to build the software. I explain my reasoning, write documentation on what I've discovered, make graphs and distribute them to everyone, etc.

You probably won't make a very good impression by refusing to do any work until complete requirements are handed over. But by gathering good quality requirements yourself (without necessarily drawing attention to the fact), you will reach the same goal of quality software.

And yes, as other commenters have said, always build the software assuming that it will change. Change is the one constant you can rely upon. Always build your software flexible and modular enough so that it won't be painful to update it when some new requirements suddenly appear.

share|improve this answer

If you want to work as a software developer at a startup, it's a skill to possess.

If you want to work at a consulting company then it's a situation to avoid at all costs. This is because your firm gets paid according to how well you implement the spec/requirements and not how well you solved the customer's problem.

If you are coding for fun in your spare time, then it's your call. If you don't feel qualified to make the call for your spare time projects then try a couple each way and see what works. Also it's not necessary a one-size-fits-all thing, some projects call for one or the other type of a approach. Usually if you pick the wrong one on one of these projects you'll figure it out pretty fast.

share|improve this answer

You can NOT develop operational software without knowing the Requirements; but, you can have a jolly good stab at developing what your experience tells you the Requirements are likely to be. Agile development uses a combination of 'intuitive' techniques, including the 80:20 Rule and the 'discovery' of Requirements by prototyping. In other words, an experienced development team makes a best guess at what's needed and produces a prototype of the software. The 80:20 Rule says they'll be 80% correct. The project stakeholders then review the tangible prototype. Their feedback begins to fill the 20% gap in our understanding of the Requirements. So, in effect, Agile isn't about writing software without any requirements, rather, it's about using your prior experience to say, "are you wanting something like this?" Which, in 80% of cases, will allow you to leap ahead and confirm what's really needed quicker than plodding through traditional Requirements processes.

share|improve this answer
    
Agile is not about intuition, it's about communication. Delivering working software often in order to receive feedback often is encouraging communication and valuing the delivery of the things the customer needs. Yes, experience comes into play, but you are more likely to develop what the customer needs if you first ask what the customer requires. The so called 80:20 rule doesn't really apply unless you are very familiar with the customer's business domain, and even then I'd take that 'statistic' with a large spoon of salt. –  S.Robins Jun 7 '12 at 0:22

Who said Agile was writing code in the absence of requirements? I know the Manifesto has been interpreted this way by some...but that doesn't make it right.

share|improve this answer
1  
Hi Trent, while I agree with your comment in principle (and I'm also tired of seeing how people use Agile as an excuse to screw the development process and call it "being agile"), this answer doesn't really address the OP's question, which isn't about Agile, but is instead asking about whether writing software without requirements is a skill to develop. Perhaps you had intended to add this as a comment to someone else's answer? –  S.Robins Jun 7 '12 at 0:28

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.