Creating Economies of Scale in Software Development

Planning to be a successful software company

Economies of Scale in Software Development is about planning to be successful.

Software development is rather cheap when compared to physical manufacturing but that doesn't mean it doesn't cost money to create a product or service.

The classic myth of the lone wolf hacker who creates a viral product runs counter to the reality of billions of dollars generated by the software industry.

Elements of a Software Team

Consider the many elements required to create a software product:

Developers (hiring, location, communication, etc.)
Developer tools (IDE, compiler, debugger, etc.)
QA (you do run tests of some sort, don't you?!?!)
Distribution/Release (shrink wrapped or delivered by Internet continuously, it still costs something)
Support (assuming you've actually got users)

Making Software Better, Faster, Cheaper

What can you do to make your software cheaper, faster, and most importantly, better?

1. Use Open Source

(like facebook, twitter, google, netflix). Leverage the crowd and reduce your costs (e.g. not buying software licenses, not paying someone to audit your software licenses, etc.)

Spending money on licenses becomes cost prohibitive for large successful organizations.

More importantly, get the quality of years of development by lots of different perspectives. The homogeneous gets wiped out by a single cause, get diversified!

Concerns about competitive advantage based on your supply chain (e.g. the myth "using Open Source tools doesn't give you an edge") are unfounded as:

a. If your competitive advantage is a "secret supplier" then your business will go bust as soon as anyone else finds out your secret.

b. If you're paranoid enough to worry your competitors are messing with your tools then you shouldn't trust a closed source vendor - keep it in the open where everyone's watching.

Giving back to open source projects you depend on has a multiplier effect: a healthy community project is far cheaper than paying full time to support your critical requirements and has built in support and marketing.

2. Standardization

Consider the trend of large clusters of commodity hardware. Using the same internal development tools means it's easier to focus on the real problems and not get lost in translation.

This doesn't mean sticking to old versions or being afraid to innovate, but make success a formula and not an accident.

Larger efficiencies can be generated by getting a decent level of determinism in the workflow.

This means use the same IDE, the same dependency libraries, communication channels, etc. If you have rock stars that can't learn the common tool or won't teach others why their method is better then you run the risk of a dysfunctional "all-star" time bomb.

This also applies to fairness: office perks, salaries, etc. Make it an organization about transparent achievable results, not a labyrinth of back room exceptions.

3. Reduced specialization (and silos)

System Administrator's whose sole purpose is to watch machines is a dying breed.

An army of QA who manually walk through the same test plan over and over is also legacy.

Start with "DRY - Do Not Repeat Yourself".

Develop automation early and make the process simple and obvious.

(i.e. Amazon's internal conversion to APIs http://apievangelist.com/2012/01/12/the-secret-to-amazons-success-internal-apis).

This also means avoiding purchasing hardware (and the associated inventory/maintenance/overhead).

The more virtual servers you buy the larger volume discount you can negotiate. It's not entirely about cost:

you're renting somebody else's implementation of best practice
you need to make your product number one, distractions from that reduce velocity.

Your feature set will continually grow. (Even with careful pruning).

By looking at software as the solution to quality/delivery/maintenance/etc. you can reduce your running cost to a fraction of what it would be AND be able scale up quickly when you become wildly successful.

Note: people are still irreplaceable but by having a lot more Developers (and less unique specialists) you can distribute the load more evenly.

Getting more cross functional individuals means less silos and less communication gaps.

The network mesh effect destroys productivity if everyone's a separate bottleneck.

4. Make it real

Code that lives solves problems and is valuable.

Uncommitted, unused, and otherwise un-useful code costs money to debug and deconstruct; much worse it costs time.

Continuous integration gets your stable unit tested code some real world bruises. Continuous deployment gets your code crunching data and making users happy.

Critical Leadership

There will be bugs.

Far more important are to ensure the product fits the market and have the ability to quickly fix what's broken - sometimes amputation due to business needs is critical (i.e. how Flickr the photo sensation was born http://en.m.wikipedia.org/wiki/Flickr)

Your team must be able to execute.

You lead them by example (both the late nights and the high fives) and these real people will deliver exponential success.