"Just Enough Software Architecture" xuất bản năm 2010
(georgefairbanks.com)- Just Enough Software Architecture của George Fairbanks bắt đầu từ vấn đề rằng chỉ với kiến thức về ngữ pháp ngôn ngữ hay UML thì rất khó thiết kế được một hệ thống hướng đối tượng và kiến trúc tốt
- Cốt lõi là risk-driven architecting, tức khi rủi ro nhỏ thì tránh thiết kế quá mức, còn với những rủi ro đe dọa thành công thì áp dụng các kỹ thuật chặt chẽ hơn
- Cuốn sách xem kiến trúc không phải là đặc quyền của một số chuyên gia mà là năng lực mọi lập trình viên đều cần hiểu, đồng thời giải thích tác động của các ràng buộc và những thay đổi nhỏ lên thuộc tính hệ thống
- Thay vì quy trình phát triển hay vận hành tổ chức, sách tập trung vào các kỹ thuật kỹ thuật, giúp xử lý các trade-off trong thiết kế của các bài toán từ trung bình đến lớn bằng mô hình hóa và phân tích kiến trúc
- Nội dung gồm hai phần: kiến trúc phần mềm dựa trên rủi ro và mô hình hóa kiến trúc, bao quát các trừu tượng như domain model, design model, code model, encapsulation, component và connector
Năng lực thiết kế không thể chỉ dựa vào kiến thức ngôn ngữ và UML
- Tác giả bắt đầu từ mong muốn viết ra cuốn sách mà bản thân mình đã cần khi mới bước vào phát triển phần mềm
- Vào thời điểm đó có sách về ngôn ngữ lập trình hoặc lập trình hướng đối tượng, nhưng lại ít sách bàn về thiết kế
- Chỉ biết các tính năng của ngôn ngữ C++ không có nghĩa là có thể thiết kế một hệ thống hướng đối tượng tốt, và chỉ biết UML cũng không đủ để thiết kế một kiến trúc hệ thống tốt
Architecting được điều chỉnh theo mức độ rủi ro
- Trọng tâm của sách là risk-driven architecting
- Khi rủi ro nhỏ thì không cần thiết kế quá chi tiết, còn khi có rủi ro đe dọa thành công thì thiết kế sơ sài là không đủ
- Nhiều người ủng hộ Agile cho rằng một phần thiết kế đi trước có thể hữu ích, và cuốn sách này bàn về cách thực hiện “kiến trúc vừa đủ”
- Sách hướng dẫn tránh các quy trình kiểu “one size fits all”, thay vào đó điều chỉnh nỗ lực kiến trúc và thiết kế theo rủi ro đang phải đối mặt
- Phần lớn kỹ thuật có thể điều chỉnh cường độ từ mức quick-and-dirty đến mức cực kỳ chặt chẽ
Biến kiến trúc thành ngôn ngữ chung của mọi lập trình viên
- Cuốn sách hướng tới mục tiêu dân chủ hóa kiến trúc
- Trong tổ chức có thể đã có software architect, và bản thân người đọc cũng có thể là architect
- Nhiều architect muốn mọi lập trình viên đều hiểu kiến trúc
- Nếu lập trình viên không hiểu lý do của các ràng buộc và tác động của thay đổi nhỏ lên thuộc tính hệ thống, các phán đoán thiết kế có thể trở nên lung lay
- Kiến trúc không phải chủ đề chỉ dành cho architect mà là điều liên quan tới mọi lập trình viên phần mềm
Kiến thức thủ tục và kiến thức khai báo
- Cuốn sách tập trung vào việc bồi dưỡng kiến thức khai báo
- Khả năng đánh được quả bóng tennis và biết vì sao mình đánh được là hai chuyện khác nhau; đó chính là khác biệt giữa kiến thức thủ tục và kiến thức khai báo
- Nếu bạn đã là chuyên gia trong việc thiết kế và xây dựng hệ thống, có thể bạn đã dùng nhiều kỹ thuật trong sách từ trước
- Cuốn sách giúp bạn ý thức rõ hơn về những gì mình đang làm và đặt tên cho các khái niệm đó
- Loại kiến thức khai báo này cũng giúp nâng cao khả năng mentoring cho lập trình viên mới
Tập trung vào kỹ thuật hơn là quy trình
- Người thiết kế và xây dựng hệ thống phần mềm phải đồng thời xử lý nhiều vấn đề như lịch trình, cam kết tài nguyên, và yêu cầu từ các bên liên quan
- Nhiều sách về software architecture đã bàn khá nhiều về quy trình phát triển và cấu trúc tổ chức
- Khác với chúng, cuốn sách này tập trung vào phần kỹ thuật của phát triển phần mềm và kỹ nghệ để làm cho hệ thống vận hành được
- Sách giúp tạo mô hình và phân tích kiến trúc để có thể đưa ra các trade-off thiết kế một cách có nguyên tắc
- Đồng thời giải thích các kỹ thuật dùng để suy luận về các bài toán cỡ vừa và lớn, cũng như chỉ ra nơi có thể học sâu hơn về các kỹ thuật chuyên biệt
Thiết kế thực dụng qua nhiều mức độ trừu tượng
- Cuốn sách xem kiến trúc là một hoạt động thiết kế mang tính thực dụng
- Software architecture là một dạng của software design; quyết định thiết kế ảnh hưởng đến kiến trúc, và kiến trúc cũng ảnh hưởng ngược lại tới thiết kế
- Lập trình viên giỏi sẽ đào sâu để hiểu chi tiết các trở ngại, rồi liên kết bản chất của những trở ngại đó với kiến trúc tổng thể
- Phản ánh hành vi drill-down/pop-up này, sách bàn đến các mô hình ở nhiều mức độ trừu tượng, từ kiến trúc đến thiết kế cấu trúc dữ liệu
Cấu trúc và định dạng cung cấp
- Cuốn sách gồm hai phần
- Part I: Risk-Driven Software Architecture
- Part II: Architecture Modeling
- Có thể tải một số chương mẫu dưới dạng một tệp PDF duy nhất
- Bản điện tử được bán trên Google Play, gồm ba định dạng không DRM là ePub, Mobi và PDF, với giá $9.99
- Bản bìa cứng có trên Amazon
- Google Books và Amazon Search Inside cung cấp phiên bản có thể tìm kiếm toàn văn
Phạm vi đề cập và những gì không đề cập
- Cuốn sách tập trung vào software architecture liên quan đến việc xây dựng phần mềm
- Sách giải thích các kỹ thuật để bảo đảm phần mềm đáp ứng các yêu cầu kỹ thuật
- Vì bản thân các kỹ thuật kỹ thuật phần lớn độc lập với quy trình, nên cuốn sách cũng hầu như không bị ràng buộc bởi quy trình
- Sách không bàn đến các lời khuyên về hoạt động quản lý như
- trách nhiệm chính trị của architect
- khi nào nên tổ chức các loại cuộc họp cụ thể
- cách thu thập yêu cầu từ stakeholder
Part I: Kiến trúc phần mềm dựa trên rủi ro
- Khó có thể định nghĩa software architecture một cách thật chính xác, nhưng có một số đặc điểm là rõ ràng
- Lập trình viên phần mềm cũng như kỹ sư ở các ngành kỹ thuật khác sử dụng trừu tượng và mô hình để giải quyết các bài toán lớn và phức tạp
- Software architecture hoạt động như bộ khung của hệ thống, ảnh hưởng đến các thuộc tính chất lượng, trực giao với chức năng, và tác động đến thuộc tính hệ thống thông qua các ràng buộc
- Kiến trúc đặc biệt quan trọng trong các tình huống sau
- khi không gian lời giải nhỏ
- khi rủi ro thất bại cao
- khi phải đối mặt với các yêu cầu khó về thuộc tính chất lượng
- Có thể chọn cách thiết kế giữa architecture-indifferent design, architecture-focused design và architecture hoisting
- Quy trình cốt lõi của mô hình dựa trên rủi ro là đơn giản
- xác định và ưu tiên rủi ro
- chọn rồi áp dụng một tập kỹ thuật
- đánh giá mức giảm rủi ro
- Chương 4 minh họa việc áp dụng mô hình dựa trên rủi ro bằng ví dụ hệ thống Home Media Player
- giao tiếp trong nhóm
- tích hợp các component COTS
- bảo đảm tính nhất quán của metadata
- Part I kết thúc bằng các lời khuyên về cách dùng mô hình và software architecture
- dùng mô hình để giải quyết vấn đề
- thêm ràng buộc một cách cẩn trọng
- tập trung vào rủi ro
- phân tán năng lực kiến trúc ra toàn bộ nhóm
Part II: Mô hình hóa kiến trúc
- Part II tập trung giúp hình thành mô hình khái niệm về software architecture
- Có ba cấu trúc mô hình cơ bản
- domain model: tương ứng với các sự vật trong thế giới thực
- design model: biểu diễn thiết kế của phần mềm đang được xây dựng
- code model: tương ứng với mã nguồn
- Có thể tạo thêm các view là những mô hình thể hiện các chi tiết được chọn lọc, và các view này có thể được nhóm lại theo viewtype
- Việc tạo ra ranh giới encapsulation là một kỹ thuật quan trọng trong software architecture
- người dùng component hoặc module có thể bỏ qua hoạt động nội bộ để tập trung vào các vấn đề khó khác
- người viết component hoặc module đã được encapsulate có quyền tự do thay đổi cách triển khai mà không làm người dùng bị xáo trộn
- sự tự do đó chỉ có được khi encapsulation thực sự hiệu quả, nên sách cũng đề cập các kỹ thuật để bảo đảm điều này
- Sách tích hợp các kỹ thuật software architecture từ nhiều nguồn
- kỹ thuật nhấn mạnh thuộc tính chất lượng
- kỹ thuật nhấn mạnh chức năng
- cách thực dụng để tạo ra mô hình hiệu quả
- cách debug mô hình
- Part II cũng bàn về các lời khuyên để sử dụng mô hình hiệu quả, cùng với những cạm bẫy có thể gặp trong kỹ thuật này
- Mục tiêu cuối cùng là có được một mô hình khái niệm phong phú về trừu tượng và quan hệ, từ đó có thể nhìn hệ thống phần mềm như một huấn luyện viên quan sát trận đấu
1 bình luận
Các ý kiến trên Hacker News
Có ý kiến cho rằng nếu rủi ro quản lý dự án là “lập trình viên chủ chốt bị xe buýt tông”, còn rủi ro kỹ thuật phần mềm là “máy chủ có thể không mở rộng được tới 1000 người dùng”, thì cần phân biệt hai loại này; nhưng theo kinh nghiệm của tôi, chúng không thường tách biệt rõ như vậy
Chất lượng và cấu trúc mã, kiểm thử và tài liệu, cũng như việc dùng các công cụ tiêu chuẩn, phổ biến đều có ích cho cả hai phía
Vì vậy tôi đã nhiều lần nêu giả định “nếu bị xe buýt tông thì sao?” với đồng nghiệp hoặc cấp trên, và nó trở thành một cơ chế gây áp lực để tạo ra phần mềm có thể tái lập và dễ hiểu
Nếu muốn tránh sắc thái tiêu cực về chấn thương hay cái chết, nên dùng “nếu trúng xổ số thì sao?”
Điểm cốt lõi của “bị xe buýt tông” là, bất kể tính cách ra sao, hoàn toàn không có thời gian chuẩn bị, và vì thế nó tạo áp lực phải chia sẻ thông tin ngay hôm nay
Đáng tiếc là tôi vẫn chưa tìm được cách diễn đạt tích cực nào mang cùng hàm ý
Cả hai đều quay lại làm việc sau khoảng một tuần, nên có lẽ cần một ví dụ thảm họa tiêu chuẩn khác
Khi muốn truyền đạt ý chính, tôi thường dùng cụm “người tiếp theo” hơn
Tình huống tệ hơn là burnout: số người vẫn giữ nguyên, nhưng về mặt tinh thần thì họ đã rời đi rồi
Tôi đã thấy nhiều công ty không chịu nổi chỉ chừng đó, dù đó không phải là nghỉ việc vĩnh viễn
Hoặc cũng có thể dùng cách nói tập trung vào động cơ loại bỏ điểm lỗi đơn lẻ, như “tăng bus factor”
Nếu phân tích nguyên nhân gốc rễ thì không nên dừng ở “Larry bị xe buýt tông / trúng xổ số”, vì đó không phải vấn đề thật sự
Kiến trúc chỉ vì kiến trúc là tệ nhất, vì nó làm tăng độ phức tạp một cách không cần thiết
Mục tiêu tối hậu của kiến trúc tốt là giảm chi phí
Nếu vì kiến trúc mà việc phát triển và bảo trì mã tốn nhiều thời gian hơn, thì kiến trúc đó đã thất bại
Đây luôn là vấn đề cân bằng
Vì vậy không có một kiến trúc đúng duy nhất; lựa chọn phụ thuộc vào hoàn cảnh và đôi khi cần được đánh giá lại
Tính linh hoạt đặc biệt hữu ích vì nó cho phép điều chỉnh kiến trúc ở một mức độ nào đó và duy trì hiệu quả ngay cả khi hoàn cảnh thay đổi
Giảm chi phí có thể là một trong số đó
“Mô hình dựa trên rủi ro dẫn dắt nhà phát triển áp dụng tối thiểu các kỹ thuật kiến trúc để giảm những rủi ro cấp bách nhất. Đó là quá trình kiên trì hỏi: ‘Rủi ro của tôi là gì? Kỹ thuật tốt nhất để giảm rủi ro đó là gì? Rủi ro đã được giảm nhẹ chưa, và bây giờ tôi có thể bắt đầu hoặc tiếp tục viết mã chưa?’ Mô hình dựa trên rủi ro có thể được tóm tắt trong ba bước: 1. Xác định và ưu tiên rủi ro 2. Chọn và áp dụng một nhóm kỹ thuật 3. Đánh giá mức giảm rủi ro”
Ta không muốn lãng phí thời gian vào các kỹ thuật có tác động thấp, cũng không muốn phớt lờ những rủi ro đe dọa dự án
Để xây dựng một hệ thống thành công, cần chọn con đường sử dụng thời gian hiệu quả nhất; điều này có nghĩa là chỉ áp dụng các kỹ thuật kiến trúc và thiết kế để xử lý rủi ro khi rủi ro là động lực
Ví dụ, “kiến trúc” cũng bao gồm việc dùng kiểu client-server, trong đó máy chủ không chủ động hành động trước mà chỉ phản hồi yêu cầu của client
Cách này có thể phù hợp với vấn đề, hoặc cũng có thể không
https://www.georgefairbanks.com/assets/jesa/Just_Enough_Soft...
Những kiến trúc sư kỹ thuật được trả nhiều tiền nhưng không làm được bao nhiêu, trong khi áp đặt các pattern khủng khiếp mà các kỹ sư phần mềm phải giải quyết dưới những ràng buộc phi lý như deadline
Kiến trúc tốt cho phép nhiều người hơn tham gia vào sản phẩm
Nếu xuất bản từ năm 2010 thì tôi tò mò không biết nó còn trụ lại được bao nhiêu kể từ đó
Tôi thích “Design It” vì có các workshop và hoạt động hay dành cho những kỹ sư cần tương tác với các bên liên quan hoặc khách hàng
Vì tôi ở vai trò tư vấn nên nó càng liên quan hơn, và tôi cũng thích việc nó không dựa quá nhiều vào các phong cách kiến trúc kỹ thuật cụ thể vốn thay đổi thường xuyên
Tôi đang nói theo tiêu chí nguyên tắc thực tế, chứ không phải trào lưu
Tác giả dành nhiều thời gian cho các bài luận về tư duy, còn kỹ thuật cụ thể thì chỉ lướt qua, nhưng có cung cấp tài liệu để đọc thêm
Nó khiến nhóm xử lý các ý tưởng kiến trúc thông qua những hoạt động cụ thể, và cuối cùng làm lộ rõ điều gì là quan trọng
Cuốn sách của tôi đã cố trực diện xử lý những ý tưởng lớn như vậy, nhưng hóa ra chủ đề quá trừu tượng nên khó về mặt giảng dạy
Kể từ 2010, những ý tưởng nào đã trụ lại? Có hệ điều hành là microkernel, có hệ điều hành là monolithic
Có cơ sở dữ liệu là quan hệ, có cơ sở dữ liệu thiên về tài liệu
Có ứng dụng là client-server, có ứng dụng là peer-to-peer
Những phân biệt này có lẽ là lâu bền, và nếu quay lại sau 100 năm, dù các ví dụ như Windows, Oracle, Salesforce có thể đã biến mất, ta vẫn sẽ thấy các hệ thống có những thiết kế như vậy
Và ta vẫn sẽ nói về các phẩm chất như khả năng sửa đổi hay độ trễ
Lĩnh vực kiến trúc phần mềm là việc nhận diện những trừu tượng lâu bền như thế
Có phần giải thích ngắn gọn ở [2]
“Tóm tắt: Kiến trúc phần mềm là một tập hợp các trừu tượng giúp ta suy luận về phần mềm dự định xây dựng hoặc đã xây dựng. Lĩnh vực của chúng ta từ lâu đã có các trừu tượng nhỏ, nhưng phải mất nhiều thập kỷ mới tích lũy được các trừu tượng lớn hơn như thuộc tính chất lượng, che giấu thông tin, thành phần và bộ kết nối, nhiều góc nhìn, phong cách kiến trúc. Khi thiết kế hệ thống, chúng ta đan kết các trừu tượng này để bảo toàn chuỗi chủ ý, và để hệ thống được thiết kế làm điều ta mong muốn. 20 năm trước, Martin Fowler đã đăng trên tạp chí này bài viết có ảnh hưởng ‘Who Needs an Architect?’. Giờ đã đến lúc các nhà phát triển nhìn lại kiến trúc phần mềm, và xem nó như một tập hợp các trừu tượng cho phép suy luận về phần mềm”
[1] Michael Keeling, Design It: From Programmer to Software Architect, https://pragprog.com/titles/mkdsa/design-it/
[2] George Fairbanks, Software Architecture is a Set of Abstractions Jul 2023. https://www.computer.org/csdl/magazine/so/2023/04/10176187/1...
A Philosophy of Software Design của John Ousterhout rất hữu ích
Có nhiều lời khuyên vững chắc, dễ hiểu và nhiều ví dụ
Tôi không biết bản thân cuốn sách này, nhưng có biết bài viết của tác giả về Intellectual Control, và nó rất sâu sắc
https://www.georgefairbanks.com/ieee-software-v37-n3-may-202...
https://johnwhiles.com/posts/programming-as-theory
Ở công ty trước, chúng tôi từng chuyền tay nhau cuốn Software Architecture for Developers của Simon Brown: https://leanpub.com/b/software-architecture
Nó vẫn chỉ nằm trong danh sách cần đọc của tôi và tôi đã rời công ty đó, nhưng cuốn này được khuyến nghị rất mạnh
Công ty đó cũng dùng mô hình C4 để tài liệu hóa kiến trúc
Tôi tò mò không biết ở đây có ai đã đọc chưa
Các bài nói chuyện về kiến trúc [1] và workshop của ông ấy đặc biệt hiệu quả, và ngôn ngữ mô hình hóa kiến trúc C4 [2] cũng đang thực sự có đà
Tôi cũng có video YouTube [3], nhưng không hiệu quả bằng
[1] https://www.youtube.com/results?search_query=simon+brown+arc...
[2] https://c4model.com/
[3] https://www.youtube.com/playlist?list=PLRqKmfi2Jh3uoMnZdaWmC...
Tôi nghĩ phương pháp luận này lẽ ra nên được gọi là “phụ thuộc vào rủi ro” thì hay hơn nhiều
Vì sao các lập trình viên lại thích cách nói “[X]-driven” đến vậy?
Kiểu trục này dẫn động bánh răng kia, rồi bánh răng đó dẫn động bánh xe
Đó là cách nói rút gọn của “cơ chế mạnh nhất trong cỗ máy tư duy phức tạp này là gì”
Vài năm trước, công ty tôi tổ chức nhóm đọc cuốn sách này, và tôi thấy nó rất lặp lại
Tôi tò mò liệu cuốn sách này có phải là tài liệu tốt cho người bắt đầu một dự án mã nguồn mở không hề nhỏ hay không
Hoặc liệu một nhà sáng lập solo có thu được giá trị gì không; tôi muốn được gợi ý sách hay tài liệu khác hữu ích cho lập trình viên solo
Kiến trúc phần mềm giống với kiến trúc xây dựng thông thường, nhưng phần mềm vẫn chưa có một nhân vật như Isaac Newton, nên có cảm giác như kỹ thuật dân dụng vẫn chưa tồn tại
Theo tôi, người gần nhất cho đến nay là Claude Shannon
Vì thậm chí còn không có đơn vị đo lường
Trong kỹ thuật phần mềm, chúng ta vẫn đang ở giai đoạn “hy vọng nó không sập”
Điều này ảnh hưởng sâu sắc đến năng suất tự báo cáo
Ví dụ, đạp xe có thể cảm thấy nhanh hơn so với lái xe trên những con đường nhỏ ở ngoại ô có nhiều biển dừng, với cửa kính kéo lên và tốc độ 30 dặm/giờ
Nhưng thông thường người lái xe sẽ đến nơi cách đó 20 dãy nhà nhanh hơn nhiều
Nếu không có đơn vị đo lường, mọi người sẽ tranh cãi rằng xe đạp nhanh hơn
Kỹ thuật phần mềm hiện đang ở tình trạng như vậy
Việc tạo ra phần mềm hoàn toàn không giống việc xây cầu hay tòa nhà cao tầng, mà gần với việc thiết kế chúng hơn
Trong các dự án xây dựng lớn, trước tiên người ta thiết kế rồi sau đó mới xây; và việc thiết kế này là một khối lượng công việc khổng lồ
Phải suy nghĩ về mọi thứ, chạy mô phỏng, trao đổi với các bên liên quan, nắm bắt yêu cầu và ràng buộc, cân nhắc chi phí vật liệu, trọng lượng, v.v.
Trong các dự án xây dựng lớn, chỉ riêng việc tạo ra thiết kế thực sự có thể mất nhiều tháng hoặc nhiều năm, và kết quả là các bản vẽ cực kỳ chi tiết bao quát gần như mọi khía cạnh thi công
Thực ra điều này khá giống với việc tạo phần mềm
Những dự án thiết kế như vậy có mức độ bất định và rủi ro cao
Dù vậy, tốt hơn là phát hiện mọi thứ đều sai trước khi bắt đầu dùng đến những nguồn lực đắt đỏ như nhiều nhân công, bê tông và thép
Nhưng bạn đã từng nghe kiến trúc sư nói rằng họ tạo ra một thiết kế cho việc thiết kế để giảm thiểu điều đó chưa? Không có chuyện như vậy
Cùng lắm thì ở một thời điểm nào đó có thể đã có một bản phác thảo hay hình vẽ trên khăn giấy
SpaceX đã đưa một số yếu tố Agile vào kỹ thuật, và điều đó học được từ phát triển phần mềm
Trong phần mềm, bản thiết kế hoàn chỉnh có thể chạy được
Quá trình tạo bản thiết kế là thủ công, nhưng quá trình tạo phần mềm từ bản thiết kế đó thường được tự động hóa bằng trình biên dịch và các công cụ khác, nên rất rẻ; vì thế các nhà phát triển làm việc đó liên tục
Tất nhiên, trước đây không phải lúc nào cũng như vậy
Quá trình tạo ra một bản thiết kế có thể chạy được đương nhiên có nhiều rủi ro, và ở nhiều chỗ có thể có thiết kế trên khăn giấy hoặc bảng trắng
Nhưng khái niệm làm một thiết kế hoàn chỉnh trước rồi sau đó triển khai hoàn chỉnh, tức mô hình thác nước, chưa bao giờ thật sự hoạt động tốt trong phần mềm
Ngoài một vài ngoại lệ, thường không có bản thiết kế cho bản thiết kế
Nếu đọc bài báo gốc của Royce về mô hình thác nước, thực ra từ “thác nước” hoàn toàn không xuất hiện, và ông mơ hồ gợi ý rằng lặp lại có thể là một ý tưởng hay
Kiểu như ít nhất hãy làm thử hơn một lần
Ông hoàn toàn hiểu rằng thiết kế đầu tiên rất có thể sẽ sai
Agile đã tối ưu để loại bỏ bước có giá trị thấp là tạo thiết kế cho bản thiết kế, điều trở nên rõ ràng khi lặp lại nhiều lần
Chỉ là bên ngoài một số lĩnh vực cụ thể, nhìn chung chúng ta phớt lờ chúng
Ví dụ, nhìn lướt qua phần tóm tắt và mục lục này, dường như gần như không có, hoặc hoàn toàn không có, nhắc đến các chỉ số hiệu năng
Kiến trúc có ích gì nếu không xét đến việc máy tính thực sự làm gì?
Ngay cả ở khía cạnh năng suất phát triển hay giao diện người dùng, tại sao không có một mô hình toán học nào mô tả ngăn xếp tinh thần cần thiết để phát triển, thay đổi, mở rộng và quan trọng hơn là sử dụng phần mềm?
Tài nguyên tính toán, dù là của con người hay máy móc, có tác động thực tế và đo lường được đến việc tương tác với phần mềm với tư cách nhà phát triển hoặc người dùng, vậy tại sao chúng lại hiếm khi được xem xét?
Ví dụ, Westminster Palace chắc chắn có các yếu tố kỹ thuật dân dụng, nhưng những đặc điểm mang tính quyết định như kết cấu trang trí cầu kỳ, tháp đồng hồ mang tính biểu tượng và bố cục nội thất phần lớn do các lựa chọn chức năng và thẩm mỹ chi phối
Nhiều phần của phần mềm cũng tương tự như vậy