Today is a good day to code

Why Mining Instead of Farming in Software can be OK

Posted: April 3rd, 2011 | Author: | Filed under: Programming | Tags: , , , , | 1 Comment »

Wil Shipley wrote a great article about mining vs farming when building software and a software company.  I have been thinking about it and I wanted to offer my perspective on it.  Let’s start with this quote:

The problem with mining in the software business is that it doesn’t work. It creates broken, useless companies.

Founders and angel investors usually don’t particularly care if the companies they created live or die after they sell out, because they’ve gotten their money and moved on. There’s no stigma to having a company you founded fail after you leave it. In fact, again, it’s a badge of honor: “Bob Smith founded, sold it for $46MM, then got out before it tanked! Genius!”

Well, while I agree that there is a clear incentive to get to market and sell, people do like money, and it does create some broken companies, I don’t agree that this is a bad thing.  The entire point of a startup is to search for a viable business model.  Once you find it, occasionally the founders can continue on, but frequently the founders find somebody who can clean up the mess and make a killing off of the awesome opportunity they have discovered.  However, and this is where the broken companies come in, the founders never find a business model.  They love the idea so much they sacrifice too much in quality, spirit, and finance to keep something going that can never work.

So in a healthy economy in general, you are going to have some companies that just have broken business models and terrible code and will fail.  Then you have companies that want to farm, so they take huge amounts of funding, or time, to build up fantastic and impeccable structures of code, but they haven’t released anything so they don’t really know if customers will want it.  They build for years and launch only to find that customers yawn, or worse are antagonistic to the product after the hype cycle.  Then you have a company with great code and developers can never work.  The founders often take more money, rinse… dry… repeat…

Finally, you have startups that, crank out an MVP the code behind it is terrible, the execution is only So / So, but they get it to market and customers love it.  Now they have found a market.  Its time for the professionals to come in, clean up the code, allow the founders to focus on product, get professional managers, etc… and go… go… go…  Unfortunately this is rare, typically terrible architectural decisions will make it challenging for the team to ever get ahead of the fixes to start iterating on the features that customers are telling them that they want.  However, it is frequently necessary to keep analysis-paralysis at bay and get it done.

You can mine, as long as you acknowledge that you are mining.  This is where code and business concept documentation come into play.  It is fine to write terrible code to get to market quickly, as long as you have documented any shortcuts, and in general everything assiduously.  If someone has spent months to come up with a fantastic piece of code but doesn’t document it, it doesn’t really help anyone else learn.  It also makes it difficult, if it ultimately isn’t so clever, for someone else to fix it because they don’t really understand the entire rationale behind what they were thinking when they wrote the code.

The “ramp” of someone getting up to speed with code is largely due to negligent documentation.  You can find this in “farming” companies or “mining” companies.  If someone can read a brief synopses of what a piece of code is supposed to do, why it was supposed to do it, and how, they can typically come to an understanding of what was in the author’s head.  Otherwise, you have a long slog ahead of you reading through the code and either writing out, or mapping in your head all of the possible branches, dead or otherwise.

The secret of success turns out to be so incredibly simple: Work your ass off. Really care about what you’re creating, not the fame or fortune you’ll get. You’ll succeed.

I definitely agree with this part, just focus on your customers.  Make sure they are surprised and delighted when they are using your product.  No one should be in this just for profit.  Mostly because it isn’t worth it.  Coders spend so much time behind their keyboards, they damn well better love what they are doing or building, if they don’t they will quit, or burn out.  This is the real truth behind this developer shortage.  There isn’t a shortage of good developers, there is a shortage of great concepts for them to work on.  If you build it, believe in it, and its awesome, they will come.