Taxonomy of Chatbots

Chatbots are a recent trend in user interface. To contrast with a two-dimensional visual UI, a chatbot is a linear time based interface, where the user does an action, there is a response from the system and then the user may act further and so on with the system. The term 'chatbot' comes from a typing 'chat' system that acts like a Turing test robot in an online question response sequence. Some of the things that are called 'chatbots' don't superficially seem like this (they don't all attempt to be linguistic systems), but they are a linear action-response loop, which seems to be the defining characteristic/

By recent trend, I mean, as usual with technology, they've been around forever (Weizenbaum's ELIZA Rogerian psychotherapist from mid 60's, phone menus or IVF from 70's). But as of 2017, there is an explosion of available chatbot technology and, orthogonally, chatbot marketing.

The point here is to to give a superficial systematization of the different things labeled 'chatbot' with examples.

There are two distinguishing characteristics of chatbots that are only leniently considered defining: sequential response and natural language input (either by text or speech). These two might be combined to be called more formally a Linguistic User Interface (LUI) in contrast with a graphical user interface (GUI). The natural language part underlying many of these is some kind of speech-to-text (S2T) mechanism to get words from speech and some NLP processing to match the words to the expected dialog. The leniency about sequential may come down to a single step (the shortest of sequences possibly not even considered a sequence at all) and about language (a label for a button is language right?). With those caveats, on to the taxonomy.

