Should a developer argue against unnecessary or harmful features?

Question

What is a good attitude from developers when discussing new features, and namely, non critical/questionable features?

Say you are developing some sort of Java like language, and the boss says: "We need pointers so that developers could fiddle with object memory directly!"

Should the developer shoot down the idea because it adds unimaginable complexity and security vulnerabilities, or should he do what's asked?

This may not be a good example, but what about things that are more in a gray area, like adding buttons that break workflow, or goes against internal structure of the program, etc.?

What is the optimal "can do" vs. "can't do" distribution for a regular programmer?

EDIT: The question is not about a bad boss :D

I was more interested how do people approach new problems that add a noticeable amount of problems while maybe being marginally useful.

Should the general attitude be:

1. yes we'll do it, screw the complexity
2. maybe
3. no, the general rework, and implications don't justify the change

What should be the reaction of a good developer?

Answer 1

Best thing is to have a meeting and lay out the pros and cons as a group, and based on that discuss the best solution. If you have a team, get them to agree on solution. Once a team agrees on something, managers and "bosses" tend to go with the solution.

If your boss still does not agree, then you've done all you can do: you've gotten your team and managers together and covered the pros and cons and despite that your boss chose a potentially inferior solution.

The key to this is discussing the pros and cons as a group. By doing so you are discussing what the best solution is with your team, and at the same time are pointing out your boss's decision (before he makes it) without the political backlash of going around after the fact telling people why you think your bosses decision was the wrong one.

This is a tender situation involving work politics, but it can be handled amicably.

Answer 2

If your boss tells you to do stupid tasks, then you should (kindly) explain why it is stupid.

If he or she does not get the point, then you are obligated to do stupid things. That's it. He's the boss. In such case you can just do what he/she says, or talk to his/her boss or change the job.

Answer 3

You could tell the boss that while it's technically possible, it will cost X amount in time and money spent on effort on analysis, design, to rewrite existing code, testing, regression testing, ... And then ask if the feature is worth it. Sometimes the answer will be "yes! we must have this!", sometimes it will be "no, I guess not".

If the feature being asked for violates some core principle of the application (such as "Add a blue button!" to a UI that is spec'd and designed to only have red buttons as per the customer's request) then I think it is OK to ask "Why?" and mention that it goes against the pre-established design.

In the end, almost everything is a "can do" (it may not not hard from a technical point of view to add a red button to a blue-only UI), it's more a question of "should do?"

---

To answer your edited question, I think the answer should be #2, "Maybe", pending further investigation and analysis.

You don't want to answer #1 "Yes, unconditionally" because you could get stuck committing to something you're not capable of delivering in the given timeframe.

You don't want to answer #3 "No, it's too much work" because then it looks like you are being uncooperative and needlessly difficult.

Answer 4

From the perspective of a developer: NEVER tell anybody paying the bills that they can't have what they want. Instead, you may tell them they can't have it for that price, or that they can't have it exactly the way they originally conceived it.

To your "pointer" example; .NET, a managed-code environment, has pointers. They are critically necessary for a lot of interoperability with unmanaged code. However, "safe" use of them is tightly regulated, and if used in "unsafe" code, that code requires higher security permissions in the runtime. If you were developing a managed language that also required direct memory access via pointers, you could come up with a similar scheme of marshalling behind the scenes where you could, using read-only managed pointers where you couldn't automatically marshal, and allowing "true" pointers only in the most trusted areas of the codebase.

To your GUI examples: if you know that a new feature will "break" the current flow of code, then you can test for that and develop it more robustly to roll back any previous work done by the workflow. Your clients, and sometimes even your manager, usually have no clue or interest in the structure of the program; if something they want is difficult because of the way you structured the program, then by definition the structure is wrong because it does not allow you to do what the client wants.

In all cases, this new feature may increase the scope of work required beyond what the client had thought it would be. That will in turn require either an extension to the schedule, more money, and/or a reduction of other planned work.

However, if you know a way to achieve the same basic result in an easier or more logical way, then that can be suggested to the client. Although they definitely do exist, I fortunately have yet to see a client that refused categorically to listen to input from developers, especially in an Agile environment where there's a "product owner" whose sole job is to liase with development on various needed details such as these.

Answer 5

If you spend many years programming for large applications, and think critically about it along the way, you will develop a finely tuned sense of when a feature is going to cause problems that outweigh its usefulness. Another word for this is wisdom, and just as is the case with other kinds of wisdom, it can be a challenge to make those without it see its value.

Other posters have argued that you should try to quantify the cost of the problem that will be introduced by a problematic feature, and that is a good idea when it is possible, but usually it is not. It is usually only possible to estimate immediate implementation costs. Even that is often difficult for larger features. As for the future costs, you are in a tough spot. You don't know with certainty what other features will be required, or how long the product will be under maintenance. The cost will usually be much higher than you could back up with an estimate based on hard facts.

