一个程序员，同样的东西，一个月做出来和三个月做出来到底有什么不同呢？底层架构不同、可预见未来支持的扩展不同、优化不同，可以这么说，从某个角度上说，是完全两种东西。
开发时间的常用评估方式
首先，评估开发时间的问题，两个常见的方式，***种，会从底层程序员往上报自己需要的时间，经过主管、经理再到总监每一层都会多报出一个百分比的时间，以备用来解决不可预知的问题或bug，其实不预估时间的项目往往是最快的，程序员尽力去完成，但在有一定规模的项目组中却不可取，没有哪个老板或投资人会对没有时间规划的项目开发组充满信心。企业也不会任由程序员来规定时间。而报到老板那的时间也会直接被砍一刀，三分之一的时间被砍掉都算是少的。
第二种方式，如果是合同定制的，开发需求非常明确的，一般都会有一个明确的开发周期和时间节点，开发任务会“以终为始”的方式来开展，举个例子，六个月的工期，那么第六个月的时候交付产品，需求、设计、开发、测试各自匹配出相应的时间，在这个时间段内完成任务。只要对方不改需求，时间给的合理，这样反而简单了，一般情况下都可以保证deadline来之前上线交付。
开发时间被压缩的要求，往往来自于不懂行或者没有开发背景的老板，一方面是项目进度、企业进度这类客观性的要求，另一方面是怕程序员偷懒，工作不饱和，自己白付工资这种主观性的考虑，在他们的视角中，开发一套系统，三个月的时间成本和一个月的时间成本是一个简单的数学关系，所谓的高层，从来不会关心你短时间内开发的系统所遗留的问题，那是程序员应该解决的事，而这些问题实际上会像滚雪球一样一直堆积，最终在某个时间段内集中爆发出来，后果就是重写，而我刚好就遇到这么一起事件，项目进行半年后，那边的负责人告知我，他们的系统的架构已经无法再加任何的功能了，只能重写。
我们假定这个程序员的水平在中等偏上，不存在技术水平以及任何情绪的问题，一切都是按照比较公平的方式去比较，现在企业要做一套系统，需求明确度60-80%，为了简化模型复杂度，我们只要一名程序员，这名程序员负责系统的所有的任务，程序员报三个月的开发时间，如果这个时间被无端压缩至一个月，那三个月开发出来的系统和一个月开发出来的系统到底区别在哪呢？
架构不同，决定了对未来可扩展的支持的不同
系统做的可大可小，关键看给的时间，时间不够，即便有能力也会把系统做成小的、扩展性差，为什么呢？程序员都会选择当前环境下的***解，和时间赛跑的项目***解就是，快点上线。底层架构？领导又不关心你操哪门子心。未来可扩展性？表示不关心，只知道项目完不成会更糟糕。反正先让你看到个东西，管他底层是啥样子呢。
举个例子，你的系统是做一个学校的客户关系管理CRM，实现客户的录入、分配、跟进、报名的功能。假如老板或甲方压缩时间，给的时间不够怎么办，那只能做做表象的东西，一个客户表，一个跟进表，两者一对多关联，再加一个用户表和报名表，用户表和客户表一对多关联，客户表和报名表一对多关联，完工。项目做完啦，其它不管了，也没时间管，谁让你给的时间少呢？那上面这套系统哪还有问题呢？程序员报三个月，被老板压缩到一个月，老板是不是赚到了？
同样的东西，压缩时间做出来，老板真的是赚到了吗？
上面那套系统，程序员未来可预见的业务扩展，但由于被压缩了时间，所以底层架构是按照最快最简单的方式来实现的，那架构在哪会出问题呢？问题可大了，比如：1、对方需求没说支不支持多校区，整个数据库设计被设计成了一个校区，想要多校区？不支持的，你们没说，没这个概念。2、班级的问题，你们没提，我们也没给你们加，一个学员可以进几个班，一个班级可以安排多少课，是分开计课时？还是一起计课时，不管你上不上都会划去一节课。3、补课？缴费？退费？补款？没说啊，没说可不没有么？为什么我们不写啊，我们只写你们提的需求里的功能，谢谢。4、操作权限问题和数据权限问题，一个客户的市场收集人、销售分配的人、登记客户的人是三个人？不支持，按需求合同来。5、你还要统计跟进次数？什么，还按部门统计，你们重新提需求文档吧，先把***阶段的给钱给结了。6、访问速度太慢啦？把服务器的性能调一下，多加点钱就好了，服务器费用从每月3000增加到每月9000。
上面简单列出了一些问题所在，有看得见的功能上的完善，还有看不见的架构扩展，你只要不说我们就不写，你压缩时间，我们就压缩你看不见的，一切以时间为准。这样的系统，再来几次新需求，可能就要重翻了，重新翻系统的话，该花费多长时间不会减的。本来多给几个月，这些东西全给做上了，这一压缩时间，多花费出来的时间你还是要给程序员开工资的，别指望靠每天免费加班来榨取剩余价值，程序员离职对项目的损伤更大，并且，项目是公司的，公司是老板的。上有政策下有对策，所以业内有句话是这么说的，得罪谁，也别得罪程序员，否则，***你怎么死的都不知道。而这句话并不是危言耸听，觉得程序员老实好欺负的老板的最终下场都很惨烈。
除了功能和架构以外，还有什么？
那除了功能、和架构以外，还有什么“本应该可以做”，但由于时间原因没做的呢？性能监控和优化、缓存、日志分割和备份、数据库备份、代码重构等等等等，这些东西你做了，别人看不见，不做，对系统交付也不会产生问题，时间紧任务急，被时间压急眼了，不做也罢。
