And it makes me think, to what degree are organizations’ code bases shaped by their formal or informal organization structure? Are core modules and root objects often the domain of senior developers and objects lower in the hierarchy the domain of juniors? My experience is that it often tends to be, and it seems a reasonable overlap: after all, you want your more trusted developers fiddling where the damage can be greatest.

But how about other attributes of the code base? In the world of Perl, are CPAN authors often hired as external consultants? Are the most communicative programmers the ones that will write network services? Are the modules most used also written by the programmers that are most in contact with others?

And does organization structure also shape general code base structure? Will a more hierarchical organization tend more towards hierarchical object structures, while more chaotic or flat organizations tend towards more chaotic or flat code organization?

A lot of questions, but no answers… But one thing that comes to mind is, if organization and code structure follows each other, is this a good idea? I think few people designing a data model or object hierarchy starts with the organization structure as a blueprint, but speaking from my own limited experience, you can often at least see a reflection of either in both. Is this a good or bad thing? What can the consequences be?

THE SYSTEMATIC DEVELOPER: Writes code defensively. Does everything he or she can to protect code from unstable and untrustworthy processes running in parallel with their code. Develops a deep understanding of a technology before using it. Prides himself or herself on building elegant solutions.
THE PRAGMATIC DEVELOPER: Writes code methodically. Develops sufficient understanding of a technology to enable competent use of it. Prides himself or herself on building robust applications.
THE OPPORTUNISTIC DEVELOPER: Writes code in an exploratory fashion. Develops a sufficient understanding of a technology to understand how it can solve a business problem. Prides himself/herself on solving business problems.

Now why should you care?

Almost every mention I’ve seen of this online – or of any other personality type categorization system – is usually followed by a “which type are you?”. This misses the point utterly and completely. Psychological research like this first becomes really valueable when you stop thinking about yourself and start asking how this can help you understand other people. If you design API’s and base your design on what makes most sense to your own coding style, you will create something that two thirds of your audience will find difficult to use. Even if you don’t like or agree with their style.

Granted, that makes the assumption that programmers are always equally distributed among styles, which is a pretty wild assumption. The point is that other people are more likely to think differently than similarly to you.

That is also a good thing to keep in mind when formatting code for readability: if your coding style differs from standard Perl Tidy or your company’s coding standard, keep in mind that you are not formatting for yourself, but a colleague, maintainer or anonymous CPAN downloader. They are more likely to understand a common standard than your standard.  It sounds obvious, don’t it? I don’t think many (any) programmers think like this even so.

Now, Clarke, in an article to Dr. Dobbs Journal, has an example of a cognitive mapping of programmer types and API traits which is quite illustrative.  In Figure 1, thick blue lines shows the expectations of a particular programmer type, while the dark lines shows the score of a particular API. As you can see in this case, the match is bad. Now the good thing is that Clarke’s research gives you a framework to discuss how and why.

That’s important because programming style isn’t related to experience level or educational background. An programmer with an opportunistic style will not necessarily grow into a systematic programmer with more experience, neither will a systematic programmer become more pragmatic with age. Or perhaps they will – but you can’t assume that.

Finally, the dimensions which Clarke suggests APIs can be understood on at a cognitive level:

• Abstraction level. The minimum and maximum levels of abstraction exposed by the API, and the minimum and maximum levels usable by a targeted developer.

• Learning style. The learning requirements posed by the API, and the learning styles available to a targeted developer.

• Working framework. The size of the conceptual chunk (developer working set) needed to work effectively.

• Work-step unit. How much of a programming task must/can be completed in a single step.

• Progressive evaluation. To what extent partially completed code can be executed to obtain feedback on code behavior.

• Premature commitment. The amount of decisions that developers have to make when writing code for a given scenario and the consequences of those decisions.

• Penetrability. How the API facilitates exploration, analysis, and understanding of its components, and how targeted de- velopers go about retrieving what is needed.

• API elaboration. The extent to which the API must be adapted to meet the needs of targeted developers.

• API viscosity. The barriers to change inherent in the API, and how much effort a targeted developer needs to expend to make a change.

• Consistency. How much of the rest of an API can be inferred once part of it is learned.

