BaBSE 6: Knowing When to Say No

Solving problems with systems and software is a tough job. And it gets tougher when you have users dipping their phalanges in the system that you need and want to create for them.

Common things you will hear during the software development process from users are, “yeah, that’s great, but…” or “well, I thought it should work like…”. If you have been developing for any time at all then you are probably accustomed to this behavior.

Don’t hate the player, hate the game

It’s not the user’s fault that they want a billion different things in a new system. They simply want an awesome system to do their job and make their lives easier. But, there is a little term that called feature creep that destroys developers’ lives. This is the idea that as one new feature gets added to a new system, then ideas start flowing and other features are suggested and then “needed” by users.

This is the “game” of defining features for systems. You have to be good at this game to make sure that you don’t design a system that has a million functions, looks amazing on paper, and then will never be developed because it is too much work.


It’s never a bad idea to sit around the table with some users and come up with a bunch of potential features for future systems. This allows everyone to work together and bring their different background and perspectives to light. This is a super important exercise in the software development process and shouldn’t be avoided because you are afraid of feature creep.

But, what tends to happen is that users (and developers) get this idea in their head that all of their good ideas will be put into reality. This is dangerous territory.

So, to make this game better, make sure that when you are brainstorming ideas for systems, that you and everyone else knows that this is a brain dump of ideas, nothing more, nothing less. Don’t say no to particular ideas in the process. Instead, come at it from the perspective that none of these ideas “are the system”. These ideas are just ideas.

Saying no

Saying no to particular features of a potential system is the most important part of developing a system that will actually work. I work in a team of 1 where I work and because of that I have to say “no” a lot. All ideas are great ideas until you look at the details and realize how much work they will actually take to implement.

I can’t remember the exact saying, but it basically goes like this: However long you as a developer thing something will take to create, convert it to the next time unit and multiply it by 2. So, if you think a feature will take 2 hours to implement, you should say that it will take 4 days.

The numbers don’t really matter. The point is that new, awesome features take time and resources to create. If you don’t have the time and resources, then you have to say no to things that aren’t “core” to the system. This can be a painful pill to swallow, especially in a corporate environment where sometimes saying “no” is not an option.

When to say no

So, when can you say no to something? My best advice on this is that the only real time that you can do this is when you have worked with users and stakeholders of the system and identified all of the “potential” features. With that raw information in front of you, you can pick the top 5 features that you have to implement for the system to be the system. Everything else is a no until those 5 features work awesomely well.

The number 5 isn’t necessarily a hard-and-fast rule. The idea is that you are taking a workload of development that by the end of it will produce something that is worth something to your users. Yeah, they may not have all of their amazing, whizz-bang features that they were hoping for, but they have something that is usable. Other features can come later.

So, you have to say no a lot, especially in the beginning of a project or if you are strapped with little resources (raises hand).

Here are some other really great posts/books on this topic. Just remember implementing features is all about what you can handle and get done. After a couple of years you become much more realistic when it comes to timelines and what you can handle as a technologist.

One last thing, if you didn’t make the connection, this saying “no” stuff isn’t just about software development. You can use the idea of creating boundaries and doing just the right amount of stuff when it comes to productivity as well.


Leave a Reply

Your email address will not be published. Required fields are marked *