No, this is not about economics. It is about one of the greatest disappointments Computer Science students often encounter as soon as they graduate and start their professional careers in the software industry.
The good ol’ days
Studying Computer Science is an intellectually challenging endeavor that requires a good deal of passion and perseverance. By the time you finish your studies, you will have gone through a fairly large and diverse set of thought-provoking problems. You will have studied (a) some theory (e.g. Mathematics, Logic, and Probability) (b) some literature about how computers work, (e.g. Compilers, Computer Architecture, Operating Systems) all the way up to (c) advanced applications of Computer Science (e.g. Image Processing) and (d) Software Development (e.g. building web-apps and services).
The moment we start interviewing, one of the greatest frustrations many of us struggle with is the stark difference between the software development industry and college. Nobody seems interested in the vast majority of topics you have studied and the world seems only excited about business apps for some reason. Don’t get me wrong; this is not to say that business applications suck. I am just pointing out that there is a great difference in nature between the problems computer scientists/engineers study and what they end up doing on a daily basis in today’s software market. This difference is so significant that a fresh graduate may start wondering if they really needed a degree in Computer Science to do their job.
What happened?
Let’s take a moment to figure out what is going on. Where has all the beauty of Computer Science gone? Why does the world of software development seem dominated by less interesting problems?
Well, let’s think about some of the software projects you worked on during college. Pick any of them and let’s imagine that you want to start making money out of it. Let’s think about what you need to do in order to start charging people money for using your software.
- We need to make sure the software won’t crash or fail all of sudden while users are using it. Remember, people are paying for it now so you need to make it robust. Let’s add some serious quality assurance work to our to-do list.
- We need to make sure our program is not easy to hack. Depending on the nature of your software, software vulnerabilities may have terrible ramifications on your customers’ confidence in your product. Let’s not get into these gory details. Let’s just add some security best practices and testing to our to-do list.
- What should users of your software do if they encounter errors? Of all people, you know how many things could go wrong when it comes to software applications. Depending on the audience of your software, users will probably need to reach out to someone on the phone or online whenever they need support. OK. We will need to sort out some details here. Who will respond to support requests? How will you gain insight into the issues your customers are running into? I think we have some serious work on our to-do list now.
- How are people going to know about your software in the first place? We need some advertisement at the very least. There are some details to sort out like what the different venues of advertisements are, how much each of them costs, what type of audience is better targeted with each, and how do we get the most value out of the money we put into it?
- How are you going to charge for your software? Is it going to be a one-time purchase? Is it a service that we can sell subscriptions to? How much should you charge? Is it an application that you can release on some software store that takes care of selling, distribution, and billing on your behalf in exchange for a fee or percentage of your sales?
- How much profit are you expected to make after taking care of all these details? How can you cut costs? Is there a way to build a profitable business around it?
It turns out that making money out of software takes a lot more than just writing code and implementing features. We need quality assurance processes to make sure our software is usable and dependable. We need some support mechanism that people could use when they need assistance or run into issues. We need some decent marketing and PR work to make our product known to those who need it and can pay for it. Our to-do list will definitely grow even longer as our software succeeds and starts attracting more users.
This is more or less the situation of software development firms. They have many such work-items to be taken care of on their to-do lists and they require a fair number of employees to accomplish these objectives. Of course they also have to be building something that people will want to pay for. This implies they can’t just work on whatever problem they think is interesting. It has to be monetizable and profitable (but not necessarily fun).
The sum of all fears
This might have cleared things up a bit. Unfortunately though, that’s not the end of it. There are more unpleasant things about making money out of software:
- Legacy
It’s not just code that gets old, but also the tools, technologies, and processes. The more established the product you are working on becomes, the bigger audience it will get and the more risky it will become to make significant changes to it or the way it was built. Ideas like migrating to a new source control system, or a more modern work-item tracking app are likely to be viewed as an unnecessary risk that may pose a threat to the product itself. In some occasions, it may only be a problem of perception and resistance to change. Remember, however, that there is an inverse correlation between the size of any running business and how much agility it can afford. - Complexity
People grow as time goes by and so does software. A simple and straightforward program that does something as basic as sorting may grow very complex as you keep fixing bugs and adding features. This is not to say we should give in to complexity. However, it takes conscious effort and determination to keep any evolving (software) system simple.
As Blaise Pascal once wrote in a letter to a friend:
“I have made this longer than usual because I have not had time to make it shorter”.
It’s not easy, but if you just keep adding more features then you’re guaranteed to end up with a complex system. Some people take the time to reduce complexity. Others don’t and rely on hiring people who are smart and persistent enough to manage the complexity.
- Hubris
Also known as: not-invented-here syndrome. This one is especially true in the case of established corporations that have well known products. It is not uncommon to find resistance to technologies or tools that have not been home-grown, or those that have internal alternatives, even if those alternatives are much worse.
Are we stuck?
No, we’re not. There is a number of things you can do if this is not what you want to do. You can:
- Re-adjust your expectations
Now that you have learned about the differences between college and the industry, start reaching out to friends who are already working in the software market and try to learn about the things they do day-to-day. You will be more informed and you won’t have to suffer the disappointment of unmet expectations. - Work on new things
Whenever you have a choice, try to work on products or features that are entirely new or relatively less established. New software means less legacy and more freedom to choose from modern technologies and tools. It could be more stressful to work on new software that is trying to hit the market as quickly as possible with the highest achievable quality but this is another trade-off you are going to have to consider. - Consider working for small companies, incubation groups, R&D labs, start-ups and the like
There are obvious benefits to working in established software companies. But if you want to maximize your freedom and diversify your experiences, then you should consider working for smaller companies. It may be more stressful and less economically stable but it is a matter of choice. In a start-up, for instance, there is a higher chance for a skilled individual to be influential; any bit of information or skill a start-up employee possesses may make a world of difference to it in terms of money, time, and effort. If you don’t want the risks associated with start-ups, you can consider small to medium companies. Your scope of work, responsibilities, and influence are likely to be greater in a smaller company. You can afford higher agility and flexibility in such settings and it often pays off to a great extent.
Just remember: there is a number of trade-offs to consider when you have to choose between working on big software products maintained by some well-established multinational software house versus working on a smaller product in a smaller company. These trade-offs aren’t only about the code you’re writing or the problem you’re trying to solve or the technologies and tools you’re using day-to-day. They also have to do with your readiness to take risks, the level of financial stability you wish to accomplish, what you want to do with your life (you may not care that much about what you do for work anyways), how fast you want to progress in your career … etc.
The choice is ultimately yours. My hope is that you have become more informed by reading this article. Why don’t you share your own story? Were you disappointed as well when you graduated? How did you deal with it? And what did you end up doing?
Thanks for reading.