The more competence you have demonstrated in the past, the more leeway you will have to simply declare a feature a bad idea. That can only come with time and a demonstrated record of success. That said, you should always express eagerness to fulfill the request, since it is what your client wants. You should express reservations based on your experience, and once you have, it becomes a non-issue in 90% of cases because you will start a conversation that gets to the root of the issue, which is: Why have they asked you to add this feature in the first place? At that point you can offer alternatives, or perhaps agree that although the requested feature will introduce problems, it is still necessary.

Of course it is also possible that you are just wrong. Isn't software engineering fun?

Answer 6

Since the question is pretty vague, i'm gonna generalize a bit with my response.

Always question them, but listen to their reasoning. Sometimes, people just forget about the practicality of a feature or how long programming it would take. On the flip side, we sometimes get locked into a programmer mentality of being efficient/no frills/etc and we forget that what we consider as non-essential for a project really isn't for the client.

If they have a good reason, then let them know how long it would take to program it and all the possible bumps that you'll run into during implementation and see if they will still want to proceed with it. Otherwise, state why you don't think that it's a good idea and see what their reaction is. Rinse and repeat.

Answer 7

Most is already said, but there is one thing I would emphasize in my current work environment. I work for a company that is a contractor for other companies and out applications are business process related ( to a fair amount they drive sales and customer communication ).

Business processes along with the accompanying products can be ( at least if the company is big enough ) very complex. To a certain degree, if you are modelling a complex thing, the resulting application will have a relating complexity. As most individuals of the business people only see their part of the process the complete application/process builds on a greater complexity than what is visible to just one user.

My point is, that when a new business requirement arises, it will work for the business people, because it doesn't raise the complexity much higher, but may have a greater impact on the whole system. In my opinion this is not a reason to argue against that change. It is the right point to discuss the efforts ( and the expenses ) with the customer. It probably won't stop the customer to have that feature build, but by time they will gain a feeling for the applications and some discussions about "uuh, you're that expensive!" will be much less picky.

I do not know whether you are in a comparable situation, but I have learned that the stakeholder's situation doesn't necessarily has the same complexity raise imminent like the one that developers and architects of the IT system face. In that situation communication helps both sides.

Answer 8

Excuse me, but this question sounds like a minor asking for fatherly advice. If this is the case, the good developer will need to embrace these commandments:

• Remain faithful to yourself. If your gut feels uneasy about a feature, voice your concerns audibly. Chances are good that the team is just awaiting an opening.
• Do not try to substitute experience with the rules of thumb of the experienced. To you, every situation is different, every feature is new. This is a plus your seniors don't have.
• Software development isn't exact science, it will never be. Therefore, accumulate wisdom, not behaviour.
• Accept defeat. If the team agrees otherwise, do not repeat your concerns ad nauseam.
• Think positive. If the idea is really begging for 'shooting it down', try to find and name positive aspects to it before you list its deficiencies.
• Learn how to interact with people. We developers often place technical knowledge over social competence. The technical abilities peak early in life, but the social competence can keep growing until retirement.

Answer 9

I believe in pushing back bad requirements. But I also believe that when you have given your best shot at explaining why they are bad and they still want them, then you agree and do your job.

For instance, I have had people who want requirements that were mutually exclusive of something the application already does. If I do that, then this will, 100% guaranteed, break. So I send the requirement back and tell them that this will break this other business rule we already have in place and do they want to change this rule too? Often the small group which comes up with a particular requirement doesn't have access to the bigger picture of what the rest of the application may do. Most of the time when I've sent one of these back, the customer has realized that the intial rule was more critical and decided that the change they wanted wasn't worth it. When they have decided to make the change they did it after consulting with the people who pushed the initial requirement.

Sometimes just asking clarification questions will make them see the issue is not as simple as they thought it was. Sometimes you want to ask why they want something and come to the real need that is driving the change. Once you understand that, it is often easier to see an alternatve solution that works for you as the developer and meets their need. If you can present that solution in terms of how it will better meet their need than the orginial suggestion, you have vastly improved your chances of having your change accepted.

Sometimes when a change is going to create havoc at a basic level in your design, just giving them the new estimate of hours the change will take is enough to get it turned off. If you combine that with a risk assessment that points out what critical functionality you might be introducing new bugs into with telling them it will take 6 weeks of dedicated effort by 3 people, suddenly it isn't so important any more.

But sometimes you tell them this isn't a good idea and why and they still say, "Too bad we need it." You win some and you lose some and sometimes the business needs genuinely have changed and the application must accomodate that. Once the decision has been finalized, it is no longer the time to question what you are doing and time to get on with doing it. If you have documented your objections, then you personally should still be in a good place when it goes over budget and causes new and more exciting bugs. And they might even be more willing to listen to you next time when you have built up a track record of being right on these sorts of things.

