After writing about the Software Engineering Myths Microsoft claims to have busted, I’ve been thinking about their find that organization structure is the most predictive factor for bugs. 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[…]

How do programmers differ, and why should you care? Steven Clarke from Microsoft’s usability labs has identified and demonstrated at least three different programmer styles, which has been reported in quite a few places, hence programmers do indeed differ. The types Clarke found are: 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[…]

This is just a quick quote from the course description of a ten year old course in Cognitive Psychology and Computer Programming at the Texas A&M: 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[…]

As a programmer, you write for two very different kinds of readers. One is the rigid computer platform, the other is the human maintainers of your code. For the former we have quite conclusive guidelines on what works, but the latter is only consistent as a source of disagreement and uncertainty. Typically the guideline is “Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.“, while most people end up writing as if the person maintaining the code is themselves. 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[…]

15 years ago, the research journal Human-Computer Interaction published their special issue on Object-Oriented Programming.  Having realized that a lot of the claims made about OOP at the time were not technical in nature, but rather were psychological and cognitive, the special issue attempted to present empirical and experimental research examining the claims about OOPs advantages on procedural programming. Or as the editor Bill Curtis notes: 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[…]

I promised to explain better the idea of variable roles I mentioned in the previous post about natural programming. 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[…]

When I hear people start talking about “natural” programming, easier ways of programming or making programming available to non-programmers, I get very skeptical. It makes me think of Logo and Turtle Graphics, or programming languages made to be more similar to natural language. It’s like you could make a simpler English to make it easier for non-authors to write literature. So when I first read about The Natural Programming Project, I balked – although for no reason. 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[…]

Occasionally, programming forums take a step back from the nitty gritty implementation details and look at the bigger issues. I wish they did more often, as “occasionally” means pretty much close to never. Most discussions in technical forums rarely go past what you can find in the manual, while the big things that can make or break a project (or a programmer) goes unmentioned. 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[…]