I see a problem in modern software development. Which hurts businesses a lot. Our QuickAdmin suffers from it, too, so this article is kind of a confession with expensive lesson.

The thing is that developers think that their job is to produce code. Valid, elegant, flexible, easy-to-read, maintainable, extensible etc. And they focus on those technical decisions only, often forgetting the big picture, which has a different goal – to serve the customer.

One would probably argue that quality code is actually serving the customer. And that’s partly true. But if we look at it from business perspective, or with the eyes of a customer – neither of those actually care about the code. They care about functionality which helps to get their jobs done.

In fact, they don’t even care what functions your project has – as long as it helps them reach their final goal. For example, if there is a function of importing data, that’s great – I would import it. But if instead the system somehow automatically gets the data from somewhere – so there is NO import functionality – I think no one would argue. What I mean is sometimes not having a function is a better option.

There is a product management framework which recently got popular – called Jobs to be done. Basically, it says that you should focus on the actual result your customer wants to achieve. For that they probably need to perform some job. And that’s where your product should help. It doesn’t matter that much how the product looks/works, as long as it helps reach the goal effectively.

jobs-to-be-done

Transferring that theory to the world of IT projects, quite often developers think about effective code and don’t really ask why the function is needed. What is the actual final goal of the client, what do they want to achieve. Cause if you ask “why” at least several times, you might come to conclusion that:

  • The function you’re building needs to work differently
  • There is already another function which you can use in this case
  • There is another tool which is quicker/cheaper to integrate than create your own
  • The function is more like “nice-to-have” and client doesn’t realize how much it would cost to build, otherwise they would refuse to build it
  • Priority of this function is much lower than you initially thought

So if you say “stop and think for a minute”, you might actually help the project. Without even writing the code.

How it looks in practice

Example from our QuickAdmin product. While trying to build “the best Laravel adminpanel generator in the world”, we changed the core functionality logic 4 times. Yes, rewrote from scratch. Not once, not twice, FOUR times. Of course, it made sense every time – at first too slow, then too little flexibility, then too many bugs, then rewriting with TDD approach. And from development point of view it’s totally fine.

Finally, we were pretty happy with the codebase – my colleague lead-developer was proud of himself and the team for TDD approach and the performance.

like-a-boss

But then we looked at the stats via Piwik (awesome tool for analytics, by the way!) and realized a painful reality – only 2-5% of our users were actually using edge-case generators that we were refactoring for. Functions like:

  • Changing field type from int to varchar
  • More convenient/flexible radio-buttons options
  • Choosing date format for your adminpanel
  • and others…

All those functions were important for those users who are in the middle of creating their adminpanel. But the problem was that majority of our potential customers stopped much much earlier! As we saw in statistics, 60-70% of registered users just wandered around with default generated adminpanel and didn’t do ANYTHING else. Just left. Reasons may vary – didn’t reach the expectations, unclear UX, some bugs etc. But the main point is before you optimize the code and think about the “most effective” way to build a function – think about whether it’s actually needed there and then!

Therefore in our case we’ve decided to stop on building new “deeper” functionality and focused on the customer onboarding process – shortening registration form, presenting information in a more convenient way, provide first demo-CRUDs for them etc. And now we actually see the results from this – conversions to active users and to paying customers went up.

In short

So, my advice to developers here is to think broader. When you get up from your table at the end of the day, think about not how many code commits you have made, but what problems have you solved. Problems of real people. How many people you have actually helped today – cause that should be the result of your coding. Not the code.