Lập trình viên không chỉ không được giao một đề bài rõ ràng, đầy đủ ngay từ đầu, mà các yêu cầu cũng thay đổi theo thời gian

Khái niệm::

Trong hầu hết các trường hợp, những người ủy thác xây dựng một hệ thống phần mềm không biết chính xác những gì họ muốn và không thể cho ta biết tất cả những gì họ biết.
Ngay cả khi ta biết các yêu cầu, vẫn có nhiều sự kiện khác mà ta cần biết để thiết kế phần mềm. Nhiều khi vấn đề chỉ được phát hiện ra khi đến khâu triển khai ý tưởng. Một số điều mà ta học được làm mất hiệu lực thiết kế của ta và ta phải quay trở lại. Bởi vì ta cố gắng giảm thiểu công việc bị mất, thiết kế kết quả có thể là một thiết kế không phải là kết quả của một quá trình thiết kế hợp lý.
Ngay cả khi ta biết tất cả các sự kiện liên quan trước khi bắt đầu, kinh nghiệm cho thấy con người không thể hiểu đầy đủ rất nhiều chi tiết phải được tính đến để thiết kế và xây dựng một hệ thống chính xác. Quá trình thiết kế phần mềm là một trong đó ta cố gắng tách biệt các mối quan tâm để ta làm việc với một lượng thông tin có thể quản lý được. Tuy nhiên, cho đến khi ta tách rời các mối quan tâm, ta chắc chắn sẽ mắc sai lầm.
Ngay cả khi ta có thể nắm vững tất cả các chi tiết cần thiết, tất cả trừ những dự án tầm thường nhất đều có thể thay đổi vì lý do bên ngoài. Một số thay đổi đó có thể làm mất hiệu lực của các quyết định thiết kế trước đó. Thiết kế kết quả không phải là một thiết kế được tạo ra bởi một quá trình thiết kế hợp lý.
Lỗi của con người chỉ có thể tránh được nếu có thể tránh được việc sử dụng con người. Ngay cả sau khi các mối quan tâm được tách rời, sai sót sẽ được thực hiện.
Chúng ta thường bị gánh nặng bởi những ý tưởng thiết kế định kiến, những ý tưởng mà ta phát minh, có được trong các dự án liên quan hoặc nghe nói trong một lớp học. Đôi khi ta thực hiện một dự án để thử hoặc sử dụng một ý tưởng yêu thích. Những ý tưởng như vậy có thể không bắt nguồn từ các yêu cầu của ta bằng một quá trình hợp lý.
Thường thì vì lý do kinh tế, ta được khuyến khích sử dụng phần mềm được phát triển cho một số dự án khác. Trong các tình huống khác, ta có thể được khuyến khích chia sẻ phần mềm của ta với một dự án khác đang diễn ra. Phần mềm kết quả có thể không phải là phần mềm lý tưởng cho cả hai dự án, tức là không phải phần mềm mà ta sẽ phát triển chỉ dựa trên yêu cầu của nó, nhưng nó đủ tốt và sẽ tiết kiệm công sức

Điều đó khiến cho Hình ảnh một phần mềm được xây dựng thuần tuý từ lý thuyết là một ảo tưởng. Tuy nhiên, Việc giả bộ là phần mềm được xây dựng bằng lý tính là có ích

In most cases the people who commission the building of a software system do not know exactly what they want and are unable to tell us all that they know.
Even if we knew the requirements, there are many other facts that we need to know to design the software. Many of the details only become known to us as we progress in the implementation. Some of the things that we learn invalidate our design and we must backtrack. Because we try to minimize lost work, the resulting design may be one that would not result from a rational design process.
Even if we knew all of the relevant facts before we started, experience shows that human beings are unable to comprehend fully the plethora of details that must be taken into account in order to design and build a correct system. The process of designing the software is one in which we attempt to separate concerns so that we are working with a manageable amount of information. However, until we have separated the concerns, we are bound to make errors.
Even if we could master all of the detail needed, all but the most trivial projects are subject to change for external reasons. Some of those changes may invalidate previous design decisions. The resulting design is not one that would have been produced by a rational design process.
Human errors can only be avoided if one can avoid the use of humans. Even after the concerns are separated, errors will be made.
We are often burdened by preconceived design ideas, ideas that we invented, acquired on related projects, or heard about in a class. Sometimes we undertake a project in order to tryout or use a favorite idea. Such ideas may not be derived from our requirements by a rational process.
Often we are encouraged, for economic reasons, to use software that was developed for some other project. In other situations, we may be encouraged to share our software with another ongoing project. The resulting software may not be the ideal software for either project, i.e., not the software that we would develop based on its requirements alone, but it is good enough and will save effort
Nguồn:: A Rational Design Process: How and Why to Fake It
Nguồn::

Việc làm sản phẩm thì muốn làm thật ít chức năng càng tốt, nhưng việc viết phần mềm đòi hỏi nên lên kế hoạch các chức năng kỹ càng
Mỗi một nhiệm vụ đều chứa những cái không biết, vì nếu đã biết rồi thì nó đã trở thành thư viện