Did you read the title of the post correctly? Am I, a software engineer, really encouraging you to reject writing software solutions? Yes indeed I am. There are times in your career when you’ll need to evaluate if a particular problem really requires writing a new piece of software. Sometimes, you’ll find that a NO is the best answer for everyone.

Why not to write a software solution

Writing a software solution is a huge investment. Plenty of effort, time and money are involved. Clients and software makers often need to commute so that they can work with each other. Meetings and conference timings need to be blocked. Requirements are identified and revised several times. Software architects and developers need to be hired and assigned work. They need to write several revisions of software. A quality team needs to constantly test the revisions for bugs. The software needs to be delivered and installed where the client wants to work with it. The client needs to be trained how to use it. A support team needs to be hired and stay available so that they can help the clients whenever they face problems using the software. And so on and so forth.

After investing so much into a piece of software, if it is found unsuitable for sustained use, then everything will have been a waste. Apart from effort, time and money, it will have been a huge opportunity cost, where everyone involved was actually better off working on something else. Saying NO to a software solution that has no future is actually a smart thing. While it may cause people to raise eyebrows at first, everyone will thank you later.

When to say NO

The rest of the post will teach you when you should say NO to writing new software solution for a problem. I will also give you examples from my career as a software engineering employee and as a freelancer.

Reason 1: Can the main problem be solved by software?

An interior decoration business owner was discussing a problem for managing his inventory. He told me about considerable delays between a client requesting an interior decoration work and the designer team being able to finish that work. After a lot of Q & A, it was clear that the real problem was in ordering and procuring raw materials and shipping them in trucks. It became clear that I could not solve his problem through software, because the actual delay was in building a piece of interior decoration using mechanical tools and shipping it between workshops, go-downs and client’s premises, a logistical and transport problem.

When someone wants a piece of software built, you need to discuss at depth and listen. You may find out that the real problem cannot be solved with software. It is necessary to stop the idea right there.

Reason 2: Can the current system be automated by software?

A company that owns a fleet of trucks approached me to build an app using which one could hire trucks online. Think about it as Uber for trucks. Let’s call them Fleet X. Things became fuzzy when I asked Fleet X for a tariff card, i.e. truck fleets charge the shipper in proportion to the weight of goods and the distance covered. Fleet X’s response was rather bizarre.

Person ‘A’ wanting to ship goods calls Fleet X. Fleet X promises person ‘A’ that they’ll call back in 10 minutes with a price quotation. Fleet X poses as a client and calls 4 to 5 more fleets, say Fleet Y, Fleet Z, etc. to get their prices. Then they take the cheapest of those prices and reduce it by 10%. They call back person ‘A’ and quote this discounted price. Thus a deal is made.

I told them that there was no way to automate the process of posing as a client and undercutting the lowest price just by using software. I wanted a defined tariff card using distance and weight to set up a mathematical formula so that a potential shipper could see what he/she would pay for immediately on the screen rather than having to wait for the fleet company to call back with a price. To this day, despite following up, I haven’t received a tariff card. So I haven’t moved a finger to proceed with the project.

Reason 3: Is it being built because everyone else is building it?

Most apps are built because someone else is doing it. Plenty of people want to cash in on the latest software fad. You can see that the mobile phone app markets are chock full of chat apps, minor social networks, photo sharing apps, camera apps, GPS apps, cloud storage, etc., with nothing to differentiate one from the other. All these apps may be packaged with a different UI and brand, but from the user’s point of view they all do the same thing.

Such software solutions either fail or become stagnant after a while, with no increase in the number of users or no change in usage. Smart business says that the tried and tested ideas work better than an idea which is yet to be tried and accepted by the market. But ‘tried and tested’ doesn’t mean that you simply ape another idea. The market loves a proven idea but with enough innovation that makes that idea much better to use. E.g. glass utensils are exactly the same as metal utensils, but you can see the contents inside at a glance and can use them inside a microwave oven.

Reason 4: Is the client asking the software engineers what to build?

