编程语言与软件工程2021arxiv.org
“我本周会完成”及其他谎言
“I’ll Finish It This Week” and Other Lies
入门 · 约 20 分钟读完前置知识:软件开发流程、项目管理基础、时间估算常识
导读
这篇论文讨论软件开发中的时间估计问题:为什么开发者常给出“本周就能完成”之类过于乐观的承诺,以及估计与现实之间为何会出现系统性偏差。它围绕工期承诺为何不可靠展开,关注技术之外的任务不确定性、人的工作状态与规划方式等因素。
HN 关注点:是因为软件工期估计长期是痛点,讨论焦点集中在心理状态/心流对生产力的影响、短期与长期计划的偏差,以及是否应该承诺 deadline。
HN 评论精选
这几条评论里:支持 1 补充 2 亲历 1
补充估算忽略心理状态与心流波动,工程师不愿承认状态不佳,个体生产力波动大且少被公开讨论。
在我看来,估算与现实的差距在于估算没有把心理状态算进去。更具体地说,我指的是是否进入状态/心流,以及个人是否健康、压力和幸福感是否正常。我们总假设自己能保持稳定产出。以我 20 年经验,从没听过软件工程师对经理说“再加两周吧,我最近状态不够好”。头脑正常的工程师不会把自己置于这种脆弱处境,尤其没人谈论它时。我们天真预期会延迟的,是明显技术相关的问题和没考虑到的边角情况。这个问题在这个领域很突出,除非我漏掉了讨论,我从没见过有人谈。醒来就在状态和不在状态的人生产力差异巨大,而我还没见过哪个工程师或人能每天都醒来就在状态,不可能。虽然个人可以通过降低波动标准差来改善估算,我认为这是技术能力相近的工程师中有人估算更准的关键因素之一。每个工程师都独自面对这种波动/问题。
halayli查看英文原文
imo, the problem with estimates vs reality is that estimates don't include mental state. And just to clarify more about mental state, I am referring to being in the zone / flow, and individuals are healthy and experience normal stress / happiness levels. We assume and expect consistent productivity from ourselves. Anecdotally, In my 20 yrs experience, I've never heard a software engineer saying to their manager "add 2 more weeks on top because my mental state is not at its sharpest these days". No SE in their right mind would put themselves in such a vulnerable situation especially when no one else talks about it. The delays we naively anticipate are the obvious technical related ones and gotchas / cases we might not have considered for the problem. This is a problem that is prominent in this field and unless I've been missing out on discussions, I've never seen it discussed. There is a huge productivity difference between people that wake up in the zone vs any other zone. And I've yet to see an SE or any other human that can wake up in the zone every single day. It's impossible. Although this is something we can improve at an individual level by focusing on lowering the std deviation which will help us estimate better and imo it's one of the key factors why some SEs can give more accurate estimates than others assuming they have similar technical skillset. Each SE deals with this fluctuation / "problem" alone. I've often seen SEs jumping on the management track when the gap between "being in the zone" start to consistently widen. Often after a burnout that never fully recovered. You wouldn't see this being a problem in careers like HR/Management/Sales. Because an individual can still be somehow productive without being in the zone. But in software engineering, art, writing and the like, it's kind of binary and is very visible.
补充短期容易高估、长期容易低估;不必执着于今晚完成,持续投入更重要。
我学到的一个重要事情是:人们会高估自己在短时间内能做的事,而低估自己在长时间内能做的事。你今晚大概率完不成那个功能,这没关系。但只要持续投入一点,一年后你会做出不错的东西。
rognjen查看英文原文
An important thing I've learnt is that people over-estimate what they can do in a short time whereas they under-estimate what they can do in a long time. You probably wont finish that feature tonight, and that's OK. But you will have built something good in a year if you work on it a little bit consistently.
支持软件问题无界,难以承诺 deadline;应按周优先级推进,PM 的话术只能安抚客户。
“永远不要承诺截止日期”——某软件工程师。软件像创意领域一样有无界的问题集合。区别在于,没时间你可以用随想填满一本书,但不能用随想填满你承诺过的代码库里的功能。大型复杂建造(如摩天大楼)也有同样问题,不过因物理约束(场地、机械、材料、平均劳动力产出)可以提前规划很远。我们软件公司每周排优先级,效果很好;我们无法承诺截止日期甚至无法估算,因为变动部分和产品太多。为了让客户满意,产品经理用话术安慰他们,就像销售用一分钱承诺金山。
sublimefire查看英文原文
"Never commit to deadlines" -some software engineer Software has an unbounded set of problems, like in the creative fields. The difference is that you can fill in a book with random thoughts (if there is no time), but you cannot just fill in functional features in the codebase you did commit to. The same issue exists in the very large and complicated builds (eg skyscrapers) although you can plan ahead really far due to the existing physical constraints (site size, machinery, materials, avg. labour output). Over in the software shop I work for, we just prioritize each week. Works really well. And we cannot commit to the deadlines or even estimate, as there are too many moving parts, too many products. To make customers happy the product managers comfort them with words (just like sales people promise mountains of gold for a penny).
亲历按周计划更可行;自由职业者仍渴望组织化目标带来的安全感。
我在一个工作坊和一位教个人组织的人互动,有一次电话辅导。我原以为把计划和日历填满固定事项很重要。她反而建议我按周计划。我是自由职业者,老实说,成为更大、有组织的群体的一部分、由它告诉你该做什么,感觉更好。当你是自己计划的唯一决定者时,感觉很怪:我是不是只能把自认为重要的事填满日程?就像萨特说的,我们自由得令人震惊(存在主义等),但我们仍渴望并向往加入一个有目标可依附的组织化群体,以获得安全感。
jokoon查看英文原文
I interacted in a workshop with a person who taught about personal organization, and we had a phone session. I thought that it was important to fill your planning and calendar with fixed things. Instead she advised me to just plan week by week. I'm a freelance and honestly, it sort of feel better to be part of a bigger, organized group that tells you the things that are to do. When you're the only decider of your own planning, it feels really weird: do I just have to fill up my planning with whatever things I deem of importance? Just like Sartre said, we are shockingly free (existentialism etc), and we still crave and aspire to be part of an organized group with goals we can adhere to, to feel safe.
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2021Hacker News 讨论帖306 分 · 115 评
同领域还值得读
Google 的软件工程(2017)
Software Engineering at Google (2017)
介绍了 Google 的软件工程实践,包括其单一代码库(monorepo)、几乎全部开发在主干进行而非分支、代码审查、构建系统 Blaze、协议缓冲区等工具与流程,并讨论了频繁重…
编程语言与软件工程2017 · 1,127 分 · 465 评 · 引用 15入门 · 约 45 分钟编辑精选Peter Naur:编程作为理论构建 (1985)
Peter Naur – Programming as Theory Building (1985)
Peter Naur 1985 年的经典论文《Programming as Theory Building》提出:编程的本质不是写代码或文档,而是在程序员头脑中构建对程序及其运行…
编程语言与软件工程2016 · 629 分 · 74 评入门 · 约 45 分钟编辑精选SciPy 1.0:Python 科学计算的基础算法
SciPy 1.0: fundamental algorithms for scientific computing in Python
这篇发表于 Nature Methods 的论文介绍了 SciPy 1.0——Python 科学计算生态的基石库,涵盖其核心算法模块(优化、积分、插值、线性代数等)、软件架构与社…
编程语言与软件工程2020 · 387 分 · 98 评入门 · 约 45 分钟编辑精选Lisp 的历史(1979)
History of Lisp (1979)
这是 Lisp 发明者 John McCarthy 于 1979 年为 HOPL(编程语言史)会议撰写的回顾文章,讲述 Lisp 的起源、设计动机与早期演进,文中也涉及 if 表…
编程语言与软件工程2018 · 352 分 · 44 评入门 · 约 45 分钟编辑精选使用 NumPy 进行数组编程
Array Programming with NumPy
这篇 Nature 文章介绍 NumPy 的数组编程模型及其在科学计算中的核心作用:以 ndarray 为中心,通过向量化操作让 Python 高效处理多维数组。
编程语言与软件工程2020 · 318 分 · 134 评入门 · 约 40 分钟编辑精选