have you faced this problem?

[J radolf]

Hi guys and girls.

am suffering from a strange problem the software company am working in never tells the requirements properly but still tells me to code something without telling the requirements properly.

can you share your experiences in your workplace if you dont mind??

please dont delete this topic.

because after working for seven months in this company am feeling demotivated.

[Devaka Cooray]

J radolf wrote:but still tells me to code something without telling the requirements

So why do you feel that this is bad? According to this, you can do anything as you wish.

[Jason Cohen]

When you say "expects me to code something," what are the exact instructions they give?

If you can convince them to give you instructions in writing, perhaps that would illuminate the problem. That is, when you deliver something that they claim they didn't want, you have something physical that you can use to compare against.

If they won't provide it in writing, YOU can write it up anyway! Email them with it and say "This is what I heard. Please correct it." Then you can still use it as a foil.

Then when you have clear physical evidence that what they ask for is either incorrect or incomplete, you now have the ability to say "I'd like to fix this next time so we don't both waste our time."

[arulk pillai]

It is very normal to have gaps in requirements, etc, but don't you have a requirements or specification document to start off with? Did you talk to your fellow team members? How do they feel?

[Sai Surya]

... still tells me to code something without telling the requirements properly.

Perhaps you can derive requirements from this 'something' and confirm from your team lead or manager. For instance, if they ask you to write a Java class to get JDBC connection to Oracle and store some record, this means that the requirment is to get data from user as a web form and storing in database and finally showing an acknowledgment message to user.

I had undergone this type of problems, believe me, you cannot fight/argue all the time with them. So have positive attitude. If you are not clear ask your people to tell you the requirement.

Moreover, they are helping you by giving direct instructions to code or else you need to put more effort to derive requirements.

[Kj Reddy]

This is a common problem many projects facing. We can define ourself what is the requirement what is the scope and out of scope of the implementation.
Even though we will write everything clearly there will be communication gap but it can be minimized by different ways like developing prototype.

[VineetK Singh]

It's better than the case we are facing. Develop something and then the requirements drastically change and we end up doing lots of rework.

[Tim Holloway]

A sign often found in American offices: "I think I am a mushroom - they keep me in the dark and feed me bull***". I don't doubt that that saying is considerably older than I am, and for that matter, than IT itself.

On the other hand, IT suffers from what I call the "All You Have to Do Is..." syndrome. Any time a boss or user starts out with this phrase, you should immediately scream and run for the exit. If you catch yourself saying it, you should immediately punch yourself in the face.

Only idiots and ideologues think that problems have simple solutions. In the real world, everything has "gotchas", some foreseeable, some not. "Known unknowns and unknown unknowns", if you like. This is true of processes in general, but especially in IT, since computers are totally incapable of understanding "All You Have to Do" and must be instructed minutely and in detail. Expect everything to take at least 3 times the "All You Have to Do" estimate in time and effort, and if you're lucky, it will only take 5 times as much.

To a certain degree, it's a part of your job - and one you almost certainly weren't trained in at university - to extrapolate and intuit the missing parts of the assigned task. This can be especially challenging for those raised in the Asian culture where initiative traditionally comes from above.

On the other hand, for a number of reasons there simply may not be enough information available. In this case, you've got your work cut out for you. You'll need to determine how to obtain the missing info, and that may be a political process as much (or more) than a technical one. And, of course, nobody may actually know, indicating that further study is needed.

[arulk pillai]

Well said Tim.


What is the big deal in being a Java guru if one can’t understand how the business works and how one can enhance value? The more you know about your business the more you will be able to contribute in project and team meetings, and consequently make an impression.

If you don't want to get stuck behind the keyboard the whole day, you must understand the short and long term goals of the business, so that you can devise tactical and strategical solutions. Also, technical people need to understand the company’s products and services, who the target customers are, and how these products and services are used. Having a good understanding of “whys” behind a project can help you figure out the “hows” much easier.

In fact many don't get this vital opportunity to liase with the multi-disciplinary teams as project managers, business anaylsts, team leads, and/or architects perform this pivotal role. It is a real opportunity to make your mark as a well-rounded developer with potential opportunities to go places. Take this opportunity to prove your-self as a great contributor not just a techie. Not many get these opportunities.