There are some clients who approach software engineers and ask them how they can improve their software solution. In theory, this sounds like a wonderful idea. Software engineers are the ones who stay updated about how technology can be used to build new things that weren’t possible before. Software engineers can often uncover possibilities than non-techie clients haven’t heard about.

There is one problem with that method. Software engineers are specialists at how software works. They may not be the best at suggesting how a client’s solution can be improved for user experience. Fancy technology and shiny new features are good only if they make the solution more convenient to use from the user’s point of view. A software engineer may suggest switching to blockchain or integrating Google Analytics, but do they have a direct impact on the user’s experience?

Here is a better way. The client or the project manager has to think of ways to improve the workflow in a way that impacts the user. While presenting this idea to the engineers, the engineers may come up with ideas to use technology in a way that the client is not familiar with. E.g. a client regularly using iOS but getting an Android app built, may ask the software team how they can make a feature to transfer files to the hard disk of a laptop. The software engineer can quickly point out that Android phones can simply be connected via a wire and accessed like external storage with drag and drop. Or they may suggest a wireless solution like AirDroid.

Reason 5: Is using a fancy technology the main reason to build?

During 2010-11, browsers got a shiny new feature called web sockets. Our CEO read about them on a tech blog. He approached us and asked if we could integrate web sockets into our web-based solution in some way. When we asked him for a reason to use web sockets, he told us that he’d have a reason to update the contents of our home page in a section called ‘Cutting edge technology we use’, which I felt was already jargonistic for a non-techie viewer of the home page.

Similar to the above paragraph, we told him that we did not need to use that feature until we found a way to make it really useful for the user of our software. No user cares what technology is used as long as the solution solves his / her problem.

Reason 6: Can a current solution solve the problem in a pain-free way?

Sometimes it may not be useful to write a software solution from scratch. It is possible that a simple two-sheet Excel spreadsheet will do the trick, especially if there is no repetitive data entry. A solution that delivers latest news to its users doesn’t even need to build a web page to list the news. It can simply deliver news in an email newsletter or as an RSS feed.

Writing solutions for the sake of writing them and over-engineering are problems that waste several days of effort. If existing solutions can achieve what the clients want in less number of clicks or typing, then you can simply put together a solution for the user that uses those solutions. You can either demonstrate to the client or write a documentation on how to use those solutions together. It is perfectly okay for you to charge consultancy or tutorial fees for your guidance. After all, you have delivered a valuable solution to the client and made his/her work easier.

Reason 7 (totally personal): Does it fit your ethics?

While reasons 1 – 6 are important for business, reason 7 is completely my own and I don’t recommend it as a filter that you use every time you are asked to build solutions. I cover it because it is important to me and may be important to some others.

Also note that writing solutions within your realm of ethics is not possible if you are a freelancer with no experience or savings. It is also not possible if your company is cash-strapped. You are better off taking any project that fits the above 6 reasons. You can exercise your ethics once you are financially sound and have built up experience. Even I may relax these ethics during a phase when income is hard to come by.

Here are some software projects I avoid nowadays. I don’t like it if a software solution keeps the user chained to the screen as an addiction. E.g. computer games, fantasy sports, social networks, sensational news, etc. I am not fond of making apps specific to a political party, e.g. an app tailored for BJP or Congress. What’s the opposite? I enjoy making software that encourages and rewards users to work out more and eat healthier. I would enjoy making software that helps the Government of India (regardless of whoever is the ruling political party) track and achieve their lofty goals for billions of people. I also respect software solutions that don’t push notifications to the user when he/she is working and rather sends a digest of updates as an email that the user can see when he/she is ready for it.

Ethics will differ among people, so there is no guideline for it. If you stick to your ethics, it will inevitably cause clashes. E.g. a client will hate your opinion and never come back to you. Your company’s project manager may  fire you from your job if you refuse to participate in a project due to ethical grounds.

Conclusion

Building software solutions usually takes several weeks or even months from a person’s or a team’s software career. It will also determine if a person’s resume shows software that creates real value for its users or just ones that make up the numbers. It is important to choose to use your career wisely. Using the filters from this article, you get to choose what you work on.