The developer syndrome and how (not) to avoid it

By August 4, 2014 Business, CodeProject
The developer syndrome

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. The developer syndrome (Incredibles)

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:

The developer syndrome (quality, time, money)

1. Quality

Product quality should be your primary concern. Every single engineer has very specific standards about her work. Lowering your standards is a bad thing and won’t help you in the long term. Do not provide your clients or employers with Frankenstein software (*) just because you are lazy. Instead, strive for quality and allocate your resources accordingly.

2. Time

Time is the second most important factor. Projects have deadlines you should meet. You can’t buy time, but, if you are sort of it, you can buy software that integrates smoothly with your code and finish on time.

3. Budget

Time is money and money is your client’s / boss’s budget. High-end solutions cost money. If you are aware of the budget, explain with every single detail what can be done with it. You can’t create the new Facebook with a few thousand of dollars, but you could build a simple social network (with the minimum functionality) using web plugins and open-source software.

In short, think: what is the highest quality you can achieve with the given budget and time frame? Then, make your decisions with the software product 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… The developer syndrome (Frankenstein)

Vangos Pterneas

Author Vangos Pterneas

Vangos Pterneas is an award-winning Microsoft Most Valuable Professional. He is helping companies from all over the world grow their revenue by creating profitable software products. He loves Motion Technology and Mixed Reality. Vangos is the CEO of LightBuzz Inc and author of The Dark Art Of Freelancing.

More posts by Vangos Pterneas

Join the discussion 8 Comments

  • Hey Vangos,

    Thanks for the great blog. This is a topic that really needed to be expressed in our community. As technology jumps forward at almost light-speed in some cases, it is almost virtually impossible to keep up with the changes unless it is your job. For myself, coding is not my primary job, I am a human factors engineer at NASA and was hired to do evaluations of human performance with space hardware and software. However, with changes in the space industry over the past few years, our group has started doing more traditional research and some R&D. I have found the Kinect to be a technology that benefits my interest in interface design through the use of gestures. Therefore, I have been forced to start learning code, again (the last time I coded was in graduate school back around 2004, think of all the changes that have taken place since then), in order to build new and innovative interface prototypes. I know that people like Vangos and others (like my friends at Infostrat, Leap Motion, Microsoft, JPL, and others) have been more than generous to share their code (which is work) and time to help. Thus, here are a couple of more points I will add to the list:
    – If you are going to use the code to help in creating a product, contact the person and let them know about the project and how it will be used. I am not sure how many people expect this, but I think it is just simple professional courtesy. It also helps form a professional relationship. You never know what you may need in the future and who could help. I like having friends in the field that I can come to for support and help.
    – Give credit where credit is due. At least give an acknowledgement in your code, project presentation, whitepaper, or where ever. This is being honest to your group and respectful to the person whom’s work you are using. Also, it let’s the person who wrote the code use that acknowledgement in their vita. This will help the coder (or in some cases a business owner) be able to list your company or organization as a consultant, which could help them get more business, create more code, and keep them around for the future. In addition, I work with a lot of other groups and by acknowledging the person these other groups now know of another person to turn too for help, which could create future work or funding.
    A know I owe a personal thanks to Vangos for his help with my project by using his code as a foundation to build my interface.

    Cheers,
    Shelby Thompson, Ph.D.

  • Alex Rojas says:

    Hello, thanks for this useful points, I’m starting in this and it’s good to somebody gives you this kind of tips to consider. 🙂

  • Denis Kontonis says:

    Hi Vagos
    I and some friends in Canada are going to develop and implement something similar to the captaiwise platform targeted to the North America market.I did sent an email to captaiwise but i got no answer.I will be in Athens Greece till the middle of February and would like to talk with you about our project.
    Please contact me at your convenience.
    regards
    Denis

  • nice information shared by you.I like your article.

  • good blog shared by you.Thanks for this nice information.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.