What every developer can learn from startups

Preview:

DESCRIPTION

My talk on which aspects of agile work in startups and which don't, as well as some general rules of thumb for launching software projects

Citation preview

What every developer can learn from startups

/me #1

Got hooked on startups at Riot-ESearch for “riot on” on YouTube

Startup cult member since 30+ companies totalexpert on failure

/me #2

Do technical due diligence for investors get paid to criticize other's work

Keen on JavaScript the older I get, the more lazy I get

Why write code?

What drives developers?

Self actualizationRespect of others

What drives managers?

???Profit

What drives customers?

Value (for money)

Software development is like ...

… Biological Systems

Evolving, interacting systems

… that nobody quite understands

Everything somehow still works

… but may end up being a monster

How do projects get started?

Somebody thinks they know what others want

raise → build → sell

Should validate their assumption first

sell → build → raise?

Be Lazy

The only projects that get delivered on time and according to spec are the ones that never

get started at all

Customers #1

You're not in the service industry

The customer is not always right!Learn how to say NO, excessive customer collaboration results in bloat

37signals vs. Salesforce

Customers #2

Don't build just for one customer

Discover product market fitYou're building a long term relationship

The Team

Communication overhead to be avoided at all costs, this increases exponentially with team size

Cross functional teams are great, but smaller teams of specialized generalists are better

Rockstars and Ninjas

Developer output varies by an order of magnitude, so finding the best developers (who are nice people) is key

Expectations

It's all about managing themVery hard to do when requirements changeAlmost always means more work

Burn-down & burn-up charts

Milestones

Needed to achieve sense of accomplishment and self worth

Needed for invoicingHaving something working badly is better than having nothing that works well

Embarrassment

“If you are not embarrassed by the first version of your product, you’ve launched too late”

Reid Hoffmann, LinkedIn

Prototypes #1

Changes are easier to make early in the development cycle, but this gets progressively more difficult

Functional prototypes are great for conveying the big picture and user journey

Prototypes #2

Basis for a contractYou do need those sometimesWorks even when you are your own customer

Great for validating the customer

Features #1

Features are like sexLess is moreNot every piece of work can be described as a story or a feature

Features #2

You can think through a feature without implementing it

You can build a feature without rolling it out

Modularity #1

Monolithic systems are hard to reason about

The Unix philosophy is the way forwardWrite programs that do one thing and do it well. Write programs to work together.

Modularity #2

Creating reusable modules is the right thing to doDespite having no visible benefit to end users

Because you don't always want to scrap everything

Open Source

Give away everything you canPromotes your businessRecruiting toolMotivational aid

Technical Debt

“Eventual consequences of slapdash software architecture and hasty software development”

Do take on, as long as you know you're doing it

Failure

Failure is changeEmbrace itLearn from itKnow when to quit

Don't throw good money after bad

Distributed Teams

Increasing trendRockstars and Ninjas are on the road a lot

Meetings are evilTools can help

Operations & Metrics

Roll out updates quickly and often

Trust your developers

It's a numbers gameTrack everything you can

Summary

This is not an exact scienceUse whatever works for youThink about the bigger pictureEnjoy the process, not the end goal

Thank you!

@olegpodsechin

github.com/olegp

Recommended