On the right choices

When I’ve started this blog I made a deal with myself to only write about subjects that could translate to other things in life, not a web development universum. I always like to treat issues as a whole — so that the sole feature or lack of it does not determine whether a project is success.

Today I would like to talk about reusing things. In a world of web development a common project would consist of a whole stack of libraries, plugins and small utilities which together create a solid pipeline for producing a nice website. And by nice I mean not only visually appealing but also easy to maintain, debug and scale according to the needs.

I think choosing the right toolset is more important than actual development in all projects. On many occassions I’ve made the bad choices regarding using a library over writing something from scratch or choosing an incorrect tool for the task. I sincerelyhope some of you might find the following notes useful at some point. Here goes:

1. If a schedule is tight, choose the bulletproof tools over the new ones. The same applies to a large scope (devices and platforms).

For almost every creative project there is a prototyping stage where you test things out, throw everything at the wall and see what sticks. Let’s assume you have three different ways to overcome a problem and of the three two are reasonable, differing in performance and overall coolness. Which one to choose?

The answer is: depends on the timing. I, for one, always try new libraries and try to work things out quickly, but it has proved to be problematic when you don’t quite know the limitations of the approach and end up with a huge problem when you find yout the performance on device X is not so great or it doesn’t work at all.

Time wise, I choose the most robust solution available. I check github for pull requests and issues, and by no means the less issues the better. If a project has known bugs and a bucket full of pull requests it means it’s both widely used and actively maintaned and that is precisely what I’m going after.

2. Spend twice as many hours as you think you need on research before development kickoff.

This one is easy in theory. You’ll spend the next day googling and digging stuff, doing some super simple prototyping and then you’re ready to go. Truth is, you’re not. Let it settle a bit. Check how it works across browsers and devices, if you need to support them. Try different input data to see what the boundaries are. Be in control. By doing all the above you’ll have a very clear picture regarding your available options and will be able to step back and readjust before it’s really difficult to build again from scratch.

3. Test on platforms at every stage. Do not leave that for QA phase!

That seems pretty obvious, but when the reality kicks in and you’re in a midst of a storm you’re also likely to forget about cross-checking your project in browsers and devices supported in the project scope.

The trouble is, whereas it might seem an interruption in a smooth flow, cross-browser and cross-device testing in short intervals is really key and we often leave that towards the end of a project life cycle. Should any problems arise, you’re likely to be stressed out and feel angry (“why the f… does it break”) thinking about an approaching deadline. Also, with a high level of complexity at that stage you’ll spend more time debugging and testing as there are more steps and layers to inspect in order to find the bug.

I’ve been there and it’s a bad idea.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.