• Role expressiveness. How apparent the relationship is between each component exposed by an API and the program as a whole.

• Domain correspondence. How clearly the API components map to the domain and any special tricks that the developer needs to be aware of to accomplish some functionality.

Steven Clarke seems to have discontinued his blog, but his scientific work is chronicled at Scentific Commons.

(Found, among other places, assertTrue() ).

Computer programming perhaps more than any other manufacturing endeavor begins with a thought and through skilled application of knowledge yields an intrinsically proven object that is itself almost mental (encoded electrical information).

It’s a good argument for why cognitive psychology is relevant for computer programming, but even more important, it points out the almost mental nature of computer programs.

Physiologically, the way our brains operate is mainly through bursts of electrical current called Action Potentials, that propagate information down neurons in a on-off fashion. Some people will call it binary, but the information conveyed is typically frequencies rather than binary patterns  (But this is a somewhat contentious question).

Here’s a beautiful drawing of neural communication from Wikipedia:

So you have a mental construction in a human brain contained in electrical signals, and this is transferred over to a construction of electrical signals in a computer.  Add that you usually want these two representations to be identical, you have a good argument why programming language design should be based strongly on cognitive science!

Neither approach is particularly good -I can’t imagine code written for violent psychopaths  would really be that great to maintain. And on the other end, a lot of coders optimize for their own readability, and will argue the finer points of formatting from that point of view, not that of the actual readers – missing the point that readability is ultimately decided by the reader, not the writer.

I certainly catch myself doing this quite often.

In the Perl world, this is probably an even bigger issue than in other languages.  There-Is-More-Than-One-Way-To-Do-It is still one of Perls big strenghts, but certainly not all the ways are equally good – which is why Perl Best Practices is now a staple of any Perl-wielding office. The contrasting Python, with it’s “there should be one — and preferably only one — obvious way to do it”, seems to be able to get away with 19 simple statements to define the pythonic best practice.

Now, anyone can have an opinion, particularly since research on code readability it still quite lacking. We just don’t know for certain yet what makes people get code. However, cognitive psychologists have been interested for several decades in how people generally organize large data structures in their brains, and some of this has given some neat practical applications for coding, such as Furnas’ paper on ‘Fish-eye’ views (1986). (This is basically about IDEs with collapsing code branches, but now you know why that’s nice, how to do it right and who thought of it first.)

Research on general language comprehension, however, is a massive field. In the ACM Journal of Computer Documentation’s August 2000 issue, George R. Klare provides some clear-minded and research-based adviced for communicators that might be enlightening and is a good starting point for thinking about readability of normal text – that might apply to programming.

He specifies four purposes of readability:

• Reading speed and efficiency.
• Reader judgment.
• Readership.
• Comprehension, Learning and Retention.

Of these, only the last is of any big interest for programmers; you don’t typically care about the speed the maintainer needs to read your code. You might care about the Reader  judgment if you code to impress your fellow programmers, but that is another chapter. Readership applies to how the size of the readership may be a function of  the simplicity of the text – a consideration on the skill level of your maintainers, perhaps, but few people code with the intention of their code to be read by a large audience.

However, the biggest issue with text and code is comprehension. Even more so in programming code, as it is essential that the maintainer is able to create a precise representation of the code in his own mind. Also he must be able to understand both what it actually does and what the intention is, since these don’t always add up.  For debugging purposes, it is actually completely essential that the reader can separate the soft human intentions from the hard computer operations, so any code must be understood on two levels simultaneously.

Now, how does readability affect comprehension? First, keep in mind that readability in natural language usually refers to choice of words and sentence length, and is typically measured by level of education necessary to read the text. This might not be appropriate for code readability – level of programming skill might not map to level of code understanding in the same way, and readability in code is often just a matter of indentation and syntactics.

But it probably maps somewhat close. This is where research is lacking again, so it is hard to tell.

Klare’s big advice, however, is that higher readability does not always convert into higher comprehension, but is modulated by situation and traits in the readers. And that is the important part. He describes four conditions when it does not work as you would think:

1. A reader can understand at higher levels than expected if his motivation is high. Also, skill level is a fuzzy concept.
2. If time is not limited, increase in readability might not make a difference on comprehension. The more time is limited, the larger the effect of readability
3. The greater the readers background knowledge on the topic, the less effect does readability have. On the other hand, even an expert on one field may prefer higher levels of readability in texts outside his field.
4. Type and level of motivation might affect comprehension.

or to quote his summary:

[..] more readable, written material is likely to produce greater comprehension, learning and retention than less readable only when one or more of the following factors are present: the less readable is much harder than the more readable, and clearly beyond the reader’s usual level; reading time is limited; the reader does not have a large amount of background or experience with the topic being covered; and, the reader has a relatively strong set to learn.

Now does this particulary increase understanding of readability of programming code?

Perhaps not.

However, if we think of readability not as just the reading of code as natural language, but rather of understanding of the semantic concepts, there is an interesting observation to be made.  If we consider using more basic programming to make the program easier to understand, while avoiding more advanced concepts, Klare’s summary of readability shows something that also adds up with other research, namely that this approach to readability doesn’t always increase comprehension.

In a very recent piece of research using Scala, Gilles Dubouchet found that using more compact and advanced functional programming methods rather than basic, typical loop-constructs increased comprehension.  Although one single piece of research such as Dubouchet’s is too limited to base decisions on, it becomes more interesting when it actually adds up with prior research on language comprehension.

Together it indicates that using more advanced methodology can increase comprehension for both original programmers and maintainers, unless they are pressed on time or motivation.

Unlike many other languages, Perl allows you to increase the complexity of your programming across methodology quite freely. You can start with the simple baby-Perl, go through procedural programming, add objects or start playing with functional approaches. You can use Aspect Oriented Programming or add on your own crazy, homespun programming methodology, if you so please.  For comprehension and readability purposes, the above research indicates that if you consider your audience and their situation well, going for a higher and more advanced level might not be a disadvantage.

But do keep in mind that the research is still a bit patchy, and this is mostly an argument without empirical data. But I’ll make sure I report what I find, as this is just the first in many articles about readability…

Object-oriented (OO) design and programming trace their lineage to research on abstract data types in the late 1960s and early 1970s, but they did not become popular software development techniques until the late 1980s. In all this time there has been little serious empirical or experimental study of OO techniques. What usually passes for evaluation is either a testimonial from an industry pundit who may have developed a small application using an OO technique [..]

and..

Even worse, this special issue of Human-Computer Interaction will be read by very few of the thousands of the people who read Computerworld, Information Week, Datamation, Software Development, and the other trade press periodicals in which OO methods are touted as often as explained. The results reported in this special issue are promising, but simultaneously they provide sobering expectations about the effort involved in obtaining the benefits of OO methods.

And little have changed since then – if anything the influence of Computerworld pundits and today’s bloggers are even larger than that of empirical and experimental research.

Just 15 years later, though, few of the journal issue’s articles have stood the test of time. Still, there are some anecdotes and pieces of information that are still interesting, if nothing else as a reminder of what people were thinking about OOP before it became mainstream, standard fare.

One quote from Curtis is still interesting for programmers changing from procedural to OO-style programming – as I guess most programmers actually still do while learning the ropes:

[..] professionals may require experience on as many as three 00 projects before they become proficient in these methods. The reputed advantages ultimately occur, but not during the early projects in which programmers are on the learning curve and have difficulty capitalizing on the capabilities offered by 00 methods.

Also, Herbsleb reports a few interesting facts from general cognitive psychology on how people generally understand objects, as part of a larger article on software engineering teams:

In careful experiments, Gentner (1981;  Gentner & France, 1988) showed that, when people are asked to repair a simple sentence with an anomalous subject-verb combination, they almost always change the verb and leave the noun as it is, independent of their relative positions. This suggests that people take the noun (i.e. the object) as the basic reference point. Models based on objects may be superior to models based on other primitives, such as behaviours.

And object hierarchies..