-- Organize meetings and invite the relevant people and start gathering the requirements, analysing the potential gaps, and devising solutions .
-- Start building a good rapport with your business and customers.
-- Make a number of phone calls and send emails to verify the requirements, identify the gaps, etc.
-- Take the intiative to document them yourslef.

[Sandeep Awasthi]

Well said Tim

And I liked this

"All You Have to Do Is..."

[Collin Dugas]

Yes, this is frustrating.

I have three years of experience in J2EE and was recently told to work on enhancement (Release 2) of an web application based on spring. After a couple of months into the project and design I am told that the a part of it was designed in .NET and all our work is going to happen in that. I was so shocked that I could reply. I think those guys are just senseless to make a J2EE exp person lead a .NET project.

Sometimes I wonder with time if the software, architecture ,etc.. improve why doesnt this aspect improve??

[Campbell Ritchie]

"Anonymous" please read the important administrative private message I just sent you.

[Bear Bibeault]

"milo minderbinder", please see my private message immediately.

[Tim Holloway]

Rajesh Thakare wrote:Well said Tim

And I liked this

"All You Have to Do Is..."

It got drilled into me when I worked for a group that was seriously lacking in original expression. They never said "certainly", "definitely", "correct", or even "you betcha". It was always "Absolutely". Got on my nerves. They also said "All you have to do" a lot, and it's what got me thinking on the topic.

The warning signs, if I'd been observant got way back, though. One guy I used to work for was jokingly referred to by his "finger waggles". Something like every time he waggled his fingers when he described how easy a project was, you should tack on another 3 weeks to how long it was really going to take, so the story went.

The sad truth, however, is that it isn't just users who suffer from "All You Have to Do". Programmers, it has been observed, are optimists. They're almost as shortsighted as users in estimating how much real effort a project will take, and with less excuse. It only makes it worse that these days it's virtually impossible to assert any timeframe longer than the user wants to hear, based on their "All You Have to Do" conceit about the project requirements. But I'm convinced that this is one of the key reasons why computer people don't get no respect these days: a consistent failure to deliver stuff even to the precision you'd expect for a contractor on a public works project. Or, in the case of far too many software projects, to deliver a usable product at all.

Speaking of lousy software products, I just got a bill from a company far too large to be doing this kind of stuff. Fortune 50, give or take. It's amazing that I got it at all and it's a tribute to the oft-maligned US Postal Service that I did. There's virtually no address on it. Even allowing for sloppy data entry, this kind of garbage should never have made it into the database.

[Sandeep Awasthi]

I had came across "All You Have to Do Is...". When requirements change, these people first tell what requirements are changed and without you asking (or expecting ) them to give you solution they will give you solutions just in a minute starting with "All You Have to Do Is..."
Few common way they say is :
Everything is same, only instead of X, Now it is Y, so "All You Have to Do Is..."
Everything is same, only this part is removed now, so "All You Have to Do Is..."
Everything is same, only this part is added now, so "All You Have to Do Is..."

[Tim Holloway]

Rajesh Thakare wrote:I had came across "All You Have to Do Is...". When requirements change, these people first tell what requirements are changed and without you asking (or expecting ) them to give you solution they will give you solutions just in a minute starting with "All You Have to Do Is..."
Few common way they say is :
Everything is same, only instead of X, Now it is Y, so "All You Have to Do Is..."
Everything is same, only this part is removed now, so "All You Have to Do Is..."
Everything is same, only this part is added now, so "All You Have to Do Is..."

Stop! Stop! Stop! You're giving me flashbacks! Aiieeee!

[Damodar Mukhopadhyay]

I think this is very normal and common to the companies...
This is one of the main reason why people change company...
The same thing happened with me
First time I was frustrated but later on I decided to do well in my new project... and I did...
Again I came back to my love (i.e JAVA) and my previous experience now helping me a lot.
I learnt new languages, technology etc... and I enjoyed it..
Later if you will be Boss it will help you a lot...

Never worry... Cheers

[Sandeep Awasthi]

