How concerned are you with the "why" when discussing requirements?

Question

When having discussions with superiors and other technical co-workers it is always a good idea to remind them to think about the "what" instead of the "how" when gathering requirements for a new software project. This in itself can be quite a challenge especially when you're dealing with technical folk.

Being part of a team of programmers, you know who will be coding the proposed requirements (after design ofcourse! or not Agile folk;-) )

Do you take the stance that you will code anything as long as the requirements are clear? Or do you tend to resist some requirements or suggestions that you feel are not worthy? I just can't get myself to accept requirements without putting up a fight if I feel that the feature/requirement will not have benefits or benefit 0.00001% of the customer base. Surely spending the effort on a feature like this is wasting valuable company time that could be spend on something with higher priority.

Where do you draw the line between constructive discussion of requirements or acting as programmer that simply accepts everything passed his way?

Answer 1

I think if you don't ask why, then you are more of a code monkey and less of a developer.

See Eric Sink's excellent article No Programmers.

Answer 2

I think you're talking about two different functions, that of a business analyst and that of a programmer.

Having said that, it's not unusual to find the two functions in a single person, particularly a developer with more experience within the problem domain.

Standard project management technique would suggest you start with the scoping, and the environment (the "why" and the "what"), and only when you get to identifying the work, to get down to the "how".

Frequently, the guys involved in organising the scope are not the guys doing the actual nitty-gritty work, so by the time they're involved, the "why" and "what" should ideally have been specced out.

With software development, particularly with iterative methods, the "what" is usually figured out as part of each iteration, which lets the "why" leak in, and should ideally involve lots of two-way communication between the developers and the client.

This isn't always how it works though :)

Answer 3

Depends on the role you're playing in development.

If you're working as a junior developer on a larger team, it can't hurt to ask 'why?' (it shows that you're trying to actually understand what you're working on rather than just blindly coding it...) but your hands are pretty much tied. If Senior members of the team want it, you're going to have to do it.