Miller (1991) described how nouns and verbs differ in their cognitive organizational form. Nouns – and hence the concepts associated with them – tend to be organized into hierarchically structured taxonomies, with class inclusion and part-whole relations as the most common linkages. These are also, of course, the most common relations in OO representations. In human cognition, these hierarchies tend to be fairly deep for nouns – often six to seven layers. These hierarchies support a variety of important cognitive behaviours, including the inheritance of properties from superordinate classes. In contrast, verbs tend to be organized in very flat and bushy structures. This again suggest a central place for objects, in that building inheritance hierarchies will mirror the way humans represent natural categories only if the basic builiding blocks are objects rather than processes or behaviours.

And with the risk of going past what is acceptable amounts of quoting (but this is all closed research, so I have to quote it for you to read it):

[..] human understanding of hierarchies tends to be organized around basic-level classes (i.e., intermediate levels of abstraction that form an anchor point for human classification and reasoning). As described by Rosch (1978; Rosch, Mervis, Gray, Johnson, & Boyes-Braem, 1975), basic-level categories have large numbers of differentiating attributes, whereas, at leves both lower and higher, the differentiating attributes are very modest in number. [..] The tendency in generating class hierarchies for inheritance is to push attributes and behaviours as high as possible. But, to the extent that this is successful, it will lead to hierarchies radically different from those that both users and developers have naturally.

The psychology papers by Gentner and Rosch seems to be very well worth a read for anyone interested in how the brain does categorization “in the wild”.  They are also freely accessible!

It might be forgotten, but originally a large argument in favour of OOP was improved knowledge sharing and better communication about program code between developers and with external forces. Now, you will more often hear arguments about code reuse, if OOP is ever even questioned.  Better communication and knowledge sharing appears to be the main focus of the papers in special issue, but where they also mostly fail to find hard empirical evidence.

As I’ve mentioned before, code understanding and knowledge sharing should be a field of far more interest for developers. That it is hard to find solid empirical evidence to base advice on in that regard is a big, under-appreciated problem!  All the examples from general cognitive psychology appears to provide direction for OO design, but without actual programming-specific experiments it is impossible to tell if that is the case.

And that was a blast from the past…

This is based on a finding by Finnish researcher Jorma Sajaniemi (published work), who discovered that 99% of variables in novice’s code can be categorized in to 11 different roles. These roles are variable uses every programmer will recognize: iterators, constants, flags and so on – although in role-terminology the names somewhat differ (steppers, fixed-values and one-way flags, for example).  Mr. Sajaniemi has also found that these roles matches tacit knowledge in expert programmers – i.e. the 11 roles are also typically intuitively recognized by expert programmers even if it is not explicit or active knowledge.

Whether or not the same 11 variable roles are enough to categorize expert variable use seems harder to pin down, but there is a master’s thesis from their lab finding that they are sufficient. And, not surprisingly, in expert-written programs, the roles have a significantly different distribution. Judge for yourself, is this enough to describe your own variables?

The list is from An introduction to the role of variables, but there is also a more extensive description available.

Sajaniemi’s aim with the research and role concept appears to be teaching programming. For Perl-programmers, it can be interesting to see an article about Teaching Python using Roles, which might tell on how interesting it is for teaching Perl. Otherwise, his research in variable roles seems to revolve around a Java world.

What I find most exciting with this is the approach to studying and extending programming. Instead of going the computer science route, it looks at how people program, identifies interesting patterns and puts forward numbers and testable hypotheses.

Now can this be used to actually extend programming and help expert programmers?

My first observation is that at least five of the variables seem to all play parts in very typical loop patterns, namely stepper, most-recent-holder, most-wanted-holder, gatherer and follower. If this is such a typical way of organizing code, perhaps language design can help this – or perhaps it already does in the immutable states and for-comprehensions of functional languages such as Scala, or the map, grep and higher-order functions in Perl. Or if nothing else it may explain why expert programmers often tend more towards those constructs (or ?).

But if we know these are the typical ways variables are used, how about implementing variable roles (instead of types) with special functionality that simplifies and enhances what they are used for: most-wanted-holders that triggers events, gatherers and followers with history, walkers with an implicit track, organizers and containers optimized for moving elements or not and so on.

But if that is a good idea is hard to tell. At least in Perl, some things can be patched on with a little magical module, so it would be simple to test. I’m playing around with it, and I’ll keep you updated if something meaningful comes out of it. If you know of any other language that implements something similar, please leave a comment!