• linguistic interfaces
• Siri/Alexa/OK Google - intent/entity/action/dialog. stateless giving, commands to evoke an action. Development of the system involves specifying: an 'intent', something that you want to happen, the entities involved (contacts, apps, dates, messages), and actions (the code the really executes based on all that information. Oh, and the more obvious thing, a list of all the obvious varieties of sentences that a person could utter for this. The limitation is that there is no memory of context from one action request to the next.
• chatroom bots - listeners in a chatroom (mostly populated by people writing text). 
• helper commands - This kind of chatbot simply listens to text and if a particular string matches, executes an action. This doesn't need S2T, and usually no NLP. It relies on text pattern matching (usually regexes) to extract strings of interest. Usually it turns out the implementation is even simpler and just uses a special character to signal a command for a CLI (command line interface) follows.
• conversational bot
• Like Eliza, finds keywords or more complicated structures in a sentence and tries to respond to it in a human like fashion (good grammar, makes sense). The latest ML and machine translation techniques (RNN, LSTM, NER) seem to apply best here.
• 'AGI' - artificial general Intelligence- these exist only in TV/Movies. 
• menu trees - structured tree-like set of possibilities, 'Choose You Own Adventure'. These are very much like (or exactly) finite state automata, where the internal state of the machine, and presumably but not necessarily mirroring the mental state of the user, is changed by a simple action of the user. The user is following a path through the system.
• phone menus - Historically, these are menus, a set of choices, spoken to you, expecting a response of a touch-tone number (Dual-Tone Multi-Frequency - DTMF. A recording lists a number of options and the phone user is expected to press one of the numbers associated with that option. Then another option is provided and so on until an 'end' option is chosen or you're transferred to a human operator.  Interactive Voice Response or IVR is this same interface allowing responses by voice also. A next level of feature augmentation is to allow the user to speak a sentence to go to the desired subtree quickly, skipping over some steps. This shows how the strict computery menu as implemented on a phone is slowly evolving towards a conversation.
• app workflow - some desktop/phone apps offer an interface that leads you through data entry sequentially. The user is provided with a set of buttons with labels, and the choice of button leads to a different next question depending. Instead of buttons, one might enter some short text, but again this can lead to different new questions by the interface. The text is not intended to be a full sentence, but simply a vocabulary item, allowing a more open-ended set of possibilities than a strict set of buttons without the necessity of parsing. This is the least chatty of chatbots, but like the phone menus may be considered a sequential but non linguistic UI that can be considered a precursor to a more language based one.

It seems strange to call all these bots. I find it natural to call only the conversational bots by the label 'chatbots'. It turns out that marketers have used the term 'chatbot' for all of these. They surely all share some aspects of a chatbot, but it doesn't feel like the name until you're actually chatting.

Testing Software and Machine Learning

Testing is a major part of any non-trivial software development project. All parts of a system require testing to verify that the engineered artifact does what it claims to do. A function has inputs and expected outputs. A user interface has expectations of both operation and ease of interaction. A large system has expectations of inter module operability.  A network has expectations of latency and availability.

Machine learning produces modules that are functional, but with the twist that the system is statistical. ML models are functional in that there are one-to-one correspondence between inputs and outputs, but with the expectation that not every such output is ... desired.

Let's start with though with a plain old functional model. To test that it is correct, you can test the output against all possible inputs to check if. That's usually not feasible, and anyway is in the more esoteric domain of proving program correctness. What is preferred is instance checking, checking that a particular finite set of inputs gives exactly the corresponding correct outputs. This is formally called 'unit testing'.  It usually involves simply a list of inputs and the corresponding expected outputs. The quality of such a set of unit tests relies on coverage of the 'space'. Edge cases (extreme values), corner cases (more than one variable in an extreme value), important instances, generic instances, random instances, etc. Also, any time a bug is found and corrected, the faulty instance can be added to the list to ensure it doesn't happen again.

An ML function is, well, but its name, also functional, but the expectations are slightly different. An ML model (the more technical term for an ML function) can be wrong sometimes. You create a model using functional directly corresponding inputs and outputs, but then when you test on some new items, most items will have correct outputs, but some may be incorrect. A good ML model will have very few incorrect, but there is no expectation that it will be perfect. So when testing, a model's quality isn't yes or no, that absolutely every unit test has passed, but rather that a number of unit tests beyond a threshold have passed. So in QA, if one instance doesn't pass, here it's OK. It's not great, but it is not a deal breaker. If all tests pass, that certainly is great (or it might be too good to be true!). But if most tests pass, for some of 'most', then the method is usable.

There are three major parts to creating a machine learning model that need to be tested, (where something can go wrong and where things can be changed): the method or model itself, the individual features supplied to the model, and the selection of data. The method or model itself is the domain of the ML engineer, analgous to regular coding.

I can almost go so far as to say that testing is almost integrated to a large part already within ML methods. Testing use systematic data to test the accuracy of code; ML methods use systematic data in the creation of a model (which is executable code). And so if an independent team, QA or testing, is to be involved, they need to be aware of the statistical methods used, how they work, and all the test-like parts to the model.

Let's taking logistic regression as an example. The method itself fits a threshold function (the logistic function) to a set of points (many binary features, one continuous output feature between 0 and 1). Immediately from the regression fitting procedure you get correlation coefficients, closeness of fit, AUC and other measures of goodness. There are some ways to improve the regression results without changing the input data, namely regularization (constraints on the model), and cross validation. For the features, mostly independent of the method), first there are the number of features, how correlated they are, how individually each feature is predictive; each feature could be analyzed for quality itself. And last for the selection of data, also independent of the method, there's selection bias, there's separation into training, validation, and test sets.


Where QA can be involved directly or indirectly:

- ensuring metric thresholds are met - analogous to overseeing unit-test coverage of code)
- questioning stats methods (like being involved in architecture design
- cross-validation - both makes the model better (less overfitting) and returns quality metric
- calibration of stats methods - quality of prediction
- test and training data selection - to help mitigate selection bias
- testing instances - for ensuring output for specific instances (must-have unit tests)
- feedback of error instances - helps improve model
- quality of test/training data - ensuring few missing values/typos/inappropriate outliers
- UX interaction of humans with inexact system - final say - does the model work in the real world via the application, has interaction with people shown any hidden variables, any unmeasured items, any immeasurables, any gaming of the system by users.

The latter seems to be the most attackable by a dedicated QA group that is functionally separate from an ML group, and all the previous ones seem to be quite on the other side, only the domain of ML to the exclusion of a QA group. But hopefully the discussion above shows that they're all the domain of both. There should be a lot of overlap in what the ML implementers are expected to do and what QA is expected to do. Sure, you don't want to relieve engineers of their moral duty to uphold quality. The fact that QA may be looking over quality issues doesn't mean the data scientist shouldn't care. Just as software engineers doing regular code should be including unit tests as part of the compilation step, the data scientist should be checking metrics as a matter of course.

I'm so sorry, Clippy

Clippy was Microsoft's 'intelligent' assistant that they added way back to MS Office 97.

Holy crap is that goofy looking! And those animated eyebrows were even goofier! And then he'd ask you really annoying questions like "Do you need help with that?" to things you don't need! Gah!

That was the general reaction. Clippy was universally mocked. Reviled. Other bad things.

But really, was it so bad?

Lately (20 years later) it seems that everyday a new 'assistant' is coming out. Siri, Cortana, Alexa, chatbots up the wazoo. Clippy asked you more questions, based on what you were doing and had answered already, just like a good chatbot. You didn't write to it natural language, but the intention was the same, help out the user by asking questions back and forth.

It was context dependent (Siri is not). It followed a decision tree to maintain context (most current chatbots have trouble with context). It doesn't use speech (like S/C/A) or even typed natural language (chatbots), but it was still an assistant to do things you weren't sure about doing.

Clippy didn't try to do NLP, but frankly the non-speech part of S/C/A and chatbots, just the text, is mostly picking out keywords using hardcoded scripts, not terribly different from hardcoded trees.

So what was so bad about Clippy?

The idea was right, lead people through tasks they are unsure how to do. The implementation as decision trees was both easy and well integrated. What the decision trees helped with...well maybe that wasn't so great. I know I turned off Clippy immediately because I knew what I wanted to do (haha no comment people from twenty years ago!).

But was that the main problem?

I believe the main problem was... the first thing I said, the superficially distasteful graphic and its smarmy animation. It wasn't with the suggestions (though those may have been too simple) it wasn't the use case (helping to write a letter) which was surely too simplistic, but it was just never pursued (unlike the more popular and well-deserved complaints about MS PowerPoint's Auto Content Wizard, a not too dissimilar concept to the assistant).

The problem was the front face of the feature. A weird laughable graphic. I'm sure the idea team thought it was cute and would draw people in with its informality. Fashion is hard to gauge. But the universal response of cringing was no fashion statement. It's hard for those people inside the design team/the makers to see what outsiders see. And sometimes organizations can be too...polite (I know I know, crazy. Sometimes people just don't tell you what they really think).

The major lesson of Clippy is that when designing an assistant/chatbot,  first avoid smarmy (and get honest opinions). The second, which is not a lesson that people normally take from Clippy because they already turned it off because of the first point, is to make the assistant relevant (I know that's a bit broad). That is, make it help people with things they really want. SOmetimes wording makes a big difference "Do you want help writing a letter?" Of course not , I know exactly what I'm going to say to that lawyer! "Do you want help formatting a proper legal letter?" Oh. Right. Yes. Where does the return address and salutation and letterhead go? Yes, that is what people want to be asked for and helped with. So even the subtlest wording can make a difference. The third lesson? Remember the context of prior questions. It just makes things easier for a human.

But what really killed Clippy? Just the graphic. Nothing else, whether substantive or not, really came into play.

What are really the problems with EHRs

There are a lot of complaints about EHRs (2016). Too much useless typing, too many clicks to get what you want, records are not really available. scanned documents are a pain, release forms take forever.

The intended benefits of an EHR are obvious. Data gathered about a patient should be available to everybody who needs to see it, quickly and seamlessly, just like all the other rocket science apps that track our dating.

I see two major problems: data sharing, and user experience.

• Data sharing - electronic health records was never a community service. When a doc or medical situation of a small team needed an IT solution, it was solved only for that particular team or doc. Nothing was intended to be shared. This creates the data silos. It would be a perfect metaphor except real silos can exchange grain so easily just by trucking it over. There is also the other turn of phrase, standards, of which there are, comically, many. There's no universal heath record, or even univesal health patient identifier.
• User Experience, both data entry and retrieval. The pencil used to be the universal recording medium. It was infinitely creative, hobbled a bit by legibility. Typing is so ... easy... that you're expected to do it constantly, but you can't draw. For retrieval, the current EHRs have at best the most rudimentary search. The EHR for a single patient reads like an electronic phone book: if you know what you're looking for you can find it, but it doesn't tell you what the town is like. Everyone complains that you get a lot of data but you just don't get what is happening to the patient.

It's annoying to hear complaints with out solutions. For once I feel I have some.

• Data sharing - the world is going to have to spend some time and money making a universal health record, just like a utility. It's not difficult to do, it just takes some desire and money
• UX - there's a lot of deeply -thought out UX design that could happen. But really just a quick modification to the 'facesheet': add a 3 line text box for a few notes about current status. A lot more could be done but that would change things radically.

These problems are not rocket science. Technologically they are simple. Maybe labor is involved but not much thought.

Cognitive computing is AI rebranded from the point of view of an app

Artificial Intelligence is whatever it is about computing that is sort of magic. As users we don't know why exactly it works but it just does. As builders it's like the dumbest of magic tricks: fast hands, misdirection, brute force beforehand. Sure a lot of research has gone into clever math for it, but once you look behind the curtain, you realize the excitement of the builder is in fooling the user, passing the Turing test by whatever means necessary. (I exaggerate considerably for effect. There's lots of rocket science behind the curtain, but what distinguishes it from algorithms is that it embraces inexact heuristics rather than shunning them).

AI doesn't have to be electronic. It could be mechanical, like a ball-bearing finite state machine that computes divisibility by three, or biological (like a chicken taught to do tictactoe). The chicken winning is magic. The brute force is determining the tictactoe decision tree then teaching the poor chicken. In the end, AI is mostly just computers.

It is usually something that humans are only able to do: language, vision, and logic.

AI is often used for just a heuristic such as the game 2048. The AI used to try to get a better score is essentially heuristics found by a good human player that were then coded as rules in a deterministic program. When you open the hood, there's no rocket science, it's just "always make a move that keeps the highest item in the corner", a human thought that is better than random and better than a beginner, but not perfect. An airline flight suggester is just (OK it is sorta rocket science) a special linear optimization problem (on a lot of data). Linear optimization is usually not considered AI but let's not quibble.

AI usually means that some learning was involved at some point but usually that learning is not continuous, learning in operation. Probably some ML algorithm was run on a lot of past data to generate a rule and then set in stone (until another pass on more recent data updates the rule).

The short history of AI is that it was invented/named in the late 50's, expected to solve all problems in a couple years in the mid 60's

Cognitive computing is IBM's way of reintroducing AI to consumers. It's not AI, but it's not not AI. That is, it is AI dressed up as usable applications or modules that can be fit together to give the appearance that a human is behind it without having an actual human having to step in to do it. The usual list of properties that a cognitive computing app has are: awareness of context of the user, giving the user what they want before they ask for it, they learn from experience, deals well with ambiguity. But then it will probably also incorporate human language input or visual pattern recognition or thinking through a number of inference steps.

Do you need an app that'll give you a new good tasting recipe for tacos? Deciding what's best is probably a good human task (but shhh we have an ML algorithm that figured out what are good ingredient combinations). Do you need an app that suggests to you good personalized travel plans? And now for something actually practical, do you need an app that will help discover cancer cures from buckets of EHR data?

All of these are not the usual single narrow one-off AI apps (back up a trailer, distinguish cats from dogs in images, compete in rock paper scissor competitions).

Without a doubt, cognitive computing is totally a hype/marketing term, new enough not to be some old over-used baggage-laden term like AI, not misleading (these are all sort of thinking apps) and vague enough to allow all sorts of companies to jump on the bandwagon with "Why yes, we've been doing cognitive computing before the term was invented!"

But hype terms can be useful. Cognitive computing is a good label for engineering a combination of features, some that are traditional AI and some that are just good design that are becoming more obvious to have. Whether it's the machines doing the thinking in silicon, or the engineers doing some extra thinking in design, as long as the machine looks like it's reading your mind then that's a good app. It'll be useful if it catches on.

Where is the universal electronic health record?

It's the 21st century. Where is our universal electronic health record? The one where all the medical knowledge about us individually is viewable by any doctor anywhere. You know, you get a yearly flu vaccine at your local drug store, and show up at the nearby emergency room for a sprained ankle, but when you go to your yearly checkup with your doc near work, they have no idea! Forget about it being possibly available when you're on vacation and get food poisoning and go to a non-local hospital.

In the middle of backest-woods China I can show up at an ATM for cash. On a flight 40,000 feet over the ocean I can get wifi to check on who was in that movie with that actress in that TV show. But in Boston, in the best place to get sick in the world, with every hospital connected with multiple medical schools, and every doctor with an MD and PhD and leader of the field that covers exactly your problem, you still have to, after getting a CT scan, walk down the hall to pick up a CD to physically deliver it yourself to your assigned specialist's office next door, nominally part of the same hospital network, but only financially connected, not electronically (oh, it is electronically connected, just not for that one thing. Oh, and the other things too which you'll have to walk back and get).
. 

What's the point (other than that EHRs suck (and not just for the lack of interoperability))? The point is that the technology, the capability, and the knowledge to implement seamless connection for all electronic health data (images, reports, visits, medlists) was possible in the 70's ... with 60's technology. There is no rocket science here (a little electronics and programming sure). It is about as complex as ATMs. The internet should make things that much easier. But for whatever reason (oh there are reasons) it isn't there.

(that's not Jimmy Carter, it's a made up person for HIPAA compliance)

http://www.theplaidzebra.com/first-manned-mission-to-mars/

It is the year 2015, and there are plans to send people to Mars, so there is no technological reason why an interplanetary health record (IHR) doesn't already exist for use when they show up there. The record of the infection you got training in the desolate arctic landscape of Ellesmere Island. The dosimeter readings while stationed temporarily on the L2 jump-off station. Your monthly wellness-checkup with your PCP (well, remotely).

Right now all you get is your intraoffice electronic health record (that is, within an office, not between). It would work great if your PCP, endocrinologist, and cardiologist all belong to the same practice. Of course they don't. Sometimes you're lucky and a big hospital will be the only center for an area and all docs belong somehow to that one hospital. I'm not saying things are bad everywhere.

Wait. Expletive. I can't go to any local drugstore (again!) to get an over the counter bottle of Sudafed, some batteries for a game controller, and a jug of bleach for my socks without stormtroopers crashing through the windows, hog-tying me, and interrogating me on suspicion for running a meth lab (I mean every time), because I went to another drugstore across town for that very suspicious flu shot. At least somebody can connect systems. I was almost happy that they cared! About me!

Enough idle complaining. My idle blaming is that it is the health care businesses's fault. The docs are doing their job as well as they can. The businesses don't get anything out of making things easier on the patients or docs. I have all sorts of constructive suggestions just no one likes advice.

AI: concerning but not evil

Clarke's Third Law: Any sufficiently advanced technology is indistinguishable from magic

Hawking, Musk, Wozniak. A new line of men's cologne or a cabal of reactionists against the benevolent Skynet overlords who just want to harvest human energy? Don't worry, it won't hurt.

Neither, of course. What scent could 'Wozniak' possibly be? Grizzly bear breath?

All they did was sign an open letter  stating concern over ethics in artificial intelligence, that researchers and implementers should be aware of the unintended consequences of the things they build (which are intended to do human like things but may not be ... perfect).

Frankly I've overstated the letter's case quite a bit. They call for "maximizing the societal benefit of AI". Wow. Earthshattering. We never knew. It's pretty weak.The strongest thing said there is:

Because of the great potential of AI, it is important to research how to reap its benefits while avoiding potential pitfalls.

That was the single mention of anything coming close to not positive. 'Avoid pitfalls', that doesn't seem too extreme. Don't step in puddles. Don't close a door on your fingers. Thanks for the tip.

Sure there was press about it and interviews and off the cuff fear mongering, based on years of anti-science science-fiction, where the interesting story is the mad or evil or misguided scientist, not the usual reality-based scientific-method science.

OK there was a link to a more detailed outline of research objectives that would support 'robustness' of AI applications. And that's a longer document, and it, out of much more content, has two items (out of many) interpretable as negative:

Autonomous weapons: "...perhaps result in 'accidental' battles or wars". Ack! Now I have to be worried about being shot in the face by an Amazon delivery drone.
Security: how to prevent intentional manipulation by unauthorized parties.

I have quite of few inspired fears of AI, but they weren't really represented in this document.

So I conclude that most of these fears dredged up by the letter are very external to the letter, created out of readers' own preconceptions.

---

There's all sorts of worries about science in general, the unintended consequences of something so obviously beneficial. And AI, since it is usually heuristic based, has even more room to have hidden 'features' pop up unexpectedly (and when it does less understanding of 'why' it happened).

But to the 'evil' point. it's not the AI's fault. It's not a sentient being. Even if it passes a cursory Turing test, it has no 'intention' or 'desire' or other mind to be second guessed as to its machinations (pun intended). If it is anybody's fault it is some person: the designer who did not consider out of range uses, the coder who did not test all cases, the manager who decided a necessary feature was only desirable and left out of the deliverable. repurposed it outside of its limits. Your worries are second guessing a bunch of people behind a curtain, on top of assessing the machine's engineering.

What are the evils that are going to come about because of AI? It's not a unconscious automaton, after calculating a large nonlinear optimization problem, settling on a local maximum which involves removing all nuclear missiles by ..um.. using them (much more efficient that way). It's not having your resume rejected on submission because it has calculated that your deterministic personality profile is incompatible with an unseen combination of HR parameters which imply that all candidates cannot be black. Haha those may very well happen eventually. It's going to be sending a breast cancer screening reminder to families whose mom has recently died of breast cancer. It's going to be charging you double fees automatically every time you drive through a toll booth because you have another car with EZ Pass. That is, the errors may be associated with AI systems, but the problem is not the inscrutability of the AI but lo-tech errors based on assuming the AI is thinking of all these things and will act responsible enough to fix them. 'AI' isn't thinking and isn't responsible. People have to do that.

So be concerned about that fraud detection that doesn't allow you to buy a latte at midnight (it's decaf!) but does allow midday withdrawals just under the daily limit for a week. Or be concerned about the process that,  for all the those ahead of you in the royal line of succession, automatically created and accepted Outlook appointments at an abandoned warehouse filled with rusting oil cans and accelerant and told to light a match.

Any sufficiently advanced incompetence is indistinguishable from malice. (Grey's law)

Another Design Pattern: Layers

Though I usually talk with software as the underlying example, I call this a general design pattern since it works in many fields.

Layers or layering is a way of separating a large goal into smaller pieces. It is not necessarily by sequence of execution or design but by amount of detail of domain expertise. That is, the

The 'layers' pattern is really a pattern using another pattern, the interface. When the terms 'vertical application' or 'horizontal design are used', horizontal means a general purpose set of tools, vertical means using a ladder of tools, one depending on the next to solve a niche problem.

horizontal vs vertical scaling

The canonical example is the OSI model for networking (computer communication) popularized by Tanenbaum (fig 1-20, Tanenbaum, Wetherall, Computer Networks (2011)):

Note - level 7:mailActual communication over a cable is through the physical layer. There are rules and restrictions on the physical layer that the layer above it conforms to in order to get certain behavior but is easier to think in in the higher abstraction.

It is a stacking of individual components, a higher one depending on a lower one. The higher layer is dependent on the lower one, and is specified in the language of the lower one.

Layers of science - mathematics, physics, chemistry, biology, psychology. Here one may notice that the interactions of the layers is not necessarily one of interfaces: though understanding of physics ostensibly underlies chemistry, understanding the former doesn't guarantee an understanding of the latter. Physics may give insight but won't necessarily determine how chemistry works. This just shows that layers is a general strategy for dealing with a large domain (here science is about as large as it gets).

Purity from xkcd

The benefits of the 'layers' pattern is that it cuts up a larger monolithic area into many smaller manageable pieces. Instead of trying to understand the meaning of life, these 'smaller' areas are more manageable. Also, each individual piece can be worked on with a limited vocabulary (that of the lower piece). You don't have to understand all the complexities of the lower layer.

This is another pattern that encourages modularity: the higher layer (the abstract layer) has its own language and ways of doing things implemented in the interface given by the lower layer. The lower layer (and so also layers below it) could be entirely replaced by a different implementation.  Or one layer could be replaced given that it respects the interface of its higher and lower layers.

Another example from computers is architecture: electronics, microprogramming, machine language, assembly language, higher level programming language, specification language. A new layers in design can come from either direction: higher level programming languages like C or Fortran came from wanting to abstract away common patterns in assembly language (like subroutines), and microprogramming came from trying to implement machine language more easily in the electronics.

A higher layer is often an abstraction from a lower one. The common patterns can be set in (parameterized) stone in lower ones, with enough freedom to connect those things in the higher layer to get applications done. That way, the higher layer can worry about its problems without having to worry about some implementation details, and the lower layer can worry about its own problems. This is a way of explaining the benefits of encapsulation/modularity/data hiding: reduce the knowledge requirements at each level while maintaining functionality.

One difficulty with layering is making sure the knowledge of the layers is sufficiently compartmentalized, that the user/designer in one layer needs to know as little as possible of other layers. A leaky abstraction occurs when too much is required of those outside a layer.

Without these layers, there can easily be efficiencies that are possible by thinking fast, by the designer of the monolith using fine local information to get benefits in the larger architecture. But this can lead to spaghetti code (spaghetti design), where small changes in a small but common/overused element can cause large changes (or rather problems/bugs/disasters).

The layers may not be a deliberate separation of affairs, but reached organically. One layer s formed naturally, and then others see that the items at that layer can be used to create a layer on top. Or the implementation of a bottom layer may be rethought in order to create a more useful layer below.

A monolith is a great big ball of cleverness. Every small action depends on efficiencies gained by side effects of other small actions far away. This often leads to very brittle designs, but think of the efficiency gain! Using layers may remove such efficiencies at the expense of ease in modification.

Or it may turn out that a hidden layer implements things in such a way that the patterns of a higher layer can take advantage of the much lower layer if only that information was exposed, either to use directly (dancing links which reuse presumably freed pointers more efficiently) or implicitly.

"You don't see people casually become neurosurgeons in their spare time"

From James Hague, Organizational Skills Beat Algorithmic Wizardry via John Cook, The most important skill in software

This is the reason there are so many accidental programmers. You don't see people casually become neurosurgeons in their spare time--the necessary training is specific and intense--but lots of people pick up enough coding skills to build things on their own.

Yeah, why is it that so many professional programmers are self-taught? So a brain surgeon is the top of the charts, but even a family practice doctor, the front line of medicine, still has the education and training of a rocket scientist.

So that's a bit tantalizing 'This is the reason...'. But Hague doesn't really give a reason. OK he sorta does. Previously he says:

To a great extent the act of coding is one of organization [not algorithmic wizardry]. Refactoring. Simplifying. Figuring out how to remove extraneous manipulations here and there.

Except programmers don't get hired because they show how well they can reorganize things, but by how they write an algorithm (classic interview questions). Sure, I bet there are some refactoring questions in some places (and I think those are just as useful a measure as the algorithm questions). But what gets you hired is your knowledge of the syntax of a programming language and maybe its libraries. But that's interviews and hiring.

It seems that Hague is saying that 'refactoring well' is the key to successful programming, not algorithmic wizardry. Historically, programming was algorithmic wizardry (a la CLRS) because that's what computers were good for, calculating extremely difficult mathematical or combinatorial computations. What is the shortest path that visits all nodes in this special graph? (greedy just doesn't work) How do you solve for a vector in a matrix equation using Gaussian elimination without using extra space? (space was at a premium). Those tasks needed wizardry, the kind of thought that goes into solving a Rubik's Cube, having good memory for a few examples, seeing patterns in them, seeing in the patterns, always an eye for optimization.

How do you get that one yellow orange edge piece in place without messing everything else up? Figuring that out takes a lot of 3D imagination ability, a lot of memory, and a lot of trial and error, but eventually you come up with a set pattern to follow like "U' L' U L U F U' F'" (ha ha that's technical, and not doable without, but that's what algorithms are). But once you have the pattern, it's straightforward to compose with other patterns (which you have to figure out possibly totally different from the patterns for the above or maybe somewhat similar)

But nowadays it seems lots of those difficult algorithms have been solved. They're in a library. You don't have to reimplement red-black trees to create a database index, you use the library. Programming today is more like 'Rush Hour', where you're moving a small set of pieces, some blocking others, but maybe the first are blocking the latter and you have to plan ahead.

You're rearranging a bunch of pieces to make the whole thing come out. For a webapp, you need some forms on the front end, communicating via http calls to a backend with a database, but your webapp needs to run on a smart phone and a tablet, too. All straightforward large pieces, but to make sure that you make it easier for yourself to modify later, you want to separate the pieces well.

What makes a good programmer, and allows so many without academic education in it to perform well, is that this kind of large piece thinking is usually amenable to anybody with a technical background, engineering, math, science. Most of such fields promote detail-oriented, symbolic thinking and memory (all of which is good to grasp the computational nature of programming) but also the

So the answer to the original question? Not everybody is an algorithms wizard, can figure out Rubik's cube, there's lots of special talent needed for that. But most technically oriented people, without specific experience, can program nowadays, can solve Rush Hour problems. It's not easy (especially for the more difficult layouts), but most technically oriented people can plow through it. You don't need to know linear algebra to do a website, you just need to read a few docs in order to move a handful of pieces around.

Comments on Mythical Man-Month: Chapter 7

Chapter 7. Why Did the Tower of Babel Fail?

(cursory comments here, there is hardly any discussion to be made  because it is too easily true; needs to be said, but I can't really add anything).

7.1 The Tower of Babel project failed because of lack of communication and of its consequent, organization.

This is the same as noting the benefits of standards. There's having a standards, and making sure everyone uses the standard, 

Communication

7.2 ''Schedule disaster, functional misfit, and system bugs all arise because the left hand doesn't know what the right hand is doing." Teams drift apart in assumptions.

Pretty obvious.

7.3 Teams should communicate with one another in as many ways as possible: informally, by regular project meetings with technical briefings, and via a shared formal project workbook. (And by electronic mail.)

By documentation? yes, it is all needed but has the same difficulty as any documentation in that it is hard to make it follow reality once written down.

Project Workbook

This is an entirely new concept to me, but is very easily implemented using a wiki nowadays.

7.4 A project workbook is ''not so much a separate document as it is a structure imposed on the documents that the project will be producing anyway."

-

7.5 ''All the documents of the project need to be part of this (workbook) structure."

-

7.6 The workbook structure needs to be designed carefully and early.

designed how?

7.7 Properly structuring the on-going documentation from the beginning ''molds later writing into segments that fit into that structure'' and will improve the product manuals.

Document early? I guess really one should document continuously and this is just a reminder not to put it off until afterwards.

7.8 ''Each team member should see all the (workbook) mate- rial's (I would now say, each team member should be able to see all of it. That is, World-Wide Web pages would suffice.)

This device (workbook) still needs behavioral 'technoloy', people should be encouraged to use a wiki in this manner.

7.9 Timely updating is of critical importance.

duh?

7.10 The user needs to have attention especially drawn to changes since his last reading, with remarks on their significance.

Current wiki technology (MediaWiki) enable comparing, but it is of questionable facility (ain't so easy to use).

7.11 The OS/360 Project workbook started with paper and switched to microfiche.

Good for them. I remember when we had to use the chits thrown away by card readers. And no pen, just a stick and excess oil from the sides of the printer housing.

7.12 Today (even in 1975), the shared electronic notebook is a much better, cheaper, and simpler mechanism for achieving all these goals.

yes.

7.13 One still has to mark the text with (the functional equivalent of) change bars and revision dates. One still needs a LIFO electronic change summary.

The current implementation of good behavior, a version control system, takes care of this.

7.14 Parnas argues strongly that the goal of everyone seeing everything is totally wrong; parts should be encapsulated so that no one needs to or is allowed to see the internals of any parts other than his own, but should see only the interfaces.

Without reference to the next item, I find this total encapsulation questionable. Yes, data hiding is good at every level, reducing the unnecessary expense of mental energy. But seeing what is available and how other things look is a good way to learn design too.

7.15 Parnas's proposal is a recipe for disaster. (I have been quite convinced otherwise by Parnas, and totally changed my mind.)

Parnas's view has been totally vindicated by the open source movement. But Brooks brings up an interesting contradiction, that of data-hiding as a laudable goal. I'm not sure how to reconcile the two. Maybe it is that for unit construction purposes, making large knowledge necessary is undesirable, but for finding the tools you need (without knowing exact details), seeing the larger catalog is better.

Organization

7.16 The purpose of organization is to reduce the amount of communication and coordination necessary.

Just like in -programs!-

7.17 Organization embodies division of labor and specialization of function in order to obviate communication.

Just like in -programs!- 

7.18 The conventional tree organization reflects the authority structure principle that no person can serve two masters.

Reduces communication and trust complexity (trust complexity is how many varieties of similar but conflicting messages one gets. Yes, I just made that up.

7.19 The communication structure in an organization is a network, not a tree, so all kinds of special organization mechanisms ("dotted lines") have to be devised to overcome the communication deficiencies of the tree-structured organization.

Right. A single tree is too simplified for humans. More than one tree, or a network is better. But not haphazard.

7.20 Every subproject has two leadership roles to be filled, that of the producer and that of the technical director, or architect. The functions of the two roles are quite distinct and require different talents.

The difference needs to be explained better. A producer is... and an architect is...

Really, I thought he was going to say a technical architect and a human resource type manager.

7.21 Any of three relationships among the two roles can be quite effective:

. The producer and director can be the same.

. The producer may be boss, and the director the producer's right-hand person.

. The director may be boss, and the producer the director's right-hand person.

I think this is too localized to his situation. Interpersonal conflicts and connections may make this a good fit or a bad one. This is too losely judgable by scoial engineering experiments.

Comments on Mythical Man-Month: Chapter 6

Chapter 6. Passing the Word

6.1 Even when a design team is large, the results must be reduced to writing by one or two, in order that the mini- decisions be consistent.

I think this is all hopelessly unjudgeable because 'large' is not defined (or it is self-defining). But the concept is important; the concept of a larger number of mini-decisions is salient, thousands of small decisions in design are made either through implicit experience or by following the path of least resistance.

6.2 It is important to explicitly define the parts of an architecture that are not prescribed as carefully as those that are.

Yes, sounds good, is good, but is an afterthought. This item is intended to get you to acknowledge vagueness, acknowledge the -lack- of specification/design. In some sense this applies to the subsystem/black box already (the subsystem, to be implemented needs its own internal design hidden), but this bullet point is also about the main design, that there are parts not devolved to the subsystem that are still just not yet specified. But it's hard to know what you don't know.

6.3 One needs both a formal definition of a design, for precision, and a prose definition for comprehensibility.

 Yes, sounds good, but a problem with DRY, and ensuring correspondence between formal and informal (the usual problem with flowcharts).

6.4 One of the formal and prose definitions must be standard, and the other derivative. Either definition can serve in either role.

Or, just to convert this into total blandness, they could be done together. It is not clear that it must be one or the other. But relevant to the previous point, whichever one is thae standard and the other the derivative, one is being modified officially, and the other has to change in kind, there has to be an explicit process to remember to modify the other.

6.5 An implementation, including a simulation, can serve as an architectural definition; such use has formidable disadvantages.

What? Is a simulation a prototype? Oh...maybe he saying this is a bad thing. In 'real-world' engineering, the prototype is a proof of concept; it isn't polished but the main effect is shown to work. No one would consider actually using the unpolished version. A 'productized' version is what will actually be used

Currently, in software engineering, there is the bad habit that prototypes, initial implementations, are somehow set in stone and become a de facto standard. Now that we've seen this, we should just realize 'don't use the prototype'.

6.6 Direct incorporation is a very clean technique for enforcing an architectural standard in software. (In hardware, too--consider the Mac WIMP interface built into ROM.)

What? (I don't get the particular reference, really, the MAC was the exemplar of that practice?). Is this the same as compiling to silicon?

6.7 An architectural ''definition will be cleaner and the (architectural) discipline tighter if at least two implementations are built initially.''

 If you have an excess of resources to do something like that, sure. Maybe competing teams? That's another luxury of big companies.

6.8 It is important to allow telephone interpretations by an architect in response to implementers' queries; it is imperative to log these and publish them. (Electronic mail is now the medium of choice.)

I feel like bug reporting software is of much higher quality now than when he was writing so this point should be 'Use modern bug reporting software'.

6.9 ''The project manager's best friend is his daily adversary, the independent product-testing organization."

Adversarial evolutionary progress sounds good but might be contrary to human nature. How can this be made less antagonistic and more...ok not so negative but more constructive. Negativity is easy (and easy to be correct), but constructive criticism is hard...at that point the commenter doesn't have the resources to  make the design take the criticism into consideration.

But this could just be the start of a better testing apparatus: formal specs, test driven development, unit-testing frameworks, testing scripts.

Comments on Mythical Man-Month: Chapter 5

Chapter 5. The Second-system Effect

5.1 Early and continuous communication can give the architect good cost readings and the builder confidence in the design, without blurring the clear division of responsibilities.

This is somewhat bland. Was it a problem in his time that communication was restricted so much?

5.2 How an architect can successfully influence implementation:

• Remember that the builder has the creative responsibility for implementation; the architect only suggests.

• Always be ready to suggest a way of implementing anything one specifies; be prepared to accept any other equally good way.

• Deal quietly and privately in such suggestions.

• Be ready to forgo credit for suggested improvements.

• Listen to the builder's suggestions for architecture improvements.

This is all about handling competing concerns: separation of concerns and managing personalities. To summarize, separate the responsibilities between design and implementation, but allow communication between the two parties.

5.3 The second is the most dangerous system a person ever designs; the general tendency is to over-design it.

Sophomoric? Most of the software engineering discipline is about managing peoples' psychology, either individuals or groups. The 'second system' problem is about what didn't get done or got done badly in the first one, and the problem is that one over compensates. or rather -can- compensate. A first system may have made compromises or limitations in an attempt to get out in time; the second system might try to correct this by adding all the features planned but missing from the first one. Or if design was haphazard in the first system, actual design used for the second, maybe just the less informal process of the second system allows more realistic performance metrics.


So this may happen, or it may not. Which is the number two system? Is it the one after the prototype? Or the one advertised second? 

5.4 OS/360 is a good example of the second-system effect.

(Windows NT seems to be a 1990s example.)

This is soooooo old. In fact nostalgic, I am not so old to...actually...I -am- barely old enough. (my only comment here is nostalgic). I remember back when I first got the computer bug (~7th grade, in the late eighties right before the first prolifereation of PCs, meaning there were none). An older friend of the family happened to be a programmer, and just happened to have a little souvenir for me: a reference card for System 360 JCL and assembly language. It was just the right amount of inscrutability to get my interest. It was an opaque totem..well I did learn about tangential things from it like the existence of EBCDIC and hexadecimal and that there were opcodes and registers and such. I didn't have a 360 to try to code on, but I did have a ...well eventually I had a 6502 to do real assembly on. And by college when I had an architecture class, and our first materials included a System -370- refcard (woo hoo...progress...looked almost the same and I already understood what was going on), I was almost jaded. But really, you just accept what things are in a class.

Which is all to say, I can't really judge his pronouncement about OS/360.

5.5 Assigning a priori values in bytes and microseconds to functions is a worthwhile discipline.

What I think he's trying to say here is 'just do it'. If you're going to try to estimate something, treat it as a Fermi problem, approximate right now without a whole lot of thought and engineering, you can fix up the details later.

Comments on Mythical Man-Month: Chapter 4

Chapter 4. Aristocracy, Democracy, and System Design

4.1 ''Conceptual integrity is the most important consideration in system design."

What is conceptual integrity? is it consistency? is it simplicity? Is it understandability by others? The locution is pretty empty, meaning anything you want that is something like 'really good stuff', or some other self-supporting, empty phrase.The more I try to pin down its meaning, the more fluid it gets. I think I have a vague idea of what it should mean with respect to software, but any rational definition of it just never seems fully right.

4.2 ''The ratio of function to conceptual complexity is the ultimate test of system design," not just the richness of function. (This ratio is a measure of ease of use, valid over both simple and difficult uses.)

I'll just continue to harp on the undefined nature...how can one have a ratio when the dividend and divisor aren't well defined. What does 'function' mean? Number of features? Define 'feature'? This is all too vague.

4.3 To achieve conceptual integrity, a design must proceed from one mind or a small group of agreeing minds.

Totally consistent with chapter 3. Simply a repetition (given that we accept 'conceptual integrity' to be general 'software goodness')

4.4 ''Separation of architectural effort from implementation is a very powerful way of getting conceptual integration on very large projects." (Small ones, too.)

Now -this- is an important strategy for design and is actually substantive (where many less vague concepts than 'conceptual integrity' can be assessed, like 'time' to implement', or run-time efficiency of code (this latter idea is probably made worse, but that's for another comment, which will come soon enough)). And it is entirely abstract. Works for anything. It essentially says design is recursive. you can design a single entity by splitting it into parts (however you split) and each of those parts can be also designed. the 'separation' is essentially the structured programming/OOP concept of encapsulation/modularity/black box/hidden data, all of which are aids to memory and knowledge. That design the whole so that you need to know and remember as little as possible about the insides of the parts.

4.5 ''If a system is to have conceptual integrity, someone must control the concepts. That is an aristocracy that needs no apology."

Authoritarian certainly. This doesn't particularly show well with open-source projects, where (naively?) there -is- no designer or master control. But this has

4.6 Discipline is good for art. The external provision of an architecture enhances not cramps, the creative style of an implementing group.

This sounds like Russell's admonition that a good notation helps with the math (that is some structure as opposed to total freedom, helps)...OK I looked for it. The quote is very relevant:

...a good notation has a subtlety and suggestiveness
which at times make it seem almost like a live teacher.

(from Russell's introduction to Wittgenstein's Tractatus)

4.7 A conceptually integrated system is faster to build and to test.

A -modular- (let's take that as the intended meaning; not a straw man, and not really what one one thinks of immediately system certainly is -easier- and then, I guess, faster to test, but not necessarily more efficient. For comparison's sake let's say the alternative to modularity is ...I'm searching for the word...something to do with 'monolithic'...how about 'monolithicity'? 'monolithicness'? 'unity'? Anyway, a monolithic system has large communication/use degree between internal implicit concepts and features, and therefore, much shorter dependency paths than a modular system,and so is more likely to have greater executional efficiencies. BUt to support Brooks's statement, if one is being modular, then each module has a much smaller and cohoerent test range and so test can be tested more easily The monolithic system -has- to be developed/designed as one entity with all element in a designers mind at once, much more likely to overload that human's ability to manipulate the design mentally.

4.8 Much of software architecture, implementation, and realization can proceed in parallel. (Hardware and software design can likewise proceed in parallel.)

If modularity in  followed and specifications of interaction between the pieces is done well, then yes.

Comments on Mythical Man-Month: Chapter 3

Chapter 3. The Surgical Team

3.1 Very good professional programmers are ten times as productive as poor ones, at same training and two-year experience level. (Sackman, Grant, and Erickson)

Intuitively, I grant that, and so am very willing to accept the data.

3.2 Jackman, Grant, and Erickson's data showed no correlation whatsoever between experience and performance. I doubt the universality of that result.

Yes, I'm sure it 'depends'. For example on specific skills like, numerical analysis or parsing or functional programming I'm sure experience helps a lot.

3.3 A small sharp team is best-as few minds as possible.

This is too vague and too unsupported by any data. Why wouldn't a larger team of very sharp minds work (working on different parts)? How about a team with sharp designers and plodding implementers? How about...well...how about just stick with 'small' (forget 'sharp' assuming that's a constant). How small?...

3.4 A team of two, with one leader, is often the best use of minds. (Note God's plan for marriage.)

- Re: marriage - WJW. I'll cut him some slack because he wrote this in the seventies. Um..actually this summary was written in 2001.

- let's just accept it for what it is. I don't doubt this is a report of his experience but could be too swayed by anecdotal evidence (one example stands out too well in his mind).

3.5 A small sharp team is too slow for really big systems.

Contradicts 3.3. So this must just be saying 'small sharp team for ...anything but a really big system (and then you need more?)'. I don't get it. I need a definition of 'small' and 'large'.

3.6 Most experiences with really large systems show the brute-force approach to scaling up to be costly, slow, in- efficient, and to produce systems that are not conceptually integrated.

 maybe. I don't have much experience with 'really' large systems or scaling up for that mattter.

3.7 A chief-programmer, surgical-team organization offers a way to get the product integrity of few minds and the total productivity of many helpers, with radically reduced communication.

Sure...I'll accept as stated.

Comments on Mythical Man-Month: Chapter 2

Chapter 2. The Mythical Man-Month

2.1 More programming projects have gone awry for lack of calendar time than for all other causes combined.

I agree. The cause is lack of connect between desire and implementation. Because of other reasons (non-repeatability inherent as a design consideration, mentioned in chapter 1). Also, it is easier to think of a thing than it is to create a thing. This is not particular to software. But maybe it is worse for software. Drawing a diagram of a building is hard thoughtful design work, but everybody can compare that directly to lifting a beam with a crane to implement the drawn line, and how much harder the latter is compared to the former. But thinking about some one else's thoughts seems makes the others thoughts seem so easy.

2.2 Good cooking takes time; some tasks cannot be hurried without spoiling the result.

This isn't special to programming. Neither really is the first one but for that I could think of programming specific reasons.

2.3 All programmers are optimists: ''All will go well.”

Again, this isn't special to programming, or even engineering, but any kind of planning.

2.4 Because the programmer builds with pure thought-stuff, we expect few difficulties in implementation.

2.5 But our ideas themselves are faulty, so we have bugs.

faulty = inconsistent, incomplete at the best of times, but usually just underspecified, vague, and inchoate

2.6 Our estimating techniques, built around cost-accounting, confuse effort and progress. The man-month is a fallacious and dangerous myth, for it implies that men and months are interchangeable.

On an assembly line, labor/time -is- a commodity, adding more people -does- make things better. Again, define what it is being added to. Adding more people to a project certainly may make things go faster, when those pieces are small, identifiable, seperate parts.

2.7 Partitioning a task among multiple people occasions extra communication effort-training and intercommunication.

No doubt. Communication costs increase with size. Software is hardly ever assembly line. Every product is new. One way to think about it is that software -is- design, you're designing an assembly line to automatically take care of many multiples of objects. Yes, you can assign more people to more sandbags, to add items to widgets. But the things that a programmer is working on...every item is a new, different thing that can't be treated in exactly the same way as the previous one.

2.8 My rule of thumb is 1/3 of the schedule for design, 1/6 for coding, 1/4 for component testing, and 1/4 for system testing.

This is just SWAG (or more charitably, what he happens to do). Even if timing experiments are done, too much is not measurable in a controlled fashion. Each of these events is 'as long as a piece of string' (i.e. however as long as it will take). Is this normative or descriptive? As percentages then meaningless.

2.9 As a discipline, we lack estimating data.

Yes. Because things are not repeatable.

2.10 Because we are uncertain about our scheduling estimates, we often lack the courage to defend them stubbornly against management and customer pressure.

I'd also add that the occupational hazard of the engineering discipline is concern for details and technical aptitude, and so a lack of practice in human psychological concerns. That's general, but also the specific acceptance of authority's wishes too easily because wishes aren't facts and so cannot be argued.

2.11 Brooks's Law: Adding manpower to a late software project makes it later.

Famous, supported by data. Depends on definitions (what -kinds- of projects).

2.12 Adding people to a software project increases the total effort necessary in three ways: the work and disruption of repartitioning itself, training the new people, and added intercommunication.

Yes, those are the major subparts of Brooks' law (when it applies)

Comments on Mythical Man-Month: Who the hell am I to say anything

Anybody can say anything about anything. a cat can look at a king. But you got a point, how does one trust, put weight, care about things said?


So what possible way can I justify that what I say anecdotally or with the scent of authority has any potential to be extrapolated successfully? We all have many layers of what we do: the accountant has to manage people in addition to being a whiz at adding/using excel, the plumber a whiz at knowing the hidden possibilities of where pipes go and dealing with suppliers not just how to connect PVC to iron, etc. A major part of my immediate purposeful salaried work is doing and managing software engineering: I program, and I manage other programmers. Not many programmers, and not a huge project (actually conveniently scaled), but I have to interact with a number of other IT organizations (company internal; few working contacts outside). I have worked in 'industry' just out of college but only on smallish things (one self-contained) and one that involved groups but self-contained within around 20 software types, did absolutely nothing of any use or nontrivial size in grad school.

So without a complete month-to-month CIA file biography, there it is. Not a lot of experience with large projects. But I have some experience, enough to be able to comment intelligently.

Comments on Mythical Man-Month: Chapter 1

Analysis of Brooks' bullet points from Mythical Man-Month chapter 1. (note: these will all be interlinear)

Chapter 1. The Tar Pit

1.1 A programming systems product takes about nine times as much effort as the component programs written separately for private use. I estimate that productivity imposes a factor of three; and that designing, integrating, and testing components into a coherent system imposes a factor of three; and that these cost components are essentially independent of each other.

The numbers Brooks chose (3 and 3) are wildly divergent depending on the kind of software system being developed. Is it a big system with large modular parts? Is it a small highly optimized system? Is it a -new- system? I think realistic numbers could be made with a lot of differentiation of what system means and a lot of experimentation. The primary point is that design/integration/testing are a big part of any project. I actually don't know what he means by 'productivity', but I'll grant 'independence'.

1.2 The craft of programming ''gratifies creative longings built deep within us and delights sensibilities we have in common with all men," providing five kinds of joys:

• The joy of making things.
• The joy of making things that are useful to other people.
• The fascination of fashioning puzzle-like objects of interlocking moving parts.
• The joy of always learning, of a nonrepeating task.
• The delight of working in a medium so tractable- pure thought-stuff-which nevertheless exists, moves, and works in a way that word-objects do not.

These five points are not particularly independent (1 and 2 are paradoxically not independent, and I consider 1 and 3 identical in this context of programming/systems engineering, because that is what we are making. As to 'non-repeating', the unwritten implication is the avoidance of boredom. We (programmers) will spend -hours- working on a for-all-time general solution with a one-button-press initiation to avoid having to do a repetitive keyboard operation over and over (that could easily have taken less time than the general solution). In fact, there is (read: 'I have') a visceral reaction to when others do something many times, when it is so obvious that one could do it once.

These points are really just an expression of the general motivating psychology for programmers. It is a good explanation for all the work put into 'open-source' and 'free-ware' ('see what I can do').

1.3 Likewise the craft has special woes inherent in it.

• Adjusting to the requirement of perfection is the hardest part of learning to program.

This is a bit like saying 'math takes getting used to'. Which is not to say that I disagree, it's just speaking to an audience of programming outsiders, which I'd expect is not the primary readership of this book.

• Others set one's objectives and one must depend upon things (especially programs) one cannot control; the authority is not equal to the responsibility.

I think this is simply a statement of the manager/worker/tool situation (managers ask workers to get things done, the worker/programmer attempts to do that using tools, and some of those tools may be created by others outside of one's control. I'm not totally sure about the independence of authority and responsibility set forth here. Again, it's philosophy, other views of the same situations are equally valid.

This sounds worse than it is: actual authority comes from momentum of accomplishment.

This qualification is still unclear.

• With any creativity come dreary hours of painstaking labor; programming is no exception.

True of any skill: painting, storytelling, baseball. I think he's trying to emphasize that programming, which many people are plain unfamiliar with, -is- a skill.

• The programming project converges more slowly the nearer one gets to the end, whereas one expects it to converge faster as one approaches the end.

Could be cynical, fatigue at the end making things harder than expected. But also, many design situations create a tree of resolutions needed: to resolve problem X, a number of subproblems need to be resolved, and each one of those subproblems their own. So the number of problems grows exponentially, but labor only achieves at a linear rate.

• One's product is always threatened with obsolescence before completion. The real tiger is never a match for the paper one, unless real use is wanted.

This sounds like 'whatever you make will be out of date before you get to market'. I'm sure that is a worry of any designer, and comes true all the time but it is still a philosophical statement. For example the opposite is similarly supportable; there are many products, badly designed, poorly implemented, and late (from the initial idea) that have grown and taken over market share despite those failings (Windows is the most obvious example). 

This chapter is really general motivation and psychology rather than anything much experimentally testable. It mostly rings true for me, and I highly suspect for most programmer types. 
 

Note: by 'philosophical' I think I mean 'a cogent thing, but it's opposite, and orthogonal versions are equally supportable'.