However, a less insightful decision is to have yellow text on a purple background. I can't force myself to read the whole thing.
[1]: http://siderea.livejournal.com/1241996.html?format=light
My favourite bits:
Waterfall as a expression of power and hierarchy within an organisation, something like: "I tell you, lowly worker, what to do" (my words).
This characterisation of a good client: "These are people who will be a pleasure to work with: they are forward thinking, attentive to detail, serious about this project, and have some idea of what it is they want their program to do."
The idea of a cultural conflict between people who value good design and want to spend time on it, and other who hold it in in contempt. Not something I'd thought about before, beyond some idea that the market doesn't demand quality, and so worth a chew over.
The correct solution space wasn't to abandon dependencies and long range planning, but to recognize that software engineering is a specific type of process engineering that involves partially or completely automated processes.
Software doesn't describe the state of a machine in so much as it describes a process. Often developers don't recognize this so much because many of the terms have been concretized into the operating system (ie, process) and get thought of as a container for software instead of the representation of an automated process working in concert on shared resources.
And consequently software is complete when the process is well-defined and repeatable, not when things are bolted together.
I'm grateful to the author for discussing all these sad things in a very well reasoned way.
On the "yellow on purple" topic:
The Safari browser has a so called "Reader View". That formats (most) pages main content into a simple, very readable style.
There is also https://readability.com which is a full-blown web service tackling this problem.
And as I understood there is an open-source library integrated into Google Chrome which deals with decluttering webpages (https://github.com/chromium/dom-distiller)
Back on topic: People often talk about flow charts when transitioning to software, so the notion is not new. It may be rediscovered for some, but that's why we post or talk about things, right? To test our thoughts? Soon somebody will tell me; hey, have you tried user agent XYZ, it does exactly what you describe.
There's a number of "contrast bookmarklets" that you can use to fix the problem part.
[1] http://megpickard.com/2011/06/nifty-bookmarklet-to-make-web-...
I've often heard coders talk about "logic" as a vaguely intimidating mass noun, as in "ugh, this module is full of old logic, who knows what's going on here?"
The word "logic" normally implies structure, coherence, and correctness. In coding, that's rarely the case. We still need to learn how to code logically.
Writing code that consists mostly of actual relevant decisions seems like an often-ignored art.
Phrase not found.
I hate to be the one to tell you ...
What the idea "hammer" is to wood and metal is the idea "GTA V" to a computer system.
The only difference is, that everyone can tell his computer to configure itself for running GTA with information from its installation package. But one can not simply tell its wood and metal to configure itself to be a hammer with a documentation of how to build a hammer. The documentation is more of a source code and needs a compiler, a craftsman or machine, that could make the hammer with this docs.
That's why I find these commercials about "stealing software" so funny.
"You wouldn't steal a car!" as if it was the same as downloading software.
It isn't.
Stealing a car is more like stealing a PC installed with some software.
Downloading software is more like stealing the documentation of how to build a car in some format that only the materials cars are build of can understand.
On a higher level there are decisions that do not directly define the behavior of the end thing under some specific conditions, but rather apply to the process by which that design happens. Those meta-decisions can also be incidental, and can be felt if you take the end thing as existing in longer time frame.
