What Is a Model?

A model is a simplified, abstracted representation of an object or system that presents only the information needed by its user. For example, the plastic models of aircraft I built as a kid abstract away everything except the external appearance, a mathematical model of a system shows only those dimensions and relationships useful to the model's users, a control system is a model of the relationships between the stimuli and the response desired by the designer and user of the larger system being controlled (evolution as designer and organism as user in biological analogy). A control system doesn't make a model of a system, to a large degree it is the designers' model of the system it controls.

At the simplest end are one-dimensional models, that we call measurements.

The most complex models are not explicit, they are too complex to be explicitly known, much less communicated; the model of the world that each person carries within his own mind.

The Relationship of Software Engineering, Computer Science, and Programming

Computer science underlies programming rather like physics underlies engineering. You can do some programming or practical engineering with rules of thumb and copying from references, but they will ony take you so far.

What is needed for software engineering to become a reality, rather than a glorified name for programming, is a set of reliable principles for designing and building effective software, that is software that works as expected. Prototyping is the currently most effective way of building software, but it is not software engineering; it is an admission that there is not yet a discipline of software engineering.

From what I have read, even the large scale, high reliability programs are built more by careful programming, testing, and debugging than by detailed up-front design, the way large scale engineering projects are.

The main reason is the incredible complexity of software projects. The only physical products that approach software in complexity are large scale integrated circuits.

Software engineering will be an engineering discipline when the development of a new operating system, the associated utilities, and APIs is as predictable and stable as the design and construction of a new skyscraper.

This is all from general reading and memory, if you agree or disagree with me, please leave links to any sources you may have in comments.

Some Notes on Responsibility

Slightly revised version of some comments I left on lesswrong.com - Does Blind Review Slow Down Science?

First I should state that I disagree with anonymous review for the same reasons that I disagree with an unaccountable judiciary - the negative effects on responsibility.

However, there are several problems with the theory in this essay - the most important being that the editors know who the writer or researcher is and can decide to go ahead and publish on that score no matter what the reviewers say. The editors have a strong incentive to advance novel but true theories in that it will advance the reputation of the journal.

About the unaccountable judiciary, you might check out this book by Max Boot, Out Of Order: Arrogance, Corruption, And Incompetence On The Bench, a large proportion of the problems he wrote about arose from judges not being personally responsible for their actions on the bench.

Also, more generally, I am a libertarian largely because I believe that everyone is totally and completely responsible for their own actions. Even if someone is holding a gun to your head, you decide what you do in response (and are responsible for letting yourself get in that position). Or if you are drunk or drugged, you are responsible for putting yourself in that position and therefore for what you do while that way.

By "responsible", I mean that people should bear some part of the forseeable costs of their actions. I say "some part" because the actions of others also influence costs, and stress "foreseeable" because in any complex system things interact to such an extent that only very direct results can actually be attributed reliably to any one party. Most attributions of "fault" in complex systems is scapegoating or motivated by interpersonal status games.

Alarm Clocks, Scheduling, and Deadlines

It's probably better not to set goals in the first place, if you are not going to keep them, than to get in the habit of ignoring them. I make it a point now not to set my alarm clock if I don't have to be up by particular time, and if I do set it to always get up.

Similarly, I try not to set a fixed schedule for things I don't need to do at a particular time. I make a list and work on something from the list (unless something gets near a deadline). I found that having the list also helps me to avoid spinning my wheels thinking about what to work on (provided your list isn't too long, then you have to decide what to work on).

Making arbitrary "deadlines" for yourself, then ignoring them, increases rather than decreases your procrastination.

Are Best Practices the New Mediocrity

Good point - if everyone is doing something it's mediocre, even if it's called "best practices". Probably, the use of "best practices" should be replaced with "standard practices", which is an almost as common synonym, and is more accurate.

The Road to Mediocrity is Paved with Best Practices

KISS: Keep It Simple and Succinct

Succinct means brief and concise, to the point. A succinct argument is one that more directly addresses the point under discussion.

The "traditional" meaning of KISS completely misses the point. The biggest problem KISS addresses is over-complication of plans - and it is not a problem of stupidity. Those most prone to over-complicate are the more intelligent, especially the highly intelligent and highly educated, but lacking in practical experience. Experience, especially wide experience, is the best prophylaxis for over-elaborate plans.

