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 gleefully taken from xkcd.com)
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.
Summary
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.
If you can think of any other common examples of software teams creating something because they can but shouldn't, feel free to add them in the comments below.
No comments:
Post a Comment