Studio Zenkai


Bold and Clear, without excess • Kaizen 改善 • With Purpose


Studio Zenkai is dedicated to the craft of digital innovation. We push boundaries in web platforms and mobile applications — from healthcare, sports and fitness, travel, ecommerce to home automation. Every day, we invent, rethink or perfect tools in big data, Internet of Things, image analysis and recognition, neural networks including deep learning, with a special focus on superior user experience.


Writing Bold Code

I wrote a Ruby Performance Checklist. Since then, I have seen the performance panel at RailsConf. Richard Schneeman (@schneems) then wrote an article on back-end performance, which starts by memory profiling tools like scout or rack-mini-profiler.

I like his article. My checklist started by Ruby code complexity. If you refactor well your code and make it simpler, it is actually the same strategy as advised by @schneems.

This begs the question: why do we always always discuss Ruby performance?

A quick answer is that Ruby is slow and takes too much memory.

This is false. Ruby is as fast as many other languages, like Python or Erlang. Methods like sort or select are in C and are very fast.

It also possible to write a program in C that’s slower than Ruby for the same purpose. See here how a simple Ruby solution is better than another C implementation. As mentioned in the previous article, there are also frameworks like roda which are faster than nodejs or go frameworks.

I believe the main reason Ruby apps, and especially Rails apps, are slower are because most of them are unecessarily complex and also naively implement features, instead of being economical.

DHH for instance advises to create as many controllers as possible. You might get only one action per file, and get >100 controller files. This other keynote by Andrew Hao tells how he designs so-called “beautiful systems” by separating files into different namespaces. He continues and adds different initializers, adapters and layers. Are we done yet? Probably not, because having different layers will increase the need for security mechanisms. Andrew Hao will probably advise you to get another AWS instance and pay more developers, like DHH does.

These are all expensive. Writing yet another method, called only once, is expensive. Adding another instance variable instead of using the existing is expensive. Callbacks & middleware are expensive. All the kitchen sink is expensive. And if you have a junior programmer in the team who likes to load all users with all comments and posts, because he can do that in one line with Ruby, that’s prohibitively expensive. A homepage request might allocate thousands and thousands of objects. I just have the impression that the Ruby (esp. Rails) community attracts people who code like there is no tomorrow.

This is not specific to Ruby. I can have the same impression when reviewing code Javascript, php or many other languages.

What does all this mean? Practically it’s often a mess, because it’s too easy to add “stuff”. We all want to please, add more features, support more formats, add more conditions for edge and bondary cases. Because that justifies our salary, our budget or yet another push request to our name.

What if there is another alternative? You will be interested in principles I have been following lately when writing code:

  1. Whatever you do, it has been already done (better) somewhere else
  2. Otherwise, write as least as possible
  3. And write boldly!

For (1), it means that many other programmers already invested valuable brain-hours in the issue. Whatever you can come up with, it is better in 98% of the cases to use what they’ve done. For example, don’t try to re-implement time zones. Don’t try to code another time reservation system. Don’t develop an Uber clone. Don’t think you can do a better queue system. You will loose and cry in a corner.

It does not mean to use any library you found on Github. It can be bloated, full of issues and unnecessary complex. I find a good programmer must spend good time in using various libraries, test them thouroughly, see what makes one better than the other, and make this a life-long practice. And, instead of writing 100 lines, you will find yourself writing just two configuration lines in the future.

(2) : If your use case requires new code, then restrain yourself from writing new lines or characters as much as possible. If a new line is trivial, then there must be ways to skip it. But if your lines are so dense and complicated that a fresh pair of eyes will get lost trying to follow its meandering, splitting logic, then you probably haven’t tried hard it enough to make your code simpler and shorter.

Like (1) above, this does not come naturally. Beginners are tempted to write, line after line. One of my mantra is every time I re-read a line of my code, I try to improve it. Everytime, try to make it shorter. Make it easier to read. This gets harder with time, but then after a few thousands trials, there is a significant difference, until it becomes a natural, elegant and powerful flow.

Pro tip: it helps also reading people’s algorithms. And of course it helps to know the idioms in your particular language.

(3) : so what does boldness has anything to do with programming? Well, many developers want to please and try to accept anything. Yet they don’t even know what their customers want, and so they also send supplementary data. Those are the grey translucent fields that go from meta-tags, extra dates, object state to dozens of other data points that only makes everyone confused. Have you decided yet? I find therefore there’s a value in being bold, by showing 1 input and 1 output, and by discarding everything else :D Users might be surprised by the sparsity of the data, but they will thank you for the clarity, and the freshness of your app.

Rewritten in a different way, (3) means to choose to do only 1 thing and do it well. You don’t get any value by doing like everyone else. If a customer, a partner or a manager says “It would be good if it also …”. Well you should be firm in your position and also review your relationship with them. Be Bold, young dev!