Day 13 – Writing code is easy, launching the project is not

When I started my online store about 15 years ago, I didn’t care about server configuration or performance of my code.

I think that was actually a good thing, otherwise, I would start to over engineer things and would never launch anything.

Initially, like most other beginner software engineers I wanted to write every little component by myself, naively thinking that I would write it better. Naturally, it did slow down the progress of my project and increased the number of bugs.

Don’t get me wrong, there is nothing bad with writing custom components from scratch instead of using off the shelf packages and libraries (we are engineers after all, right?), but I would only recommend doing it if you have very specific problems that you trying to solve. The same principle applies to different SaaS solutions.

If you are a startup, have very limited resources and a small team, you HAVE to stick with ready to go solutions and packages. I would totally encourage the use of different ready to go SaaS offerings, even if they cost money. You will waste a lot more money and what’s more importantly, TIME creating more “cost effective” version.

It could be a fun process, but it will hurt your business as momentum is the key on the early stages. The goal of the first phase in a startup is to test your ideas against the market as fast as possible. It’s very likely that the whole thing that you write now will be thrown out and rewritten from scratch once you find your unique position on the market and get some money flowing in.

In the well-established organization with big engineering team writing custom or supporting open source solutions could be very cost effective. Sometimes it makes sense to hire a few engineers for 250K a year to support ELK cluster instead of paying 1M a year to something like Splunk. Totally different ball game.

Fortunately, I was a total noobie when I started writing my online store, so I didn’t stress too much about perfection. I was excited to just develop a new feature and deploy it to production as soon as possible.

Guess what, in a few years after we launched the first edition of the site I rewrote it completely from scratch (moved it to a well known open source project), but at that time we already had established business and revenue stream.

There is another danger that could significantly delay the first version of your product. It’s called CMS trap. My good friend Maxim Chernyak came up with the term and wrote an excellent article about it (a highly recommended read for every software engineer).

I can honestly say that I got into this trap myself. About 8 years ago I was introduced to Drupal CMS and was literally obsessed with it for a few years. What happened was my Drupal skills grew, but my programming skills declined. I started looking at all tech problems through Drupal or you can say “CMS” lenses…

Here is another story for you guys. Some time ago I had an idea to create an online course to teach people programming. As a true software engineer instead of using some off the shelf platform and focus on the course content, I spent about 6 months developing the site, obsessing over different parts like advanced users registration, coupon/discounts system (naively assuming that I will be adding more courses in the future), modern navigation between lessons using latest frontend technologies. Then I decided to add some subdomain support so I could put new courses on the subdomain and they would automatically hook into payment processor…

Most legacy code I’ve seen suffers from the same disease: overmodelled early assumptions – @hakunin

When I finally launched the site I had almost zero sales – a total flop… It seemed like I had everything for the success: the shiny CMS with advanced custom logic, custom design, all the servers configured. The only thing I forgot (or should I say conveniently overlooked?) was to spend time on truly essential parts – the content and marketing!

The next time I spoke with Max, I expressed my frustrations with the project and how I wasted so much time creating it. After I finished my rant he just asked: “Why did u decide to use CMS here at all? Why did you need a database at all? Why not just throw a simple JSON file as a temporary database, especially if you don’t need to filter or search anything?”

Of course, at the time I was defending my decisions and maybe even come up with some sound arguments, but that talk and the whole negative experience with the failed project made me look at myself from the different perspective. I was totally living in the CMS trap, I forgot how to code…

Shortly after our conversation, I started looking at other languages and frameworks and was amazed to see how people build complex modular systems without using full blown CMS. This was a big eye opener for me. I finally understood (I think?) what it means to be a good software engineer. Good software engineer provides the simplest possible solution to the current problem. It doesn’t mean the solution is fragile, short lived or untested. Nothing like that. It just means simple.

“If you’re willing to restrict the flexibility of your approach, you can almost always do something better.” – @ID_AA_Carmack

There is one gotcha though – the simplest solution is the hardest to come up with. In some cases, the problem itself needs to be re-evaluated and questioned. I’ve seen too many cases when a quick discussion with key stakeholders uncovered a simple change of the process (not the code!) that was necessary to eliminate the problem!

Don’t be afraid to ask questions, so you can get a very deep understanding of the problem at hand. Don’t just jump straight to the coding. Every new line of code needs to be justified by the real need. I would much rather remove code instead of adding it.

If I knew all of that before I started my 6-month project, I would create it in a week with a few template files plus a simple JSON file as a data store and would spend the rest of the time on content creation and promotion, so people could actually find and use it… Well, sometimes you just need to go through all the troubles to hit the wall and learn a lesson. Don’t repeat my mistakes guys.

Don’t obsess with easy parts (and I think coding is actually an easy part believe it or not when it comes to starting a new business)! Do the market research, gather critical requirements, conduct some surveys. You should do all of that before writing a single line of code.

It’s great if you have a partner who will do all that work for you, but I would encourage you to learn some marketing tricks regardless of that. It will make you a better engineer, just trust me.

P.S. Next I tried even more radical thing for my next project – a WordPress plugin (who would think). I actually hired someone else to code it for me! 🙂 Stay tuned if you want to know what came out of that.