Stop! Stop! Stop! You're giving me flashbacks! Aiieeee!

[Andy Lester]

Sandeep Sa wrote:Everything is same, only instead of X, Now it is Y, so "All You Have to Do Is..."

For me, that's called "Can't You Just..."

[Hong Anderson]

If requirements are not clear, make it clear. If anything missing, make it available. It's our jobs.

[Sandeep Awasthi]

Kengkaj Sathianpantarit wrote:If requirements are not clear, make it clear. If anything missing, make it available. It's our jobs.

It's not if requirements not clear and we work on assumptions.

It is about requirements were very clear but they are changed now and they changed again and again .....

[Hong Anderson]

Sandeep Sa wrote:
It is about requirements were very clear but they are changed now and they changed again and again .....

I recommend to study Domain-Driven Design. You'll not fear change anymore.

The problem is designing base-on requirements is not a correct way, because requirements can change (and they will change), requirements might be wrong, who gives requirements doesn't understand what he is talking about, etc.

But if we design based on Domain, even if the requirements change, it would be not difficult to implement.

[Sandeep Awasthi]

Requirements do change this is why agile, scrum have become so popular.
We were just sharing our experiences when they change.

[Sandeep Awasthi]

Andy Lester wrote:

For me, that's called "Can't You Just..."

One more sentence I will fear now

[ankur rathi]

Tim Holloway wrote:
Only idiots and ideologues think that problems have simple solutions.

I think that way.
If you know each and every bit of "context", it's simple for you.

[Tim Holloway]

Kengkaj Sathianpantarit wrote:

Sandeep Sa wrote:
It is about requirements were very clear but they are changed now and they changed again and again .....

I recommend to study Domain-Driven Design. You'll not fear change anymore.

The problem is designing base-on requirements is not a correct way, because requirements can change (and they will change), requirements might be wrong, who gives requirements doesn't understand what he is talking about, etc.

But if we design based on Domain, even if the requirements change, it would be not difficult to implement.

Because "All We'll Have To Do Is...."

I've been doing "Agile" for far longer than Agile has been formally recognized. I learned very early in my career that when I hand someone a piece of software that it will change how they do their job (after all, that's what it was for!), but it will then suggest new and unanticipated ways to do things. So I design in the abstract, even though I then get static because I didn't just "Git 'R Dun!".

But the AYHTDI attitude has little to do with abstractions or agility. It has everything to do with an oversimplified attitude towards the work that needs to be done.

A good approach can make the work easier, but it's still going to be work. Both users and designers/developers/managers consistently refuse to recognize how much work that is.

[Hong Anderson]

Tim Holloway wrote:
Because "All We'll Have To Do Is...."

I just don't care that. I'll do only what is right.

[Sandeep Awasthi]

Kengkaj Sathianpantarit wrote:
I just don't care that. I'll do only what is right.

I think you haven't understood what Tim is saying. This All you have to do ............ is solutions given by the people who think every problem or change has very simple solutions. Developers always ignore those solutions.

[César Guzmán]

I think we all have experienced problems with specification, on bank industry usually happens, and it's a real problem when talking about money, but what always works is talking with your stakeholders to know what they really want, ask them to solve your doubts, do what they want and then, ask them to update the specification documents.

[Hong Anderson]

Sandeep Sa wrote:

Kengkaj Sathianpantarit wrote:
I just don't care that. I'll do only what is right.

I think you haven't understood what Tim is saying. This All you have to do ............ is solutions given by the people who think every problem or change has very simple solutions. Developers always ignore those solutions.

I understand, don't worry .

[Jay V. Gangawane]

my 2 cents .. mostly in line with replies that have been posted above ..
If you are working on something that's about to be started from scratch, prepare some document such as Fuctional Specification.
Send it for review and approval to your senior manager or your even to the person you are reporting to.
That way we can document and keep on updating the requirements and assumptions clearly.

Also after any such meetings or discussions where the requirements are discussed, its always beneficial to send out the minutes of meeting (MOM) to all the concerned persons.
P.S. this looks quite a natural and simple thing to do, but can help at later stage when anyone suddenly asks when was this decided!