ASP.NET Security Consultant

I'm an author, speaker, and generally a the-way-we've-always-done-it-sucks security guy who specializes in web technologies and ASP.NET.

I'm a bit of a health nut too, having lost 50 pounds in 2019 and 2020. Check out my blog for weight loss tips!

When it comes to software, yes you can. But should you?

Published on: 2014-04-20

One of the great things about being in the business of creating custom software is that I can generally make whatever is needed in order to solve a business problem. Need a system that consolidates previously separate systems into one to simplify cross-departmental communications? Been there. Need a system which allows you to increase product quality by enforcing some standards? Done that. Need software to improve employee morale? Well, ok, software has some limits. Software can indirectly help with company morale, but some other things need to happen, too. (That gives me an idea for another blog post....)

But with such a wide range of possibilities, it's easy to fall into the thinking that just because most problems can be helped with software, that one should solve those problems. The reality is, though, that not all problems should be solved, and of those that should, not all of them should be solved now. Here are some common mistakes that I've seen:

Trying to solve every facet of a single problem at once

When I'm trying to solve a problem, I'm rarely blessed with a simple problem with an unambiguous cause. Instead, I'm often faced with complex issues that are related or semi-related to several dozen other issues. The tendency in such situations is for people to want to solve all of the related issues at once. If you're in there fixing one issue, why not fix this other problem while you're at it? Oh, and this is related.... Whenever I've tried, or whenever I've witnessed others trying, to solve everything at once, the problem becomes too overwhelming. Find something. Fix it. Find something else. Fix it. Repeat ad infititum.

Failing to keep the big picture in mind

When you take the find it/fix it mindset too far, you run the risk of creating additional problems. I've seen this most commonly in programmers (including me) trying a bit too hard to be Agile and business leaders focusing too much on solving one particular problem. A good solution, regardless of whether it is implemented with software or not, is designed with the future in mind. Are we going to want to include other systems? Other departments? Will this process need to be repeated? If you have the future in mind, you can anticipate problems and build the solution in such a way so that it can be extended/modified in the future. If not, you will end up with an expensive integration process to build and maintain.

Trying to solve all problems at once

Whenever you are in the process of addressing an issue, there is always a temptation to address other unrelated issues in the company. My experience, though, is that most people (including me) can only accomplish so many goals effectively at once. If you try to spread people too thin, they simply won't be able to concentrate enough on any one solution. Then you run into the situation where you have a seemingly endless number of projects that never get finished. Instead, focus on a small number of important challenges. You've lived this long with the other issues - a few more months won't be so bad.

Trying to solve the hard problems first

Sometimes the most important issues to a company are the ones that are the hardest to solve. When that happens, it is easy to get bogged down in an endless series of discussions that never seem to solve the core issues. In these cases, choosing one particular aspect of the issue to solve can help give you quick wins (which will be important in keeping up morale when things get tough) and can give people an idea how the larger solution will work.

Making super-sized solutions

As I wrote about in an earlier post, programmers in general (and I in particular) have a tendency to create solutions that are more robust than the situation allows. This can include taking the time to automate a process that's done once a year, making an API for a single-use code library, or creating processes, as seen in this comic:

(photo taken from

A co-worker of mine wisely said, "whenever I find myself doing something for the third time, I find a way to automate it". But make sure you wait for that third time.

Trying to shoehorn a solution into a particular software product

It's also important to note the limitations of the software that you are using. Every software product has a list of available features, but most of those have a secret list of features that are badly implemented. (SharePoint is notorious for including these, but that will have to be a different blog post.) If you find yourself in a situation where you discovered that your idea requires a feature to be differently implemented, don't hesitate to reevaluate your solution. If you don't, you'll likely have software that not only works poorly on day one, but it will be expensive to maintain.


Don't fall into one of the above traps. It's easy to think that just because everything can be done, that it should be done. Instead, make sure that you are spending time in the most efficient way possible to make the most from both your time and everyone else's.

This article was originally posted here and may have been edited for clarity.