正如DeMarco和Lister在大约20年前在Peopleware中所说的那样,失败的软件项目绝大部分不是由于技术挑战而是社会学问题而失败。在过去的几十年中,无论我们的工具有多大改进,这种情况都没有改变。
管理不善,不切实际的期望,未能找到合适的人选和/或不让他们去做他们的工作,因此未能留住他们;不适合软件开发工作的工作场所和工具;未解决的个人冲突;政治 ; 这些只是一些可能使项目从一开始就注定要失败的典型问题。
为什么编写好的代码更难?
我不太相信现在写好的代码确实比几十年前要难。实际上,与机器代码或汇编相比,我们现在主流的一切都更容易处理。只是我们可能需要生产更多。
仅仅是因为提及因素,时间和复杂性吗?
是的,随着我们工具功能的增强,可以实现的复杂性肯定会增加(并且会继续增加)。换句话说,我们不断突破界限。在我看来,这与30年前解决当今最大的挑战同样困难。
OTOH自从这个领域发展非常迅速以来,与30年前相比,现在存在着更多的“小”或“已知”问题。这些问题从技术上(应该)不再是挑战,但是...在这里输入上述格言:-(
此后,程序员的数量也大大增加了。至少我个人认为,经验和知识的平均水平已经下降,这仅仅是因为不断到达该领域的大三学生要比接受教育的大四学生要多得多。
方法是否没有正确实践?
恕我直言,当然不是。DeMarco和Lister对big-M方法论有一些苛刻的话。他们说没有方法论可以使项目成功,只有团队中的人可以。OTOH他们所赞扬的small-m方法与我们现在所知的“敏捷”非常接近,后者正在广泛传播(恕我直言是有充分理由的)。更不用说单元测试和重构这样的良好实践了,这在十年前还没有广为人知,如今,即使是许多毕业生,也都知道这些。