1
otakustay 2013-07-06 15:48:13 +08:00
花在开会上了
|
2
cssnote 2013-07-06 16:34:05 +08:00
我觉得要花这样时间必然有他们的道理。
做一个充满bug的产品显然要比好用的、完整的简单不少。 |
3
fangzhzh 2013-07-06 16:35:07 +08:00
花在容错上, 让平庸的程序员也不至于写出致命的bug
|
5
swulling 2013-07-06 16:46:03 +08:00
自己尝试写一个Chrome就知道难度了。
|
6
luoli 2013-07-06 16:50:15 +08:00
功能规划,技术研讨等吧。
|
7
hitsmaxft 2013-07-06 17:09:39 +08:00
规划, 讨论, 开会, 完成原有的维护工作.
公司这么大, 除非boss驱动, 否则很难有完全自主支配的时间, 大部分人还要维护相关的产品线, 不见得新项目就能100%的去贡献代码. 另外等待其它部门的就绪也是要花时间的(法务, 机器采购,存储等等, 后台服务等等) 所以. 速度快慢要看项目的资源情况如何. 回到产品本身. 随便写个能用的东西那是很快, 要上线不出大问题, 前端流量支撑住, 后台服务稳固不down机, 你来试试? 1w pv 和 100w pv 的差距, 不是什么人都能随便hold住的. 而大公司往往人的工程水平参差不齐, 也需要一些时间支付修bug等额外成本 再者, 不是各个都想加班, 慢工出细活不好吗? 互联网时代强调快, 这是有病. 都是打工的, 又不能带来很多收益, 相煎何太急. |
8
hitsmaxft 2013-07-06 17:11:49 +08:00
数亿pv 产品线, 随便改了小东西都要一堆流程保证.
这往往不是水平问题, 而是根本不能犯错. |
9
luikore 2013-07-06 17:35:09 +08:00
因为软件的开发速度 = 1 + log(人数)
|
10
dorentus 2013-07-06 23:30:21 +08:00
稍微跑题一下:digg reader 绝对不是『从技术来说应该比较容易弄出来』的东西吧,在 Google 那种基础设施比较健全的情况下可能会比较容易,但是正常情况下,光要支撑这么大规模的用户,就是很麻烦的一件事情。
|