Too Abstract

Most days I get the feeling that nobody understands what I'm talking about.

This is the problem with being too abstract. Many people have difficulty with abstract models of behavior and being a person that spends nearly all my time working with abstract models I sometimes find myself in the position of speaking Greek to a Latin audience. The Greek is appreciated by the Latins but not really all that well understood.

When we as programmers communicate software designs or the impact of new technologies we often will get those blank stares. The way to help mitigate those blank stares is to use concrete stories. Stories with people's names that contain actions that people really need to perform. If you can say: "Now when Joe wants to check his mail he can do so from anywhere that has an internet connection." instead of "This is a web enabled mail client." That's more words but easier for lay-users to understand.

For example instead of "This Ajax mail client will allow our end users to use mash-ups of corporate data in email." you could say, "Now when you check your mail and hover over an order number with your mouse a little bubble will show the order details. You can click in the bubble to get other data on that order." The second example is wordy but hopefully easier to get people's minds around.

When we teach sales people we teach them to put emphasis on benefits not features. In our example the "Ajax Mash-up" is a feature but the "hover over an Order number for quicker access to details" is a benefit. Sometimes our jobs as technologists are more about sales than about technology. Instead of booking orders we are trying to buy mind-share for our thoughts and ideas.

Model Driven Architecture

When building software a software engineer or other system design expert creates a shared mental model of the problem space. Boxes and stick-figures or intricate flow diagrams detailing the space to be explored find their way into documentation. Descriptions made for implementation people to work out finer details.

What if the documentation was the software?

In theory the process of creating software is all design. Design progresses from large sketches to finer and finer detail. The finest of details yielding code that is finally compiled into machine language. Each refinement is fueled by human effort. Each finer detail of documentation yielding an artifact that exists merely to be consumed by the next stage in the chain.

Model Driven Architecture is an attempt to skip many of these steps and skip as closely as possible to the code that is ready to be transformed. UML diagrams drive a series of transformation engines to "compile" drawings into code. The resultant code may or may not be ready for use but it is a many great steps down the chain to complete. All of this hinging on the pretext that the programmer builds a mental model that is then transformed into code.

Who can program?

A there is a paper written at the School of Computing at Middlesex University in the UK that addresses the issue of programming aptitude. The authors of this paper (Dehnadi and Bornat) have devised a test that they claim can separate out who may learn to program well and who will not. This fits well with my earlier observation that: "Anyone can program, only some people will learn to program well."

The working title "The camel has two humps" refers to a phenomenon that even I have noticed when teaching programming. One group will do well, and the other will do poorly, each group will have their own bell producing a two humped grade curve. The break through for this paper is creating a test that separates out who is part of which group. You can then reliably plot two independent bell curves based on results.

The differentiating factor between our two populations of programmers? Mental models.

The tests devised by Dehnadi and Bornat determine who is creating mental models and using them. It turns out that it is not nearly so important that the student use a correct mental model as that they know how to create and use a mental model at all. So I have to ask, how does one learn to use mental models? Why do some people use them well and others do not?

What makes a good programmer?

Anyone can program, but, only some people will learn to program well. Some people learn to program well very quickly. These fast learners find ways to work with the concepts that build the systems of thought that software is. What causes one person to "get it" and another to "miss it" entirely?

There is an art to programming. You've got to keep it DRY, you've got to be terse but not too terse, you've got to be lazy in the right way. Some people get it in a short time while others never seem to understand programming. What magic formula of personality, intelligence, and determination makes the difference between those who learn to program and those who learn to program well?

What makes good software? What makes a good programmer?

I contend that Software is the encoding of thought and if I stick to my resolution then I must also contend with the implication that good software constitutes thought that is also "good" in some way. The idea of a "good" programmer therefore is anchored in the idea of "good" thought and that means that a "good" programmer must also be a "good" thinker and a "good" communicator.

Whatever "good" in this context means. Albeit the idea of "good" thought is a little subjective. The idea of a "good" communicator is also subjective. Some people would find Jeff Foxworthy a "good" communicator others no so much. Some would prefer me to use Lou Dobbs as an example of a communicator. Others would prefer Jesse Jackson. All three of these people I've deliberately chosen because they communicate well to each of their respective audiences.

The definition of the "good communicator" is dependent on the audience that the communicator is communicating with. Each of the three examples I've picked communicate with a group that each has their own definition of "good" thought.

The definition of a "good" programmer is probably just as changing depending on the three audiences that a programmer communicates with: the computer, other programmers, and the end-user. These three groups are radically different for different kinds of programming projects. Know your audience.

Just as Jesse Jackson's jokes won't play well on Lou Dobb's audience... and Jeff Foxworthy would not play well to an audience gathered for Jesse Jackson. However I am confident that all three of these men could prepare and change up audiences if they wanted to. They could each entertain the other's audience in a way that avoided real catastrophe... because all three of them are good communicators and know how to pick a message to suit an audience. It would be harrowing but I think any one of those men could pull it off.

With programming your device driver, database developer, and web designer don't play well against each other's audiences. A good programmer can learn the audience and play to it well. Because the good programmer is a good communicator.

Terseness is good

Your head can only hold so much. Even very simple problems can flood your mind and escape your ability to follow them if they carry on long enough. For example addition is quite simple but if you are asked to keep a running sum for hours upon hours you are likely to begin making mistakes at some point.

Programmers face similar problems with software. Many seemingly simple things can be made unnecessarily complex by allowing a block to run-on without bound. The non-technical analogy might run something like this:

Which response to a query is preferable?

It is most assuredly true.

Yes.