He is talking about "Internet-style pace of shipping features and functionality every three and six months", which is definitely a challenge for all web products developers. Internet is moving so fast, and it can become distressing for a product developer to keep up with all the new features suggested!
Regarding the CMS developed by Jazar for instance, we have to keep a tonnes of features out, provide our limited set of resources. But if we had 500 engineers working on it, which will become soon a reality once we have released the platform under open source license, we will still need to go through the same selection process, and plan all major releases carefully.
He comes then to scalabitly, load management, etc ...
Then to the comparison between products shipping and services shipping, which is quite interesting. Web is moving from products development to services development (this is my definition of web1.0 => web2.0 anyway). quote:
"Another big difference that I’ve found in shipping products versus shipping
services is that you have to have a real awareness of exactly what effect an
error or failure is going to have on the operations team. You have to ask: Is
this really going to pull an engineer out of bed in the middle of the night? "
an other piece of advice which I will write in big red on my desk - once error or failure happens, which you didn't anticipate - what happens? well, you start panicking, start calling your engineers every 5 minutes for updates, and basically go through a very hard time. At the end, everyone wants to take a break and hear that it will not happen again. you would be tempted to say:"Damn, just watch what you are doing next time, and don't add all these f** bugs in your lines of code". (if you are running your business from your garage and both product developper & programmer, you basically shout that to yourself, which is not very pleasant either). Well, best way to demotivate the troops, and it will not change anything to the issue. The issue is risk management, and should be considered even before drafting the functional requirements.
Phil then talk about new starters:
"New hires tend to want to do complex things, but we know complex things break
in complex ways. The veterans want simple designs, with simple interfaces and
simple constructs that are easy to understand and debug and easy to put back
together after they break."
and concludes with:
"
The best advice is just basically to keep everything as simple as
possible—simple processes, simple SKUs, simple engineering. These systems
get to be very big very fast. I don’t think there’s really any one particularly hard,
gnarly problem, but when you add them all up, there are
lots and lots of little problems. As long as you can keep each of
those pieces simple, that seems to be the key. It’s more of a philosophy, I think,
than anything else.
"
More comments on this interview:
Data trolling and the cached life by ZDNet's Dan Farber -- Worth reading: In the wake of the DOJ's quest for search logs from Google (and the other personal information data banks), Om Malik echoes Scott McNealy's remark from 1999 ("You have zero privacy anyway… Get over it.") in his post about living a cached life. He writes:Somewhere on some server, in some SAN your life is [...]
Jeff clavier: "Hotmail runs on 10,000 servers and involves several petabytes of storage (i.e millions of gigabytes) and serves, according to this Wikipedia article, 221M users who are operating billions of e-mail transactions daily. It is operated by 100 sysadmins, which is not that large a team."
0 comments:
Post a Comment