Friday, March 2, 2018

Indie vs Enterprise software development

Writing code as an independent developer (which I'll refer to as indie hacking) and enterprise developer both require you to sit down and crank out code but they are worlds apart.

When I was doing enterprise development I started by working with Product Managers to flush through the details and then come up with a technical design which then might have some iterations. Many different use cases and error conditions would get flushed out here. Then it got prioritized in our Agile Sprints and myself or the other devs on the team got to work. The code written is clear and readable, if it doesn't play nicely with other code, sometimes existing code needs to be refactor.

For indie hacking, I come up an idea and nail down an mvp with just a couple sentences. I come up with a sketch of what the UI is supposed to look like. I get started on it as soon as possible. The code works but is not polished at all. There certainly aren't any unit tests.

I think this makes sense because the thought process is different in both cases. In the enterprise development world you work on a much larger team so much of the code you read is optimized to be readable. The code is expected to live a long time and other people will be working in the same code base. As a technical lead, often the main effort was on the communication side of making sure stakeholders were on the same page. The company has been around for awhile, the business has already been validated. Maybe the specific feature you are working on might get killed but the company is invested in getting it out right and still has money to pay you even if it doesn't. This means that although you are expected to work fast, speed is not the most important priority.

On the flip side, indie hacking has so many unknowns. You often have no idea is the business is even viable when you write your first line of code. The more validation you do the better but you run into the chicken  and the egg problem. The customer doesn't really know what they want until they see it. Or people say they want a certain product but in reality won't end up paying for it. Thus you want to get something out as soon as possible so you start getting feedback. Sometimes that just means throwing up a landing page without having a real product to get signups. If you can do things without writing any code, even better. But don't do what a ton of developers starting out do and write code for a year and then end up finding out that noone wants their product. That means fast is a top priority. You need to take shortcuts. This means the code is working but not super polished and not refactored a million times. Note that an MVP should still be high quality, but just a slice of the entire pie with priorities taken into account.

I remember one time the company I worked at bought another company. One of the senior engineers on the team remarked how ugly the inherited code base that he had to integrate with was. Looking back I think the engineer that build the code did the right thing. He wrote working code and sold his company for millions. I suspect that Zuckerberg's original code had to be terrible and I'm sure that if he showed it to developers (before Facebook went to the moon) he would be laughed at by those that didn't understand the tradeoffs he was making.

So I'll dispense with writing the beautiful, perfect code that I am used to 😉 and switch to writing code that works and is good enough. I'll also hopefully learn to feel for what is too much or too little work to put in the different phases. I'll focus on starting and launching and learning.