Get your goals right, folks

Posted on Sep 7, 2015 | Categories: coding

Please let me rant a little bit about the importance of defining your goals correctly and doing some research on the available solutions.

The theoretical side

It happened a few times last year that I found a library which exactly fitted the reason I was writing code for at that moment. What to do when this happens? Continue developing your solution? Adopting some pieces of code from the solution you found, or just implement the solution or library you found in whole?

Whenever you find a library which totally fits the problem you are writing code for there are three stages of disbelief:

  1. That can’t be true

  2. It’s true but my software works better

  3. It’s true and my software is just crap

Whatever you may choose wouldn’t be a problem if it only didn’t involve huge amounts of time. When I try to make clear for myself about which way to choose I ask myself a few questions:

  • How much time does it cost to finish the solution I’m working on?

  • How much time does it cost me to maintain it?

The questions above practically only apply to your own solution. When you’re thinking about the solution you may implement you can ask yourself the following questions:

  • How much time is required to decouple whatever I wrote and implement the solution I’ve found?

  • What time is required to keep it up to date?

  • Is the project actively being maintained?

Most of the time these are though choices. It will get even more difficult when you put a lot of effort (and emotion) in it already. Stick with the plan or just ditch it?

The best advice I can probably give you is to RTFM (Read That Fucking Manual) of the solution you consider implementing as the counterpart of your project. While a library might seem to fit at first sight it might be useless when you dig a little deeper into it. This also applies the other way around. When finding a library which doesn’t seem to exactly fit just read a little bit around to find how it may help you.

I just see that way too few (junior) developers are reading their documentation properly. “Just try it, and if it doesn’t fit, we’ll ditch it anyway.” seems to be the the general rule when developing software solutions sometimes.

In addition to this we also have to do more research on the libraries and solution we’re about to use. Just ask ourselves the same questions again, does it fit our project. While the business rules are clear most of the time we just may do a little more research on the available software we can use in the favor of the project.

While I realize this topic may be influenced by company culture (consider I work in a highly flexible company where we can almost use whatever technology we’d like and about which we think it fits the job the best), I think this goal of doing a little more research especially applies to junior software developers and/or hobbyists. The ones who build solutions from scratch just to know how it’s working in general.

The practical side

In the last year I’ve dealt with this problem a few times. Most notably one which involved the Durandal framework.

Durandal is a so called Single Page Application (SPA) Framework which enables developers to ‘easily’ develop enterprise grade web application.

(Did I already tell you about the 2nd grade CS class where we had to write ‘enterprise grade software’? :))

In the days, or better say weeks or months before I found this framework I’ve been developing my own SPA Framework aside from the regular projects. This project featured most of the stuff which is easy like routers, views, viewmodels, trojan patterns and more. There were a few development phases within this project:

  1. Initial development, writing a lot of code and testing the individual pieces of code.

  2. Implementing the code in a project (a school project), only to discover stuff which wasn’t thought out enough, and stuff which didn’t work as expected. Also there were problems with model instantiation, lifetimes of objects, data access and rendering of content.

  3. An iteration in the development cycle as I continued improving this framework with the stuff I learned from the previous project.

While I could endlessly continue this loop I quickly found the limitations of my own framework. After searching for solutions I came back at Durandal again. The point here is, I can invest time to continue with my own project, which isn’t quire rewarding when looking at the amount of features implemented in the end product. On the other hand I can implement Durandal and just continue for a while with a solid base, despite the fact I put a lot of effort into my own framework.

In the end I ditched my own framework and went for Durandal due to the incompleteness of my framework. The time invested, whatsoever, is not completely thrown away. For example, I learned how a system like RequireJS works, I learned about dependency injection and how to implement a dependency resolver. They definitely should assign projects like this to the kids at school.