In large-scale planning, especially where the planner cannot see it through to completion or which has too many complications, it is easier to come up with excuses as to why it didn't work out than to actually figure out what caused any problems.
It is human nature to try to explain mistakes away - if you want to get better though you need to avoid situations that make it easy to do. Almost all government projects fall into this group, which is why many who tend towards libertarianism have practical experience and have dealt with the government enough to understand the way it actually works . (Former police, former military, and engineers, for example, tend to be over-represented among libertarians (in my reading and experience anyway, I haven't seen any really reliable statistics)).

Optimism - Dangers and Benefits

Optimism is not necessarily as beneficial as many proclaim.

The pessimist complains about the wind; the optimist thinks it will change; the realist adjusts the sails.
-- William Arthur Ward

Optimists may accomplish more than realists, realists certainly accomplish more than pessimists, but optimists do many times as much damage. For example, nearly all "revolutionaries" and criminals are optimists. Lenin, Hitler, Sadam Hussein, Bernie Madoff, and probably all con-men and burglars were extremely optimistic. The conviction that they will never be caught is nearly universal among criminals. Many, perhaps most, excessive risk takers are optimists.

An unsuccessful optimist never learns. He is one of those fools who is sure everything will work out all right, but who does nothing to make sure it will. A successful optimist will learn from his mistakes and keep working at his problem.

Some work almost requires optimism, because the work is so tedious, for example, Fred Brooks in The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition) says:

All programmers are optimists. Perhaps this modern sorcery especially attracts those who believe in happy endings and fairy godmothers. Perhaps the hundreds of nitty frustrations drive away all but those who habitually focus on the end goal. Perhaps it is merely that computers are young, programmers are younger, and the young are always optimists. But however the selection process works, the result is indisputable: "This time it will surely run," or "I just found the last bug."

If you have a choice, you should plan for the worst and hope for the best, or as Lazarus Long put it "Pessimist by policy, optimist by temperament - it is possible to be both. How? By never taking an unnecessary chance and by minimizing risks you can't avoid. This permits you to play out the game happily, untroubled by the certainty of the outcome." (Robert A Heinlein, Time Enough for Love.) Take precautions then just enjoy yourself knowing you have done what you can to prepare.

Another view from David Weber and Eric Flint's novel, Crown of Slaves (Honor Harrington):

But if the expression "optimistic paranoiac" hadn't been a ridiculous oxymoron, it would have described Ruth fairly well. She seemed to take it for granted that half the human race was up to no good, even if the knowledge didn't particularly worry her much - because she was just as certain that she'd be able to deal with the sorry blighters if they tried to mess around with her.

From the unix fortune-cookie program:
pessimist: A man who spends all his time worrying about how he can keep the wolf from his door.
optimist: A man who refuses to see the wolf until it seizes the seat of his pants.
opportunist: A man who invites the wolf in and appears the next day in a fur coat.

Getting Things Right by Avoiding Mistakes

I recently sold my copy of :

What Made Gertie Gallop? : Learning From Project Failures

by O. P. Kharbanda and Jeffrey K. Pinto

and wrote this review for Amazon when I did:

Useful and Readable, March 8, 2009

The projects reviewed here are old enough that they have been analyzed well enough for fairly complete understanding to be possible. The mega-scale of the projects makes them less than directly applicable for most readers, but their large scale makes for a completeness in their management, smaller projects frequently skimp on their formal management and are usually less well documented, that makes for a better analysis.

The techniques are well illustrated by the projects chosen and the writing does not get in the way of the analyses. This book is very clearly written, the individual project analyses can almost be read like short stories, but with the added benefit of being factual.

For those more interested more in a popular treatment of engineering failure than project management failure I recommend Henry Petroski's To Engineer Is Human: The Role of Failure in Successful Design. I mention this because when I bought this I thought this book was more on engineering failure than it was; a lucky mistake since it turned out to be more interesting and useful than I expected.


I think that reading about mistakes and errors is more useful to improving your own functioning than reading about positive techniques. As Marcus Ranum put it in "The Six Dumbest Ideas in Computer Security", "It is often easier to not do something dumb, than to do something smart."

The single best means of getting things right is to not do them wrong. Doing some reading in advance of starting a project is a good idea, but much more important is being careful while working - stopping when necessary to think things through or check reference works.

G Harry Stine in his The Hopeful Future wrote, "A self-taught person is usually deficient in one or more areas of his learning expertise."

Stine is a technocratic engineer, one of what Postrel calls a stasist in her book The Future and Its Enemies: The Growing Conflict Over Creativity, Enterprise, and Progress. Stine's book quoted above calls for planning the future, despite the inherent impossibility, and undesirability, of that task. Besides the general antagonism to his authoritarian, control-freak planning, I object to the quote above for more specific reasons. First, as phrased it is meaningless, what I think he meant is that a self-taught person may not be as "well-rounded" as he or some authority thinks they should be. Second, is why a self-taught person should care about someone else's judgement of them, unless that other is a potential employer, in first place. Third, if a self-taught person discovers he or she needs to know something that they missed earlier, they simply need to go find it out.

What Went Wrong?, Fourth Edition: Case Studies of Process Plant Disasters is a catalog of hundreds of things that have happened in chemical engineering plants. I own and have read an earlier edition not available from Amazon, but have examined this edition in a book store and it has even more case histories. Many of the case histories are widely applicable to many other situations.