Date post: | 28-Jan-2015 |
Category: |
Technology |
Upload: | oleg-podsechin |
View: | 105 times |
Download: | 0 times |
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