If you're a freelance developer building an application for a client, you should definitely ask about the 'why?'. It gives you a way to work with the client and verbalize your concern about what you're working on and where you're going to be spending your time. You just have to remember that if your client still wants it...you're probably going to be building it. (Unless, of course, you don't mind your client going elsewhere for the project to get what they want).

Answer 4

I am always very concerned. I can code if the requirements are clear, but ultimately it will hurt the organization if we start making software that doesn't make sense. Call it selfish, but that is bad for me. Really programmers are the people who know how it all fits together, because we have to make sure it works every part of the way. I used to work for a large bank, and the CEO plainly said in a meeting addressing the IT staff that the easiest way to find out how something works is to ask the programmers. He said, they have to understand the derivatives, because they have to be able to program it. There isn't much solace in thinking "I did what the requirements said to do," when a company goes out of business and you need to look for another job.

Answer 5

Tough call, and completely subjective.

Even if your users are "misguided" you have to empower them to set their own priorities and dictate features. Of course you hold their hand as much as applicable and guide them, but you are an advisor, not a dictator.

I would ask "Why" only insomuch as it helps flesh out the requirements or allows you to do the hand holding.

In the end, if the users don't feel like they are controlling the design and use cases, they will disengage and your odds of wasting your time just went through the roof.

Ernie

Answer 6

For me, "why" is in the core of the requirements. If we don't know why we want something, then why have the requirement in the first place? Without the why we loose sight of what we are actually trying to create. On the other hand, if you can tell why for every requirement, you can check if all of them are necessary and help achieve the business case.

Even though situations can change, the business case is the be-all in a project. Requirements should support this. And the "why" is often if not always, at least for the core requirements (e.g. ones that are not derived from other requirements) the way to check if our requirements meet the business case.

So I very much want to know to avoid feature creep and other unwanted side-effects. I feel it my duty to scrutinize what I'm supposed to do even if I'm not required to. I don't regard myself just as someone paid to code something but to use my expertise to improve the product.

Answer 7

You should always be concerned about the "why" to some degree. The amount will depend on your role and the point you are in the development cycle. However, it always pays to ask the "why" questions if you're unsure about any part of the project.

In the past I've found that the more specific the customer is about wanting the software to work a certain way or have a certain option, the more important it is to get to the real reasons they want it.

If you can't get to the real requirements then any software you produce is going to be frustrating to use and potentially useless to the customer.

Answer 8

I think that if you see something that seems wrong and could be improved, you should always bring it up. You figure either it will

1. Be accepted - project wins, you look good
2. Be rejected because they are wrong and stubborn - this is basically no worse than where you started
3. Be rejected because you were wrong - so now you've learned something that will give you a better insight into the company

Answer 9

I agree with Makis on this one. I think in some cases I tend to care more about the "why" than is healthy sometimes. Sometimes I get too wrapped up in the "why" of a requirement to the point where my personal opinions get in the way, so I think there should be some limits as to how far the "why" of a story is considered. Context is certainly important, and the reasoning is also important. But I've been burned before by getting too deep into why a particular feature or requirement is needed that the whole team has lost track of the core of the story.

So yes, the "why" is just as important as the "how", IMO. Just don't take it too far. :)

Answer 10

Do you take the stance that you will code anything as long as the requirements are clear? Or do you tend to resist some requirements or suggestions that you feel are not worthy?

I'm going to be the contrarian in this this thread and really assert that "being an excellent programmer" and "being an excellent visionary" are usually not interchangeable: most people are strong in one area at the expense of the other.

As much as ever programmer wants to be a hero, its important to take a reality pill and understand that your job is to churn out code. Its almost always the case that programmers are outsiders who do not have domain specific knowledge of the business they work in (especially for the vast majority of us who write line-of-business apps for a living), and it would really be a miracle if they could confidently guide a company to make correct business decisions.

That being said, there are only a few instances where I've really fought requirements:

• Scope creep: PM wants to cram in a new set of requirements 2 days before deployment.
• Micromanagement: had a client tell me what he wanted his product to do, where the requirements actually contained snippets of a very amateurish database schema. Another client wanted their entire website and database written in XML and XSLT because they heard it was really enterprisey.
• Really really bad idea: another client insisted on receiving an email each time one of their products changed. I commented that products are changed in bulk (on the order of 10s of 1000s at a time) no more than three times a year, so this functionality would end up spamming a mailbox instead of being useful.
• Second system effect: client asked me to write a product which allows people to send messages to one another over the internet, schedule meetings, organize messages into folders, etc. So I asked "oh, so you want to work like Outlook?" And without a pause or any feeling of irony, he responded "Yes, exactly like Outlook."
• Too vague: happens all the time.

Answer 11

It really depends on your situation. In my situation, leading a team of developers in a business environment, I am often called upon by the business to be somewhat of a process czar since my team works with all facets of the business. It is up to us to identify how changes in one system space impact users in other spaces, since even though one business unit may be responsible for some data other units may use that data.

So in my situation, the why is very important. Not only for the reason above, but because we consult with the business, not deliver.

If your corporate culture/situation is to take specs from the business and just perform them, then the why isn't as important. I still recommend raising any concerns you might come across but be careful not to be argumentative or be seen as a roadblock to getting things done. There are constructive and destructive ways to get to the why. I'm sure some people on this site have worked with people that would rather sit around and argue everything to death instead of getting work done. You don't want to be that person. :)

Answer 12

learn how to get your users/stakeholders to say no to their demands.

each expressed requirement should be subjected to a risk/reward analysis

if that analysis says the development will take longer, cost more, be more expensive to maintain, etc

and the ROI is minimal, non-existent or "it makes us feel good" or "we may need it someday", makes our system less secure, etc

more often than not the money people will put a stake in its heart for you.

each requirement should have a risk analysis attached.

Answer 13

Someone once said, "He who knows how is a good employee. He who knows why is his boss."

While that may not always be true, it's pretty good advice, and certainly something to think about.

I've never been satisfied with just doing something because so-and-so said so. If you can't explain why we're doing something, it smacks of something that someone just yanked out of their posterior. Give me a good, solid reason for doing it. And "we've always done it that way" just won't cut it. Neither will "it's a best practice." A best practice for whom? Just because ABC Corp. thinks it's great doesn't mean it will work here at XYZ Inc.

Every task needs to be thought through. Knowing why you're doing something is the only way you're going to be able to challenge a bad idea and nip it in the bud before it gets out of hand and costs the company a fortune.

Yeah. It's about Risk Management.

Answer 14

I thinking asking why doesn't mean you don't intend to do it if you disagree with the why. Certainly there are times when the customer wants what he wants and no amount of discussion will chagne his mind and you have to do it that way if you want to keep his business.

But if you don't ask why especially when something seems odd to you, then you may miss part of what you need to know to make the project a success. Sometimes the reason is based in contract law or some other esoteric field and while there may be a more efficient way to do it without that consideration, the company needs to ensure the law is met. Sometimes when they tell you why, you may be able to identify some other affected areas no one thought about and thus give a more correct solution. For instance, we have a project right now where we have to exclude people in some particular states due to some laws that are different in those states from an analysis of where to hold a group of events. If you just did it for that project without knowing that these type of events cannot ever be carried on in that state, then you may fix that one report, but not prevent the application from selecting one of those states as a location at a later time. Then you wouldn't comply with the law in another part of your application.

As long as you ask the why respectfully and not confrontationally(not "why on earth would you want to do that?" but "I just want to be sure that I understand exactly why we are doing this so that I don't make a mistake and the project will meet your real needs") then it would a rare person who would object to the question. The person may not know the answer though.