Cytaty #2

"We have tried to demonstrate by these examples that it is almost always incorrect to begin decomposition of a system into modules on the basis of flowchart.

We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others."

David L Parns
"On the Criteria to Be Used in Decomposing Systems into Modules"
za: http://www.infoq.com/presentations/Architecture-Uncertainty - prezentacja jednego z moich ulubionych "filozofów oprogramowania", który dodaje później:
"Projektujemy wokół tego czego nie wiemy, ukrywamy niewiedzę, aby niewiedza nie była problemem"

Cytaty #1

"People with strong technical backgrounds can covert any task into a technical task, thus avoiding work they don't want to do"

"By pretending the work is somehow abstracted from the people we can transform our interpersonal failure into a mechanical failure. It's much easier to say for example, 'We couldn't get the program working on time, than 'I wasn't skilled enough to help Jack become a better programmer'"

Te miażdżące cytaty pochodzą z książki: Becoming a Technical Leader: An Organic Problem-Solving Approach.