The key to winning many of these discussions (nobody wins all of them) is first to build up a track record for knowing what you are talking about. Next send a written document that states what concerns you have (many managers are risk adverse, they are more likely to not want someone to have a document that proves them wrong later, so they pay more attention to what you put in writing) and finally to make sure they understand all the costs (not just hours, but security risks, introducing new bugs, missing deadlines, etc.) of making the change. Change is not free and they need to understand that. The next key is to do this like an adult and not like a whining child ("but I don't wanna use ... because I don't like it"). Make a business case for not doing it and you will get a lot farther in pushing back a bad requirement.

Answer 10

If I read you correctly, the real question is about unknown complexity. Initially I read your question as, "I see the extremely likely risk of excess complexity but the boss doesn't" But you're saying that the boss isn't a problem, so I take it you're not sure what the risks of adding unacceptable complexity are.

In that case, I'd recommend some sort of risk mitigating strategy. Image you're considering adding WCF/web services to your API, which could be awesome or a lot of complexity without reward:

• add the feature on a branch. If it works, merge it. If it turns into a rats nest, kill it.
• fire up a new one page project and do a proof of concept. If you can't do a proof of concept in a short time, then drop it. If the proof of concept works, make it bigger and integrate it with your
• scour the web for people griping about that feature or technology. Where there there is a lot of griping going on, a technology might be some real risks of excessive complexity. Java Beans and COM+ are probably, old, but good examples of features that really jacked up the complexity and may or may not have delivered on the benefits side of the equation

Answer 11

Argue no. Discuss possibly yes. But it should be treated as an addition to the spec and prioritized with other features. If you know that the request will add an unreasonable amount of time and complexity to implement then state that up front. Not as opposition to doing the request, just as an explanation of what you think it will take to implement.

It does very much depend on the request. Pointer implementation is big enough to effect an entire project so its merits should be weighed if given a choice.

Implementing a button that breaks the flow. Maybe not such a big deal if the form can be laid out in a way that the button is optional. I have done this very thing in fact. I added the button but also collected enough information before hand that the button became optional. Users who expected it to be there used it and those who realized it was just redundant didn't.

It's all about balance and knowing when to pick your battles. Some things are easier to just implement anyway versus dealing with the social aspects of not including it.

Answer 12

The problem I see is your use of the word argue.

You must bring up design issues and the reasoning behind them, but be wary because programmers have a tendency to get defensive about positions they have taken and argue points just for the sake of arguing (Sometimes). I have to stop myself from arguing quite a bit--and I don't always succeed. Also as I get older I find I'm wrong more often than I used to be--or worse I didn't recognize how often I used to be wrong :)

If you have clearly stated requirements (the language must be safe, we need pointers to access legacy routines) then you could present how the two requirements conflict and ask which is more important. Once you have the requirements and the reasons behind them you may even be able to come up with a completely different solution that supports both requirements (JNI--kinda).

If it doesn't, well perhaps it's a good time to codify them!

Answer 13

1. Realize that you do not know everything and cannot do everything.

2. If you are sure that it is a bad idea then, say what's bad.

3. If they try to push it on you, say either - Need more time to analyze, if you need more time or say that we haven't found a good solution to this problem.

4. If they still insist on implementing the bad idea, get an acknowledgment from them that you have advised against it including your reasons. You may even send out an email summarizing the discussion with a copy to your manager. This might save your a** later.

Answer 14

In an ideal scenario you'd have a Lead Developer that makes final decisions on the technical side and a Business Lead that makes final decisions on the business side. This would answer the two main questions:

1) What? What does the customer want?

2) How? How do we accomplish this from a technology perspective.

What the customer wants is the ultimate decision maker as they are the ones who pay the bills

Answer 15

As a developer, you shouldn't really care which requirements are requested to be implemented.

However, you should explain if something is unrealistic and if there are better ways.

Answer 16

Sometimes its actualy customer request (comming from customer internall politics). Then its hopeless and must be done (but management should also consider whether continue such project or whether should they renegotiate price.)

Answer 17

This is almost a day to day task for me, and in fact I'm glad it is.

If you have the change to give your opinion on whether certain requirement should or should not be part of the application, non technical persons will expect you to fill in with your technical knowledge (e.g. "using pointers would make the application unstable" or "using a GET parameter for X purpose is a security risk"). Technical fellows would also appreciate your feedback on some specific advantage or disavantage they may not have thought about.

Of course, it is harsh when everyone wants feature X and you end up saying "it may not be good", but in the end, everyone is trying to make a secure, robust and stable application (maintainable, flexible, etc...) and every voice should count.

Answering your question, its not part of the job of a developer (which is, to develop), but it is an "extra" that delivers quality and team work.

Answer 18

If you are in the position to understand the cons of doing it (complexity, lack of usability, etc.), then it is in everyone's best interest for you to explain it to the best of your ability. Often non-developers do not understand the problems of adding new features. It's easy for them because they don't have to do anything or even think about it.

However, if the powers that be decide that the new feature is going to be added, then you should do the best job possible. It's a challenge.

And, if the new feature is too stupid or the working environment too crappy, then it's time to find another job.