The developer syndrome and how (not) to avoid it

OK. Admit it. You have fallen into the trap. I have fallen, too.

Imagine a very typical day in the office: you have to build some hardcore stuff, code complex algorithms or implement demanding business logic. There is a bunch of third-party libraries and tools you can use, paid or free. Such tools can save you time and energy and help you meet your deadline. You could have used a third-party tool and go to bed. But you end up coding the whole project yourself. You keep coding and coding and coding. Until it gets 3.00 AM.

This is what I call “the developer syndrome”.

If you are like me, knowing that you’ve built the whole software by yourself (and meeting the deadline) is a terrific feeling. I have afforded endless hours creating reusable libraries with extreme features and characteristics. I have even contributed some of them to the open-source community, so other people could benefit from my work for free. I love building new software, and so do you. Noticed the word “new”? Building software is your primary purpose, but you have to be really careful when it comes to reinventing the wheel. In this article, we’ll try to find out when using code from other people is an acceptable practice and when you need to do the whole job by yourself.

Why use someone else’s code?

1. Save time. Lots of it.

Let’s say you want to build an e-shop for your client or boss. The website is a typical WordPress installation. You can either install and configure some free or paid plugins, or create your own e-shop plugin. In this scenario, the benefit of using a plugin is pretty obvious: you save way more time than creating the whole e-shop functionality by yourself. If the available plugins contain the feature list you need, then it doesn’t make sense to re-invent the wheel. Also, try to get to your boss’s shoes. If you cost him 10,000 dollars per week and you need two weeks to implement the functionality, then the e-shop comes at a 20,000 cost. Unless it’s critical corporate data, a custom, time-consuming solution is not appropriate.

2. Reusable code

More of the third-party solutions out there, especially the paid ones, integrate a lot of functionality you can use in various different projects. If you buy ASP.NET components for example, you’ll find that you can easily change the look and feel of the controls and reuse them in multiple occasions. Usually, such solutions are built with extensibility in mind, so they can fit in many different projects.

3. Avoid bugs

Most of the third-party libraries are used by a huge range of users and developers and a lot of time has been invested for testing the product. If you need a highly complex element to secure your data and you only have a couple of weeks available, trusting a tested solution could be the way to go.

4. Updates and support

Free, open-source libraries and commercial packages are usually maintained by passionate solo developers or engineers that get paid for extending and updating them, ensuring that the solutions will be viable even after any upcoming technological changes. More importantly, when you have an issue there could be an army of people to help you immediately. Many projects also have a strong community of independent specialists who would help you at no cost. Public forums, private support tickets, and even StackOverflow or CodeProject, can be used for support.

Why NOT use a third-party solution?

So, third party libraries can save your day, right? Well, nothing could be further from the truth. Sometimes, you’ll have to develop your own solutions, no matter what. This where the developer syndrome comes in handy:

1. Bureaucracy

It’s common in big companies and organisations: You ask for a particular tool to finish the project. The program manager informs the department manager. The department manager requests a specific budget from the financial department. The budget is approved, so the managers can proceed with purchasing your software. If that whole process takes two weeks, you could have written the software yourself.

2. Bad documentation

Even if you discover a solution that promises to solve your problems and accelerate your work, you have to be very careful about the way you can use it. If you spend more time reading the documentation and finding the way out of it than developing your own solution, then you should check for something else. Chances are that, even if you make it work, future changes will be unattainable.

3. Awful-or-no support

So, you have found a library that seems to fit your job. Before using it, remember to check: how active the support community is? Does it receive frequent updates? Does the developer of the library address issues and bugs? If it’s a commercial product, how good the support team is? There are thousands of GitHub repositories that haven’t been updated since the Jurassic period.

4. You only need a subset of features

Many third-party tools and libraries integrate lots of functionality. However, you rarely (or never) need all of this. More features imply larger file size. Larger file size means bigger loading times and more resource consumption. That could result in bad user experience. File size also matters when you develop mobile apps. Apple allows up to 50MB, so think twice before you include the 30-MB library from which you only use a subset of features.

So, what do you need to do?

Part of my consulting work is to coach startup companies how to efficiently allocate their technical resources. This is what many entrepreneurs tell me:

“Oh, Facebook and Twitter have developed their own versions of database systems and their own version of PHP. Should we try to develop custom systems as well?”

I have seen startup companies that spend money to build TRIVIAL stuff! That’s insane! When you own a startup company, your first goal should be to get to the market quickly. You need to build your minimum viable product that will seduce your first customers. There is no point trying to make everything perfect. If you have the infinite budget of Facebook, fine, go for custom high-end solutions. However, chances are you are not Facebook. Creating complex products from scratch is not viable when you need to get to the market as soon as possible. In such cases, you’d better pay a few bucks to “buy” some code (and valuable time), rather than spending months to develop it by yourself.

3 key elements to consider (and Frankenstein software)

Whenever you feel overwhelmed by the developer syndrome, keep the following important elements in mind:

4 types of advice you can apply right now

1. If you are a startup company, prefer spending more resources and time on design, rather than building something that already exists. After all, design is your first impression, and you have only one chance to make a first impression. Moreover, spend resources on the really innovative things (such as Kinect or AI).
2. If you are a freelance developer, build what makes more sense to your client’s needs. Check the project requirements thoroughly and decide what is more efficient to do. Specify timelines and inform your customer about what can be done with a specified budget at a specified time frame.
3. If you work for a traditional company, remember the golden rule of the employers: your employers want to make more money than they spend on your salary.
4. If you are a 1st or 2nd year undergraduate Computer Science student, you have to write most of the code yourself, so you can get familiar with the programming methodologies you’ll face in your professional life.

So, what do you do? How do you use other people’s code? How much do you fall into the developer syndrome? Leave a comment and I will update the article with your own feedback!

(*) “Frankenstein software” is a software product that consists of copy-paste code and low quality third-party libraries. Frankenstein software seems to work, but is usually buggy and totally unstable. If you remember the pre-jQuery JavaScript era, you know exactly what I mean…