Mircea Dinoiu

Self-made vs library-based solutions

September 16, 2016

I want to tell you a story of how you can make a mistake in software development by thinking small.

Common case

Sometimes, we don't see the problems in the bigger picture because we are blinded by the current issues we have. And we are driven to solve them ASAP.

Often, developers have the tendency to become defensive and make excuses when they know they’ve implemented something in the wrong way.

How do these excuses sound?

  • We had a deadline
  • There were too many modifications implicated, therefore a price too big to pay
  • I don't need all the bloat that the library or framework is giving me
  • ... and so on

My story

I've started working on a JavaScript project with no architecture. No architecture means: <script> tag for each module introduced by hand, no framework, no nothing.

A bunch of new features were requested by the client. They were like 5 new whole complex pages that we needed to implement.

Considering that now we had 5 more pages on the web application, some dependency management needed to be in place. So a team mate introduced an experimental dependency management (how..?) that at least kept us clear of the necessity of adding <script> tags in the HTML code. This was the beginning of the suffering.

Pages were implemented and released. The client was happy.

As soon as the next features were required for implementation, the issues with this whole approach started to show up. We had crashes from time to time, no consistency in the architecture, etc.

The next big mistake? Let’s solve these all by ourselves. So we’ve implemented a wrapper over this dependency management library in order to simplify things.

Soon, all the modules were to be using the new in-house developed THING. Why not picking up a library? See the excuses above.

Next?

  1. maintain the THING
  2. fix the THING
  3. go to step 1
At some point, the THING became stable and required less adjustments. But when we wanted to add some new behaviors or scenarios to it, it would bring us back to the 3 steps mentioned earlier.

New addition to the team: a more experienced colleague came and asked a lot of questions trying to understand why are we using the THING. He told me multiple concerns that I couldn’t accept at the moment because it affected my pride as a developer and as the creator of the THING.

However, I knew deep inside that he was right, but I needed some time to process this. After all, I agreed he has some points. What did I do? Instead of getting rid of it, I started adjusting the THING per his suggestions. Funny, right? :D

To be more clear, as much as I wished, I couldn’t just replace it with a library because it was too late, the code base was huge and one-time modifications like these could be “catastrophic” for the project.

I’ve worked hard to change the API signatures to match the ones from the library and finally I just switched the THING with the library.

Everyone was happy in the end because this really worked. It was, however, a much bigger price to pay comparing to what we would have been paid if we were to choose the library from the beginning.

Conclusions

  • Always ask someone more experienced than you when you want to make a decision that is over your capabilities or responsibilities. We all have to learn, so you better not overestimate yourself, because it's easier to learn by asking than learning by mistake.
  • Pay the price at first even if it feels too much. Delaying the "payment" results into adding "interest rates" and could result into doing much more effort in the end.
  • Making up excuses is natural. If you ever feel you want to make up an excuse for something, you may want to ask yourself: Would it be better if I actually considered what the other person is saying?
  • Think bigger. Scalability and extensibility are two main factors that you want to keep an eye on when making a technical decision.

Kyle Mathews
Front End Dev living in Bay Area. I love video games and snowboarding.