Monday, July 23, 2018

Enterprise vs. Indie Software Development

Back in my enterprise development days. The company that I was working at acquired another company. One of the senior engineers that was inheriting the new code base remarked how ugly the code was.

Another time as a junior engineer for a different company, I was required to dig into some legacy code from the founding days of the company. I couldn’t believe how poor the code was as I struggled to understand it.

I’m convinced that Mark Zuckerberg’s original code for Facebook had to be terrible and I’m sure that if he showed it to enterprise developers he would be laughed at. However, I’m also convinced that both the enterprise developers and the solo founders are doing the correct thing.

And that’s what I’d like to talk about today; the difference between enterprise software development and Indie software development. I’ve recently switched from the enterprise world to the indie world so it’s been something on my mind. Both require you to sit down and crank out code. You drink coffee. Sit in front of a computer and code away. But they are far from the same and if you neglect the differences, it can really hinder you.

What does enterprise development look like?


In the enterprise development world, even before any code is written there is bunch of stuff that needs to happen first. You might start with working with Product Managers to flush through the project details and then come up with a technical design document. This should address all the use cases. Then you’d present this to the product managers as well as other technical stakeholders on other teams. This document may go through some iterations. Many different use cases and error conditions get flushed out here. Then the work gets chunked up into pieces, estimated, and prioritized. Finally they are assigned to the developers.

The technologies that are chosen are well known in the industry to be the most reliable and can scale well under load.

The result is code that is clear and readable. Code is written for readability so that other engineers stumbling over it could easily understand it. Methods that are too large are broken down into smaller methods. Code is never allowed to be copy and pasted. Common code is refactored into a common library that can be shared. Unit tests and integration tests are written. It is important to have proper code coverage so that the team can quickly detect if future changes break it. There is a mandatory code review where other engineers scrutinized the changes.

What does indie development look like?


For indie hacking, I come up with 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. I ship before some of the features are complete and while there are still known bugs in some parts of the code.

Why is this so?


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 is on the communication side of making sure stakeholders are 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. In fact for many (arguably poorly led) enterprise companies, it becomes more about writing code than the product since the engineers can be far removed from the customers. You get paid for the code. Your bonuses may depend on how good your code is in code reviews and if your code

On the flip side, indie developer has so many unknowns. You often have no idea if 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 feedback loops are a top priority. You need to take shortcuts in order to get something in front of someone so you can start . This means the code is working but not super polished and not refactored a million times. For indie developers, it becomes all about the product. The code takes a backseat.

Don’t Confuse The Two


Both enterprise and indie developers are acting rationally. If you don’t have any customers it would be a major mistake to spend so much effort polishing up the code and spending too much time working on useless features that the customer doesn’t care about. There is probably a high likelihood that you will end up throwing all of that MVP code away.

On the flip side if you are an enterprise developer, you probably have a large number of customer and a large number of developers. Thus the code you are expected to write will likely need to be scalable, robust, and well written right out of the gate.

As Peter Levels mentions, the rules are different. Enterprise has its set of rules and solo making has its set of rules. Mistakes are made when the wrong rules are applied to the wrong game; the indie developer that spends too much time to make the codebase perfect and never ships or the enterprise developer that writes working code quickly but unreadable by his teammates. In the end it’s all about figuring out what is important for the game you are playing and optimizing for that.