Innovation and Blogging Software

I don't have anything against innovation - provided it's more useful than the inconsistency it introduces. Tools, including software, are used for other ends, they are not ends in themselves except for a few people who specialize in them, or are otherwise particularly interested in them.

Part of the problem is that different people value different things and, consequently, want different things in their tools. This inevitably introduces complexity, both in the variety of tools available and in the tools themselves.

When browsing the internet and blogs, I am interested in finding interesting or useful content, not in learning to manage a dozen different software systems. There are too many different blogging/commenting systems. For someone interested in finding useful or interesting content rather than in "communing", it is seriously annoying to keep track of how they work.

Standardize somewhat on the blogging/commenting systems. Reducing the number of different systems will lessen the complexity a lot more than adding features to one or another would increase it. Reduce the number of systems by making it easier for current sites to transfer to another system. Reduce forking of projects by making it easy to patch systems to a consistent standard.

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.

Foresight versus Negativity and Pessimism

When I worked remodeling and landscaping I used to try to visualize what could go wrong and head potential problems off while we were still planning the work. I finally got tired of the man I was working for calling me a pessimist and complaining about my negativity and quit saying anything.

Stay well away from anyone who uses the word "negativity". Every time I have heard it used it was an attack on someone attempting to show some foresight.

Creativeness

When you come up with a new idea, review how you came up with it, maybe you can improve it, or do better next time, or learn how to come up with even more ideas.

Spend time thinking - not reading or studying or talking. To get away from my normal "background" I do much of my creative thinking while walking. I keep a notepad in my pocket to write down my ideas so they're not forgotten. The changing, more random, background helps trigger new ideas and new ways of looking at old ideas. And sometimes reminds me of older ideas I had forgotten.

Browsing the web, especially when I push myself to follow links rather than reading more intensively, also has some of the same effects, though it's not as effective as walking - but sometimes the weather is too bad for writing down any ideas I get, either raining or snowing.

You must write down your ideas or you WILL forget them.

Play with ideas, explore unusual or random juxtapositions of ideas. Exploit ambiguity and metaphors to open up new ideas or approaches. Look for **more** solutions or ideas that could lead to solutions. Try changing one of the rules or constraints and see what happens.

Avoid premature evaluation - ideas that don't work can still lead you to ones that can - but only if you keep exploring them.

I prefer "creativeness" to the conventional "creativity", because the latter is too often reified into something in itself. Creativeness (or creativity) is actually a description of the originality of choices that we make - in design and in making decisions.

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)).

Avoiding the GUI

FSF has started putting together a book on the linux command line - Introduction to the Command Line

I wish someone would write a book on avoiding the GUI. I wish even more that I could find fairly recent programs, even for linux, that don't depend on GUIs.

I dislike graphic interfaces, and though windowed programs are sometimes very useful, there is no necessary connection between windows and graphic interfaces. Unfortunately, they have become so conflated in people's, even programmers', minds that they are automatically considered together. One example is the X Window System for UNIX and Linux. You have to be running the graphic desktop to use programs written for X, and because of the libraries and reduced programming overhead, most programmers now write programs for X, rather than for linux. (I'm referring specifically to application programs, in case that wasn't obvious from the context.)

This is NOT an improvement, except in the rather narrow sense that replacing metal with plastic in kitchen appliances or tools is an improvement - it makes production cheaper.

Also, the use of graphics inside a program is not always using a graphic interface. I would prefer that command buttons in programs be replaced with a small command line text box - anyone who has lost information because they accidentally clicked the wrong button can probably understand why, even if the idea never occured to them. I have even opened the wrong program, which I then had to close and open the one I meant, by clicking the wrong icon on the desktop.

Another problem with GUIs is that they are what Mike Gancarz in The Unix Philosophy refers to as captive user interfaces - you have to sit there and keep clicking, you can't just tell the shell what to do and let it run. Including you can't pipe it together with other programs to do a more complex job. In fact X violates most of the UNIX Philosophy.

One of the reasons GUIs have become popular is that everyone seems to think that more users is better, so they are trying to make it easier to get started, apparently figuring that as they gain expertise the suckers (err..., "users") will stick with what they are used to rather than switch.

A better tool is harder to use at first, but as you learn it, it becomes more natural and quicker to use. Typing in a command is much faster than cascading menus and, for someone more than marginally literate, more natural. As far as keyboard shortcuts - most importantly, they should be easily personalized. There are too few reasonably memorizable shortcuts to cover everything, and each expert tends to work in a slightly different (or wildly different) area and will find different shortcuts valuable.

Neal Stephenson's In the Beginning Was the Command Line... gives an interesting perspective on this. It is only fair to add though that he has since changed his stance on some of the issues he raised in the book; though the note I saw didn't say in exactly what respects. I think it excellent as it reads.

Assorted Comments on Tools

Use tools appropriate to your skills and to the job you are trying to get done. Learning to use more powerful tools is one of the best ways to increase your effectiveness.

I am a good draftsman. I can complete architectural, or some engineering, drawings on paper faster and more accurately than with any of the less expensive CAD programs I have tried. I am not going to spend over a thousand dollars on AutoCAD and a like amount on a large printer or plotter without some evidence it would be worth it, especially when the less expensive CAD programs I have tried have been so crappy. And even more so when actually putting them on paper forces a person to think through the details, so I am more likely to catch any mistakes or inconsistencies.

Money is the most flexible tool. It can be used to buy physical or software tools, get information, or have someone apply expertise you lack.

Useful knowledge is a powerful tool; this was clearly recognized by the authors of the "Whole Earth Catalog", its sub-title was "Access to Tools".

If you are making tools for others you need to keep in mind the skills of your expected users, how easy it will be for them to begin using your tool and to master it, to what extent their current skills will transfer, what they will be using your tool to accomplish, how well fitted your tool is to those ends, and the
competition - what other tools the user could choose instead.

Two tools that accomplish the same ends may have totally different groups of users because of other considerations, such as, what is traditional (with training, accessories, and such already available) for the group, which tool is flexible enough to be used for other problems a particular group may have, and cost considerations (for example, most groups would not be willing to spend as much for a tool for an occasional or peripheral job as a tool for a more frequent or central job).

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.