考虑人的工作产出为x,时间为t,对应需要支付的成本为s.
那么一个profit=x*t-s
如果令s的支出跟t简单相关则有
profit=(x-c)*t.
简单地,所谓的剩余价值约束工作时长.
这里有两个隐含假设.
一个是x是恒定的,也就是单位时间贡献不浮动.
而是s跟t线性相关.
也就是这里收益和成本都是简单线性描述.
考虑x为一个带一定衰减的函数.
比如X(t) = W*(1-e^-t).
一个bounded by W且随时间增长效率递减的函数.
那么profit=\int_{0}^{t} W*(1-e^{-t})dt - c*t
->
profit=t+e^-t+R-c*t
->
profit=e^(-t) + (c+1)*t + R
如果以天为周期小时为单位计量的话.
大致回报也是线性的.
一般地来说,在给定的时间范围内,只要X的derivative为正的话.
也即是时间计量的margin为正.
那么incentive就自然会是增加时长.
那么如何构造在一定时长后margin为负的情况呢?
最简单的负值构造自然是线性的.
对应的就是抛物线.
即X(t)=a*t^2+b
->
profit=a*t^2+b - s*t
->
profit=W(c-t)^2 + d
在这种情况下才可能存在给定某个工作时长为最优解形式.
如果是存在最大值的话,那么应该有W>0
也就是这个X应该是一个会在某个时间点之后incur performance degrade的曲线.
这不算是一个不现实的约束.
其他的形式呢?
考虑相对一般的形态.
profit=return(t) - cost(t)
或者
profit=\int return(t) - \int cost(t)
对应的return和cost曲线的对t的integral差异.
即投入和成本曲线的差额.
对于单个个体来说,如果需要maximize profit/on return的话.
相对stable的IC曲线应该是会让问题相对简单的.
这就需要每个人的投入产出以及对应的成本是相对可计量/具有统计意义的.
大多数情况下个人的cost是相对可预测/固定的.
所以这个求解的关键在于个人的time investment return的模式问题.
只要产出模型是有正margin的,那么单纯延长时间是没问题的.
比较麻烦的是那些曲线比较复杂,或者根本不连续甚至在一定周期尺度下具有随即性质的.
这种可能是根本没有明确的解析解的.
从群体尺度来说的话.
在数量到达一定程度的时候,个体的模式浮动性特征是比较容易被表征出来的.
也就是说,到达一定规模之后,理论上来说是可以规约到某一种特定的产出模式上作为当个个体求解的.
但是也并不是就一定存在解.
因为形式上来说,解的存在性和形态取决于产出模式.
那么软件工程是或者说应该是什么样的产出模式呢?
可能软件工程这个提法本身就是比较微妙的.
记得上学的时候就有各种CMMI/敏捷/测试/设计模式等方面的各种宏观架构.
各种方法论解构下来不过就是拆解.
背后的逻辑不过就是把不可控控制在一个认为可控/bounded的范围内.
它可能笑起来像金融的risk control/estimate.
但是至少金融有一套稍微能跑起来自洽解释的计量和数值系统.
而软件工程理论是不具有这些特征的.
最后无论以什么方式拆解出来的方案/步骤/方案,最后指向的是一个单一的计量标准.
也就是时间.
是的,金融方面也不过最后会量化为交易价值.
但两者的不同在于,时间的定量本身是未定义.
或者说没有标准的.
就像敏捷提出来优与瀑布或者更传统的软件开发模式的时候.
一个论点就是拆解的时间单元比对方更小,从而更flexible,更能应对各种可能发生的情况.
至少在这个陈述里面,它没有回避说软件开发的难点在于 各种可能发生的情况 这种风险.
但是逻辑上却微妙地归结到更小而短的周期能够让这种风险的发生几率更低.
那么如果这个观点如果是对的话,imply的就是软件开发的风险在与周期长.
这样就实际上陷入了一种递归指责.
或者说是一个逻辑陷阱.
在没有办法定量指出风险的具体含义的时候,提出了解决风险的方式.
所以,能实施成功的话,也只是因为刚好恰当地风险主要因素确实是时间.
那么,软件工程的风险到底是指什么呢?
可能在于软件工程这个提法本身.
coding本身有所谓的工程化的么?
或者说工程化本身的含义是什么.
一般的工程化可能跟接近于科学的定义.
即是一种能够量化衡量的可重复实验/过程.
coding本身是不太具有量化标准的.
就像文章或者绘画.
即使以统计的角度来说,量化能覆盖的也不过是风格上的问题.
但是完全没有能够bound的东西也不尽然.
至少API/protocol算是一种.
但是这是在integrate阶段的.
这个时候才会有简单的satisfied or not.
所以如果软件工程如果说存在的话.
也应该指示的是在delivering service过程中的这些隼合情况.
实际上,这些理论上是包含在automation里的.
包括compile/build/test/deploy基本都是不需要也不应该由人去干涉的.
而是根据各个节点的specifications来judge的.
再回头看那些工具和方法论.
那么当所谓risk出现的时候,大致就是各个pipeline stage的合规情况出现问题.
这时候这些理论是怎么解决这些问题的呢?
并没有.
或者说也有.
因为在这些理论框架下需要满足的constrain是时间.
如果把它作为所有risk的一个proxy来看待的话.
由于这些工具所处理和解决的都是在满足time bounded的前提.
于是在proxy回实际的处理方案的时候,关注点也通常在如何回避对时间的default.
于是实际执行上,如果build或者test或者deploy或者任意阶段出现问题.
那么可能的做法就是直接抛弃约定,做default处理.
所以这里的核心矛盾就在于.
或者说一个简单的模型描述就是.
给定一定的time resources.
以及一组random generated的consumer.
如何用limited的resource去satisfy的问题.
而这个是无所谓解的.
除非是能够bound consumer.
要么有一定的确定可预测的范围,要么具有某种可描述的模式.
所以,归根到底还是know your issue.
没有评论:
发表评论