When I was growing up, my dad would often say, “Inventors are lazy”. The genius of inventors tends to dazzle, but it could also be that they were tired of doing things repetitively and were looking for simple ways to speed-up menial tasks. According to my father, Charles Babbage was ‘the laziest of the lot’ because he invented the mechanical computer since he wanted a machine to solve his math problems.

When we started building Compile, we wanted to spend time building business modules, not waste development cycles on the nuances of the technology pieces. So we wanted a framework for the web systems that just worked from the word go. Django fit right into the case. And, as our resident panda writes, this allowed us to write easily readable programs.

But over time we realised that we were doing a lot of very similar things on various modules in the system, e.g.: search, filters. This made us think on how we could minimize the time spent on writing code for each product and module. We set out to fix this issue. Django’s own code gave us indicators on what to do.

Applying the philosophy of DRY, we decided not to have any repeating code in our system. We also moved a lot of our code from the functional code to OOP + configuration based system.

Within 3 months, our code was re-factored into a better system as a side project, for Anirudh and me. We also built a more structured system from the database to the code level, with just one core philosophy - ‘Write as little code as possible.’

Our systems have been running for over a year now on the “new” code base. Over the last year we have built a lot of products on top of our base system. Interestingly, one of the product’s web components was built, or rather configured, from the prototype to the build and the deploy phase in three hours flat!

Take a look at the small piece of code (heavily inspired by and using Django ListView)

gist:cyriac/86b68c650176c55f075a

If I were to distill what we learnt in this process, this is what it would be:

1. Spend time on your algorithms

   If you look at the above snippet, you’ll notice that there is no logic component to it. Every logic component is hidden behind the scenes. The reason is simple, the logic component is common, and is repeatable with minor variations. So we simply made everything as configurations.

   How does this help us? We now spend time only writing custom algorithms for each product.

2. Spend less time maintaining the modules

   Since most of the pieces are repeatable with minor variations, maintaining it was a hard job for each module. This was also a real cost to the engineering team. Now we have substantially reduced costs as the core code is maintained for the core components that are shared between modules. If we fix a bug, it gets instantly shared on all the modules.

3. Divide the worries

   Let the application engineer worry about the business logic and the infrastructure engineer worry about the systems. This might not work in a start-up initially, as both engineers may be the same person. But as we grew our team, this helped us a lot. People need to only worry about what they are working on and not the entire foundation of the system.

4. Make it easy for everyone

   A recent hire at Compile, within a few weeks of joining, told us that he could easily understand our architecture because it was all just configurations. Why was this? It’s because we make sure our configuration parameters are really verbose and readable.

5. Configuration over code

   Speed matters a lot in a start-up. It is all about iterating your product till you find your sweet spot. Having a system that facilitates this is very important. We are able to iterate quickly, because most of our features are just modules and logic configured in different way.

I’d like to think that we are a lazy bunch, here at Compile. We are also obsessive about building the best product possible. Happily, the two can co-exist, leaving us enough time to worry about more pressing problems, like what to stock in the company fridge.