如何证明写作规范胜过代码牛仔？

所以我有一个问题.或者说我的朋友有问题,因为我永远不会在互联网论坛上写我的公司.

在我朋友的公司规范写作中,我们应该说,有点未充分利用.有一种根深蒂固的文化,即首先编写代码并稍后提出问题,无论是图书馆例程还是新工具都会给他们长期受苦的设计师造成伤害.

这当然会导致功能部分正确,不正确或完全丢失的情况("哦,只需在尝试任何您想要撤消的内容之前保存").这通常会导致那些糟糕的设计师或测试期间的生产力下降,因为错误修复主要用于正确实施.

我的朋友发现他对编写(和测试)规范的建议一般都很受欢迎.他的大多数同事已经接受了在纸上发现错误假设的美妙感觉,而不是在测试中期的周日晚上11点.Viva La Revolution!

然而,有一些人说他们的任务和键盘之间的任何东西.他们嘲笑实际设计任何东西的想法,然后快乐地放弃编写代码.这些都是资深的,长期雇用的开发人员,不愿意"浪费时间".

问题在于,第二组异教徒总是比第一组更快地产生(或者至少某些东西).随后,这就变成了理所当然:"为像图像缩放器这样简单的东西编写规范是没有意义的!哦,那些宽度!=高度或图像使用RLE的错误只需要一些调整".

现在问题:)

除了在项目结束时"告诉你"之外,有哪些好的短期方法可以证明编写功能或技术规范的实践从长远来看如何能够产生更好的软件？

干杯!

目标是编写正确的软件....规范只是尝试找到/定义正确的东西的一种工具.

我认为作为一个群体,需要决定如何构建正确的事物以及如何在每个人之间进行沟通.

即关注真正的问题,然后就如何解决它达成共识.而不是说,"这是一个问题的解决方案,让我们去做!",这通常不会从每个人那里获得大量买入.也可能是规范也不是解决问题的正确方法.

规格超过牛仔的一个领域是" 范围蔓延 "以及与之相关的成本.

规范是客户和开发人员之间的合同.如果您没有明确的合同,您怎么知道合同何时满足？

此外,具有详细的规范使得两个或更多开发人员可以更容易地同时处理项目的不同部分.而且,它给测试人员提供了一些东西来比较软件,以确保该死的东西有效!

这很困难,因为办公室文化和工作习惯很难改变.如果您对此非常认真,请尝试让管理层同意将规范用于小型项目/模块的试验,并且随着时间的推移量化维护成本(时间,错误等).

你可能不会让其他开发人员这样做,但是比更抽象的开发实践更容易理解.对poo-poo'ers的管理负责该组织的持续就业和绩效评估,这是说服他们改变或让他们在其他地方工作的一种方式.