What I've learned:
* No revolution starts big. Any grand vision has to start from smaller things like scratching your own itch and dogfooding.
* Do not overinvest infrastructure. Do an agile project and remember the vision on the same time.
* Start with the humblest, simplest and dummest thing, then one innovation by another, slowly ramp up your roadmap.
* Only software that does something new is worth writing.
* We engineers need to learn when "DONE" is done.
* Releasing important feature is more urgent than meeting some internal arbitrary schedule.
* Transparency for visibility is different from transparency for collaboration. The latter is much harder.
* "One must imagine Sisyphus happy".
Some wonderful contents:
Despite a host of innovations, programmers have been stuck with the hard slog of debugging. Their work is one percent of inspiration, the rest sweat-drenched detective work; their products are never finished or perfect, just varying degree of "less broken"
"It's like a treasure hunt," Anderson, unflappable, responds: "You have to find the first thing. You have to get the first clue before you're on your way, and you don't know how long it will take."
In practice, Brooks found, nearly all software projects require only one-six of their time for the writing of code and fully half their schedule for testing and fixing bugs.
That's the way Silicon Valley replenishes itself, forest like: The technology companies have always germinated in the enpty space created by the toppling of other companies from a previous wave of growth.
"Engelbart, for better or worse, was trying to make a voilin" -- but "most people don't want to learn the voilin." This tension between ease and power, convenience and subtlety, marks every stage of the subequebt history of software.
Too often, though, we end up with software that's not only confusingly detached from the world we can touch and feel but also unable to deliver on the promise of flexibility and versatility that was the whole point of "going digital" in the first place.
For programmers, just as for writers and artists and everyone whose work involves starting with a blank state, the "funnest" time of a project ofter falls at the very beginning, when worlds of giddy possibilities lie open, and before painful compromises have shut any doors.
But usually the parts of what you need done that your off-the-shelf code won't handle for you are the very parts that make your new project different, unique, innovative -- and they're why you're building it in the first place.
The one that people talk about most is that it's important to actually finish sharpening the axe and get abck to chopping. ... But for me, the big problem with "axe sharpening" is that it's recursive, in a Xeno's pardox kinda way.
Interesting views, excellent facts and wonderful h
《梦断代码》热门书评
-
Dreaming In Code
66有用 0无用 g9 2007-02-14
当年Lotus Development的创始银,Lotus 1-2-3的设计者Mitchell Kapor,离开Lotus后拉开单干,成立了开源应用基金会(OSAF)。他招募了一堆牛程,开发号称革命性的下一代个人信息管理系统--Chandler。我还记得Mitchell Kapor宣布要开发Chan...
-
外国大牛也不过如此
37有用 7无用 庄表伟 2008-09-18
花了一周的时间,看完了《Dreaming in Code》(梦断代码),看得我心潮起伏。对里面那帮家伙的评价也起起落落。最终的结论是:外国大牛也不过如此。别看他们名头那么响,做了那么多超有名的项目,实际的能力(软件开发能力与项目管理能力)看来相当有限。感想很多,想到一点说一点吧。1、以前有一篇文章叫...
-
开源的路在何方?
25有用 1无用 kimi 2008-12-26
在图书馆的阅览室看了这本书,花了我两个小时的时间,午后的阳光透过图书馆的玻璃照进来,很温暖,可是我的心却一点点的凉了下来。 再过半年我,一个计算机系的学生,就要投身到软件开发这个行业中去了,可没有任何经验,仅凭着那些薄弱的理论知识。边看书边记下自己的想法...
-
有关软件工程的焦油坑
16有用 0无用 大徐 2008-09-25
结婚前夕我请假一天,躺在床上看了大半的《梦断代码》,Chandler项目时间从2002年转眼到了2004年,10月26日OSAF发布了 Chandler0.4版。2年时间里,整个项目组的人员从几人上升到了20多人,有人离开,更多的是新人加入。做为一款致力于“无地窖式数据处理”的开源PIM软件,项目组...
-
一身一身的冷汗啊
13有用 1无用 铁观音加枸杞 2008-09-30
这本书看了已经一半多了,就看完的这些部分说点自己想说的。开始看的时候,还是很轻松很调侃的在看老外大牛们的囧事。可是越看越发现这个项目里的很多扯淡的事情其实每天都发生在自己的身边。冷汗啊,一身一身的出,想想以前的很多事情,那真是不停的后怕。 &...
书名: 梦断代码
作者: Scott Rosenberg
出版社: 电子工业出版社
原作名: Dreaming in Code
译者: 韩磊
出版年: 2008.06
页数: 336
定价: 49.00元
ISBN: 9787121066795