Start Lean: Why it’s best to split your next coding project by feature

A brief guide to staying focused and boosting your productivity

Ewald B.
Ewald B.
Aug 14, 2017 · 4 min read

Suppose you have that great idea of a software product. Maybe this idea wanders around in your mind for some days until you feel the strong need of getting your hands dirty. You might start with some up-front work like doing some architecture sketches or some user interface mock-ups but eventually you reach the point where you are about to write your first lines of code.

I won’t go into the details of how much work a project needs before actual coding can begin. Paulo Caroli wrote a great article about the so-called Lean Inception that describes a way of keeping that phase — I call it the pre-coding phase — short. After you have picked the language and development environment of your choice you might ask yourself: “Where do I start best writing my first lines of code?”


When working with other developers I tend to say that most of them usually start with what they are most familiar with. Those with a strong background in backend development do the backend first and those with the frontend, of course, the UI stuff. I have even seen people starting with the database model. Nothing bad, isn’t it? Well, like everything it’s not that simple.

Our primary goal should be bringing the most value to the customer and that as fast as we can. That’s what lean is all about. Not more not less. So how can we apply this principle to the question we stated above?

I usually like examples because they give me an immediate impression how I can apply the principles on my problems. We’ve got an UI. The user interacts with the application over web or a mobile device app but that doesn’t really matter. However it’s easier to imagine. Then there’s some backend that provides a REST API and contains the business logic. Of course we have a persistent datastore which can be a classic relational database or NoSQL DB or even plain files. What’s important here are the three main blocks the whole application stack consists of namely the frontend, backend and database.


Often we try to reach a minimum viable product (short MVP) that can be shown to the customer. It contains the most important features that are necessary to fulfill its purpose. You can think of it as the right to exist. One feature usually cannot live with even one of the three components (frontend, backend or datastore) missing. The feature literally cuts through the application stack. You need to touch all three of them to get the feature running. In agile development you focus on features. One should be finished before the next is started. With continuous delivery (CD) you can even provide a working product at all times.

Now that it’s clear to dispatch one feature after the other instead of dividing the work based on the technology (web, programming languages, etc.) or application stack we are left with the decision whether to create these two screens for that feature first or tackle the backend immediately. Or the database?

When starting with the UI then you get the benefit that you can evolve your API to the backend based on the needs of the frontend. The backend doesn’t exist as yet but you just continue the work as it existed. All functionality should be mocked. Once the frontend is completed then head to the backend. Automated tests define how the interface to the backend should behave. The same rules apply for the interaction between the backend and the database. The “user” of the database is essentially the backend. It holds the data in an easily accessible way that the feature can consume. There are cases where a human is not the direct “customer” of your application. For example when you interface your product with other applications you don’t have control over. Then you start coding at those interface points. Your customer is not a human then.

Development direction by feature

Doing it the opposite around there’s a big risk that the backend’s API is not as the UI needs it to be. Especially at the beginning of a project when the user’s interface is being changed regularly the burden to adapt an up-front defined API to the backend that doesn’t meet the requirements is significant.

Summary

  • divide the work by feature
  • start coding from your customer’s perspective
  • support development with automated tests from early stage

Have you ever faced the opposite that the software project you were working on had absolutely no apparent design and felt so convoluted? Check out my other post!

Would love to read your comments!