The researchers working on NPP certainly does approach programming with the aim of making it easier for laypeople, which seems like a turn-off. However, the output of the project is surprisingly interesting to the professional:  Lab studies scientifically testing the utility of design patterns (they are not all great, it turns out), examining how time is spent during programming (35% on navigating code, 22% on reading!) and how we think during debugging (why did this happen?) – to mention some of the research from their department at CMU.

And then they have actually implementation advice and real software to help utilize the findings, like the Java debugging tool WhyLine. You really have to see the 90 second introduction to WhyLine to get the point, but to me it really opens up a whole new world of possible IDE addons intelligently interpreting your code to you.

This is a presentation from the Google Tech Talks which summarizes a lot of the work they do. If you think like me on programming for novices, tolerate the first 7 minutes on making programming accessible – after that it gets good:

A final note relating this to my current programming language of choice, Perl: When Perl was first designed, it was with a lot of thought from Larry Wall on implementing natural language conventions that actually makes sense, like implicit variables, rather than blindly making it like English. Currently, however, few new things in this humanist regard has come out in the Perl world. The largest modernizing effort in Perl is the current, long-running effort to recreate Perl with Perl 6. This, however, is rather playing catch-up with other dynamic languages such as Ruby and Python on technical merits, losing what sets Perl aside as a particularly expressive and truly useful language, namely the natural approach.

At the same time, thorough, scientific study of programming such as the NPP has made serious progress past the “make programming like writing English” idea that usually plague humanist and psychological studies of programming.  If Perl wanted to build on it’s strengths, it would be better reinvented by looking at this kind of approach -how can it fulfill the virtues of a programmer better for experts who are also human?

Not surprisingly, I have some suggestions on what I would have liked to see for a modern Perl, that differs a wee bit from what is being done now:

• An IDE that uses an idea such as WhyLine.
• An IDE with better code navigation tools – watch the video to see some ideas.
• A compiler that compiles your bytecode into human natural language (English) – that is only meant for assisting reading and understanding code!
• A
  use warnings;

  that warns about constructions that are difficult to understand: do you use ! with precedence that readers understand? Do you manipulate more variables in a block than human brains can keep track of? Is your indentation following your blocks? And so on.

• Systematic testing of all the design patterns out there. Can we get quantitative data on number of bugs, development time, maintenance effort and reading time that you can expect when using a specific pattern? Then we would be able to sort out which patterns are worth using and which will be detrimental to your product – a very helpful addition to the current pattern collections and books.
• Variables that even closer follow their semantic use – how about having specialized iterator variables, temporary variables, variables with history and more. (I see that I have to explain this idea further in a later post… Until then, have a look at the idea of variable roles)

Those are some ideas of the top of my head – and not all of them of equal merit..

As the NPP provides statistics on, and as most programmers know by experience, most of your time does not go into writing fresh, new code. For an expert programmer, I dare suggest the act of expressing what you want the computer to do is rarely where the challenge lies in your 9 to 5 job. A programming language and environment that starts taking that seriously would be a truly modern and enlightened language – and winning support would be like shooting fish in a barrel.

In the Perl world, a common criticism of the Perl 6 development is that it is a solution to a non-existing problem. The above, I suggest, is the problem that is just waiting to be solved by a modern Perl.

So Elisheva’s discussion “Swallowing and Elephant in 10 easy steps” on how you go about to understand large, new systems was a very interesting diversion at Perl Monks.  There’s only a few quality thoughts past the original posters musing, sadly, but it is nice to see someone touching this subject in a serious way. Another thought on the subject is written by Chet Hendrickson who offers the suggestion of refactoring and testing for understanding.

Most programmers nowadays are more likely to maintain and extend existing systems than they are to design and develop new ones – at least in a professional manner. Still most programmers focus on how to write code, not read code. And most programmers write code aimed at the compiler or interpreter (which will understand anything that parses),  and not the next programmer (who must read in a non-native language and is usually unable to keep track of more than seven variables at the time). Perhaps it is time for an interpreter for converting code from programming languages to native human language?