Naresh Jain » Agile FAQs Blog » Managed Chaos » Stop Spoon Feeding your Developers

Stop Spoon Feeding your Developers

I run into a lot of developers who say:

Our biggest problem today is that we don’t get stable, well-defined requirements.

Sure, as a developer even I would like stable, well-defined requirements. But what do these developers mean by requirements?

Detailed Use-cases with Class diagrams and Sequence diagrams. Actual UI Mock-ups and detailed Workflows. Clearly explained Architecture with Sample Code. Set of Test-Cases with Sample Data. Basically a pile of extremely well crafted, up-to-date documents.

When I hear stuff like this, I can’t control myself but ask:

Then, what would you do? Yeah, I mean, what will YOU DO? Can’t I replace you with a program?

Its high time you grow up Kid! Take the freaking ownership. Figure out what is a real user’s/business’ need, build the simplest possible thing that not only works but is also sustainable (maintainable). Of course, its unrealistic to expect one developer to know everything (let it be technology or business or soft skills). That’s exactly why we work in teams. Pull help when you need rather than expecting everything to be served hot to you.

Want Freedom and Growth? It comes with Ownership and Responsibility. Don’t forget to have Fun and Learn new stuff along the way.

Am I not clear yet? Read Who is a Developer?

This entry was posted on Friday, April 30th, 2010 at 2:37 PM and is filed under Agile, Design, Programming. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.

Mital

The point of having all the requirements well defined is for not duplicating the effort of coding. There are many cases where we have to rewrite the code as the requirements has been changed.
If the management is not clear about the requirements then they can coordinate with developer to spike out the problem. I agree that developer has to take responsibilities for owing the product / module which they are coding but there are many cases where they don't have any control over the Business Logic and they keep writing / rewriting the code many times.
In short responsibility of Management can not be delegated fully to the developer. It should be the joint responsibility of both management and developer.
http://blogs.agilefaqs.com Naresh Jain

I agree with you that its a joint responsibility. Its a team work. But expecting that the business rules/requirements should not change is a flawed expectations. Asking for good acceptance criteria or building a thin-slice to get feedback can avoid some of the rework. Bottom line is requirements are not set in stone and some of them will change. We need to embrace that rather than resist it.
Mital

I am with you for the idea of accepting the change. Whenever we are starting of with a new product we don't have complete requirement specified beforehand. The requirements will evolve over time. Though I still prefer the idea of spiking out all possible solutions if neither of them (manager and developer) are sure about the requirements, instead of completing the solution with one of the way and then finding it not working and then duplicating the effort.

Great products can only be developed by a good team work.
Paul Boos

Quick note: on IE7 the wording is running into the border area and is hidden by the border.
Mitch

Planning, Analysis, Design, Implementation and Maintenance.
http://twitter.com/saurabhbanerjee Saurabh Banerjee

Nice Article Naresh! Another common issue I encounter with a lot of developers is that they tend to think that their responsibility is over as soon as they check in their code in the version control system. I also see a lot of developers shy away from fixing/refactoring poorly written code because they focus narrowly on their specific Sprint tasks. The code base as a whole decays over time.

Overall, I think all these are manifestations of lack of commitment/motivatioon.
eddyyoung

We have a developer who thinks our development process is 'totally bad' until he gets these 'ultimate requirements' this article talked about. He's -so- wrong.

On the other hand there are managers who think a mere 'wish' as-in “I want you to build me a medical support application”, can pass as a requirement. They are very wrong too.

As usual, the truth is somewhere in the middle; a reasonable set of requirements which are a little more detailed than a 'wish', but not so detailed that it's actually the code in another form.
http://compilefailcry.blogspot.com Jose Fernandez

I agree completely. When I worked at a help desk the concept of taking ownership was one of the first things they taught us. I always thought that was a valuable lesson and I apply it to every facet of my life, especially development.
lucisferre

Sorry, I'm gonna call strawman here. I can't think of very many developers who expect to get those types of things given to them. However detailed use-cases, sensible business requirements and properly written user stories are what I hear most developers asking for. That and communication and feedback with the sources of those requirements to ensure that all important 200% communication and agreement on said requirements.

Sadly, I feel all you've done with this post here, is given lazy managers an excuse to ignore developers who may be expressing legitimate concerns with broken communication processes.
http://twitter.com/jigarshah Jigar Shah

I share your pain too..!! But sometimes its better to understand requirement our self and convey to them. Else we keep wasting time in fixing “Their” interpretation. Sometimes…
http://twitter.com/jigarshah Jigar Shah

I share your pain too..!! But sometimes its better to understand requirement our self and convey to them. Else we keep wasting time in fixing “Their” interpretation. Sometimes…