Select tools to satisfy current needs

author image Slava Abakumov


Choice for current needs

Developers life isn’t easy. We have lots of ideas, code to write, lots of everything else to satisfy current needs:

  • frameworks,
  • libraries,
  • tools.

And that’s developers, who take responsibility when they select those things, that will be used in projects. Client almost always doesn’t have any idea (and, basically, should not care) about the difference between them, and integration, and usage complexity. But clients do can see effects of those choices from the business perspective, that can be like this (but not limited to):

  • time to launch (the longer the worse)
  • time to upgrade (the longer the worse)
  • affected conversions
  • changes in user experience
  • changes in a generated revenue

All of those metrics can be and is measured by business owners.

Developers are here not only to create a “yet another wine-related web-store” (as an example out of head) and get paid, their main goal should be to make client succeed. Because that will be beneficial to all parties. Client will be happy, and everybody loves being happy. So s/he will come back to that person, who created something that was successful, and that means in most cases – to that same developer. And thus, developer will get a recurring client, which is great as well.

I will write some day a post, how I see the relation between a client and a developer, but now I would like to focus on another thing.

Developers should select tools, that give ability to solve the problem right now. And, unfortunately, that means sometimes to live with developer-related drawbacks of those selected tools. Because business is more important, than convenience.

Let me show it on an example.

On one of my projects I wanted to use ButterBean by Justin Tadlock.


There were several reasons for that:

  • I know the quality of his work
  • it is a fairly new library (micro-framework) – and “new” often means “exciting”
  • I do like the UI, that was inspired by WooCommerce:

WooCommerce Example

And ButterBean is created using Backbone.js and Underscore.js, which is yet another reason to try it out – ability to work with powerful libraries included into the WordPress core. Exciting!

But almost immediately I started facing with some limitations, that are relevant only because ButterBean is so young. I needed repeatable fields & TinyMCE (WYSIWYG editor) “right now”. I so hard wanted to use it, that I created a plugin to extend ButterBean to eventually have TinyMCE (limited functionality, but at least something), I created several issues, proposed some improvements that might be helpful for the project from my point of view.

But suddenly, while trying to fix some JavaScript issue in the editor, it became clear to me, that I need to be client-oriented. I should not make decisions, that can badly affected my client. And in my case that was at least time needed to implement the feature. By then I’ve already spent quite a bit of extra, and needed even more (to find a workaround for repeatable fields), so to produce a valuable result sooner than later I pointed my attention to other libraries, that help developers create custom fields for custom content.

So I chose CMB2 by WebDevStudios. It is a developer’s toolkit for building metaboxes, custom fields, and forms for WordPress that will blow your mind.

CMB2 - My Current Needs

There were several reasons:

  • it’s a mature quality project with all the features I needed at that time
  • it was tested on many-many projects by its developers and lots of others
  • it has a big community and lots of additional extensions

And it took me a fraction of time to re-implement and complete the client’s feature using CMB2. But I strongly believe in ButterBean, and I hope that Justin will try to find more time to create a true competitor to CMB2 for some cases, although I understand that they are created for different needs. Like a small kitchen knife for apples and a Swiss all-in-one knife.

What I was reminded from this experience: when working with client it’s better to implement faster, than longer. It saves a ton of time, helps to iterate (and get feedback) quicker, gives ability to launch faster. For client that might mean bigger ROI, for developer – happy returning client. And to sum up:

Select tools to satisfy your clients current needs.


Leave a Reply

Your email address will not be published. Required fields are marked *