July 13, 2006

Software development lessons I learnt from Amazon

Category: Entrepreneur,Software development,Technology — by Amit Chaudhary @ 1:19 pm

Though I never worked at Amazon and once did not make it beyond the screening test, there are lessons I learnt from Amazon, from friends who work(ed) there, from others in neighboring companies and from the web.

These are views as a software developer, as a customer I love the company and if all the internet companies were to go away, I would want amazon.com to be last.
1. On work distribution: It is important for developers to know and even run their software, but it should not be more than say 10-15% of a developers job.

Reason being it is a overkill, both in terms of capability and money (Read reason 5. in Joel’s article: Top Five (Wrong) Reasons You Don’t Have Testers)

Background: Amazon teams manage their environment. This means, they know their web servers, the queues and database. It also means, it is common for software engineers sit for hours and upgrade web servers do other similar tasks. Typical backend Amazon engineer will spend 25% of their time, a decent IT person can do.

2. Monitor workload during oncall days\weeks and take steps to reduce it if it is getting out of hand.

If a software developer is on call one week every month and there are enough escalations to keep them too busy, something(quality, workload) is broken.

3. If nothing on core work gets done during certain months or more (Christmas, Harry Potter release), new work will suffer.

Background: Most of software development comes to a halt during these times at Amazon. That is 3-6 months of support and recovery time.

4. Watch why candidates are getting rejected.

Background: An interview candidate got low points on fit and got rejected as he did not seem hard working (12 hour days, 6 days a week.) On the other hand, software development members quit as the work pressure was too much. Another interview focused on advanced core language skills (C++ Template Meta Programming.) which then one never use once you join.

5. Know where small teams fit (Called Two Pizza in Amazon) and where they do not

This will also show up as hurdles due to mixed up priority, lack of predictablity or missed deadlines of cross team projects. Small teams fit well for new projects with minimal dependencies like say, Amazon web services, however for large leaps like search in books. you need VP or Director level buyin and priority setting.

6. The CEO on down should know what is being done at the lowest (Developer) level

Bezos does it like few do. I believe, if it is a startup, a CEO should interview or meet every candidate.
Background: Bezos: I am not worthy on Geeking with Greg


PS: This post got triggered by the Amazon CTO, Verner Vogels posting a comment as follows

the best way to completely automate operations is to have to developers be responsible for running the software they develop. It is painful at times, but also means considerable creativity gets applied to a very important aspect of the software stack. It also brings developers into direct contact with customers and a very effective feedback loop starts.

Hat Tip to Eighty-Twenty

• • •

1 Comment »

  1. Great list, particularly 1-4. On #1, the flip side of that is the dilletante – the programmer who won’t get involved in operations – you can’t afford to have that either. It’s not like operations is beneath a programmer, but it’s just a waste of talent. Ops and programming are distinct skillsets, but each side should be somewhat comfortable doing the other’s job.

    Comment by Gordon Weakliem — July 27, 2006 @ 2:54 pm

Comments RSSTrackBack URI

Leave a comment

You must be logged in to post a comment.

Powered by: WordPress Theme based on Sharepoint like theme from: ADMIN-BG