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 develop an internal business application that our engineers use to test and debug the company's product. The engineering manager has been pushing to get the software developers involved when the engineers are in their design phase. He says that he wants to give us an idea of what's coming down the pipe, and give us the opportunity to provide feedback on their designs (we rarely have feedback).

The engineering manager wants the developers and engineers to implement new features simultaneously, so that by the time the engineers have implemented their end, they can use the software to test them. The feature designs tend to be volatile until they are fully implemented by the engineers, making it difficult to draw up requirements. He thinks the engineers and developers can do all of our debugging side-by-side, at integration time.

It all seems inefficient and backwards to me.

share|improve this question
It's too early when you don't have all of the requirements. However, that doesn't seem to stop management from having developers start anyway. –  Bernard Jan 18 '12 at 15:15
@Bernard My situation exactly –  M. Dudley Jan 18 '12 at 15:25
@Bernard: You never have all the requirements - not even when you go live. –  sleske Jan 18 '12 at 15:41
@sleske: Exactly. I find that to be quite problematic. –  Bernard Jan 18 '12 at 16:31
add comment

4 Answers

up vote 5 down vote accepted

There's no general rule, it's always a tradeoff.

  • On the one hand, involving SW engineers early may mean a lot of wasted work for them, because they discuss and think about problems that turn out to be irrelevant.
  • On the other hand, involving SW engineers early allows them to give feedback about the relative complexity of the desired functionality, and about possible problems. This may save the other engineers a lot of time, because they can change their plans early to avoid problems later when the software is being developed.

At what point exactly to involve SW devs depends on how you want to make that tradeoff (e.g. how likely is it that engineering will make design decisions that later make life hard for the SW devs; how likely is it that SW devs can help the engineers; how important is it to minimize risk in the project, even if it means higher overall cost).

That is very much a project-specific decision (and a difficult one).


The question really boils down to "Should SW devs be involved in the requirements design?". In my experience, some (limited) involvement is very valuable even early on, as it avoids totally unrealistic requirements.

Basically, requirements design is about "getting the most bang for the buck": Identify features that are as useful as possbile, but also as easy/cheap/fast to implement as possible.

Domain experts know what is useful, SW devs know what's easy to implement. You need both pieces of information to decide which features are worth considering.

share|improve this answer
I think to some extent it depends on the company structure but I agree with the majority of what you have said. In my experience, someone from software definitely helps to keep "pie in the sky" expectations grounded. –  Rig Jan 18 '12 at 17:21
add comment

There is nothing wrong with getting developers involved with the requirements phase if your company can afford it. This doesn't mean that they will start other phases of the development cycle any sooner.

In my experience, it is often invaluable to have a sharp developer involved early in the requirements gathering process as they can help the team avoid any issues that arise based on unsound development assumptions by management/business. However, this could also be a huge waste of the developers time if the requirements phase turns into a weak brainstorming session.

There really is no hard and fast rule to when developers should get involved. I have been on projects where I was brought in too late, only to be brought in too early on the next because they recognized this and tried not to make the same mistake twice. If your company doesn't have strong leadership who can weigh when to bring developers in, there may be many frustrated developers sitting in on "it would be cool if we could..." meetings.

A good project manager should know the right time to get developers involved. This is difficult because the project manager would have to understand both the progress of the requirements, and their own limitations when it comes to their technical understanding. A great project manager will know which developers should be involved at what phase (as some developers are better at the requirements phase than others).

I have yet to see a project that has made it completely through the requirements phase that couldn't have used some input by a developer. If that is happening anywhere, I would like my company to hire those project managers/analysts.

share|improve this answer
add comment

Look at it as a prototyping problem. A prototype is a means of requirements gathering, where the creation of something physical that reflects the current thinking so far can help solidify whether it is what they want, or if there are really more or different requirements.

If the engineers are putting together some basic ideas with the developers on hand, the developers should be able to not only say whether it is feasible, but they should also be able to throw together a prototype that could be the basis for the real application. Taken to its logical extreme, this becomes an incremental, iterative method of design and development, in the vein of the unified process and/or agile.

I'd also point out that the developers SHOULD be giving feedback. How is it that yours don't?

share|improve this answer
We do provide feedback when there is an issue in the product design that impacts our requirements. However we can't always provide feedback on the product design itself because sometimes it's outside our expertise, and sometimes there are design requirements that flow down from business requirements. –  M. Dudley Jan 18 '12 at 18:50
add comment

Ideally it should work this way but this assumes an agreed upon design that doesn't change rapidly during the implementation phase, and that would go for both the engineering disciplines in this case, not just the software related one. They are dependent upon each other in this case.

The situation seems as if the engineers do not have a full grasp of the problem they are trying to solve before designing, or they problem they are trying to solve is well established but they are just not sure how to solve it until they get their hands dirty.

This forum doesn't pertain to non-software related engineering disciplines, however if this were a software design problem, the best way to mitigate this kind of problem is to have the developers begin developing a rough prototype that aims to address as many potential unknowns in the formal design as possible. This way, the formal design can be more complete and the problem's implementation approach can be highly understood.

share|improve this answer
Your second paragraph is accurate. I am trying to figure out how to manage the software development end of the situation, given that I cannot count on solid requirements. –  M. Dudley Jan 18 '12 at 18:53
@emddudley You do not have the technical expertise of the engineers, but your software serves them so they are your users. Your users give you the necessary information for you to formulate the business requirements. They do not have the information you need until they are almost complete, therefore there is nothing that you can realistically do to improve your situation. Until the other engineers adopt better design skills, prototyping, more professional discipline to their approach then the problem will not improve. Certainly you can try suggesting this but you are unqualified to do so. –  maple_shaft Jan 18 '12 at 19:04
I'm in a pickle! –  M. Dudley Jan 18 '12 at 19:31
@emddudley We are all in a perpetual pickle. Good software design and practices is like Libertarianism or Communism. It works theoretically and looks good on paper, but inevitably when it is implemented in the real world the people in charge find ways to fudge everything up. On the plus side, it is job security :) –  maple_shaft Jan 18 '12 at 19:54
add comment

Your Answer


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.