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?

I believe he has some beauty marks on his theory, such as that for every ten man programmer team, there is statistically a nil change of there not being a NNPP on the team. This assumes, in addition to assuming normal distribution, that your team is a representative sample of the world distribution of programming skills and productivity. I don’t think I’m going too far if I suggest that is rather doubtful for most teams.

Overall, however, the article has some advice and insight. For example, Schulmayer argues that the main cause of any programmer having a negative production is lacking management, and he tries to explain how to remedy this.  Also, there are quite a few good quotes, as this one:

John Gardner, in No Easy Victories, said, “An excellent plumber is infinitely more admirable than an incompetent philosopher.” He went on to observe that if society scorns excellence in plumbing because it is a humble activity and accepts shoddiness in philosophy because it is exalted, “neither its pipes nor its theories will hold water.”

But judge for yourself.

Found through Daniel Molina Wegener’s Coder.cl.

Something in the techie DNA results in more weirdness than mere mortals (non-techies). Perhaps this quirkiness is because a certain type of personality is drawn to the techie world. Or maybe we’re somehow transformed over time by our darkened working environments and exposure to computer screen radiation

Personally, I’ve meet a few weirdos, but I think weirdness and skill is generally negatively correlated. Maybe some people just can get away with it easier in the world of programming..

Microsoft has done research on some popular conceptions about software engineering and come up with hard numbers on some factors affecting code quality.  Here are the main findings reported in the artice, with links to the research papers, in case the original is lost forever:

• More test coverage does not equal better code quality, as measured by number of post-release fixes.  Usage patterns and code complexity are the main reason test coverage is a poor predictor of quality.
• Test Driven Development increases quality, creating code that was up to 40% to 90% better in the Microsoft research. The cost is increased development time, 15% to 35% in the same studies. (Realizing quality improvement through test driven development: results and experiences of four industrial teams)
• Use of Assertions decrease program faults. However, this is also correlated with programmer experience, meaning more experienced programmers generally write more assertions and have less program faults. (Assessing the Relationship between Software Assertions and Faults: An Empirical Investigation). And here is more about Assertions.
• Organizational metrics, which are not related to the code, can predict software failure-proneness with a precision and recall of 85 percent. Not only that, but organizational structure was by far the best predictor of code quality, and was at least 8% percent better than the best predictor the researchers could get from code-based measurements. (The influence of organizational structure on software quality: an empirical case study)
• Organizational closeness is more important than geographical closeness, which has no effect on quality (Does Distributed Development Affect Software Quality? An Empirical Case Study of Windows Vista)

Here’s Microsoft’s article: Exploding Software-Engineering Myths (or if that doesn’t work, a Google Cache link).

One drawback with this research is that this is primarily based on case studies, which is a generally poor research method for drawing general conclusions. How valid are these observations for other organizations outside Microsoft? Is the organizational structure of your project or company actually more decisive than your programming methodology?

Also, how transferable is this to other programming frameworks. In dynamic typed languages like Perl, is test coverage more important? I often find that a sub-set of my tests do what a compiler could have done in a statically typed language, or even for Perl if I just had a more automatic testing tool. So maybe coverage would be more predictive of bugs if the compiler catches fewer mistakes? That would be a good candidate for further research.

However, this is excellent as a step towards more evidence-based software engineering.

Found through John Tells All.

[the IT world] is populated by people skilled in creative analysis and ordered reasoning. Doctors are a close parallel. The stakes may be higher in medicine, but the work in both fields requires a technical expertise that can’t be faked and a proficiency that can only be measured by qualified peers.

and

When hiring an IT pro, imagine you’re recruiting a doctor. And if you’re hiring a CIO, think of employing a chief of medicine

It’s not bad at all! Compare me with Dr. House, and I’ll send your article to my friends too!

Ello’s has some good points, though, and probably does a good job as a management consultant. Not because if his amazing insights about geeks, but because his observations can easily be distilled down and applied to anyone who has ever been managed, anywhere: Show people respect and they will like you and do what you want.

But, there is a second opinion. Looking for this I came across this article by Tim Bryce, who appears to hate those low-IQ programmers and their techno-babble, but still has choosen to work for 30 years with advicing people on managing them. Let’s say he takes the other side of the management consultant spectrum from Ello. Now he has some saucy quotes, for example his own “Bryce’s law”:

“There are very few true artists in computer programming,
most are just house painters.”

or:

Whereas the knowledge of the language is vital to performing their job, programmers often use it to bamboozle others and heighten their own self-importance. To outsiders, programmers are viewed as a sort of inner-circle of magicians who speak a rather cryptic language aimed at impressing others, as well as themselves. Such verbosity may actually mask some serious character flaws in their personality.

and the rather inflammatory

Regardless of the image they wish to project, the average programmer does not have a higher IQ than any other worker with a college degree. In fact, they may even be lower.

and it goes on and on like this.

He has the occasional good point, however. Particulary, I find this to hold some truth:

I deliberately avoided the term “Software Engineer” because this would imply the use of a scientific method to programming. Regardless of how one feels about the profession, this is hardly the case.

Programming is often dominated by untested dogmatics, lack of empirical study, arguments-from-authority, opinions presented as facts, try-and-see approaches, voodoo programming and all sorts of other practices that would be counter-productive to, well, great engineering achievements. That’s the things I’m trying to fiddle around with in this blog, only with a focus on the parts that deals with the human side. Of all the concepts in programming, few have been thoroughly tested to see if they are actually as good ideas as they are put forward as. That doesn’t mean they are not, of course, only that we often only have convincing arguments to base decisions on.

If the above got to depressing, here’s another Ello quote to pick the mood up:

A good IT pro is trained in how to accomplish work; their skills are not necessarily limited to computing. In fact, the best business decision-makers I know are IT people who aren’t even managers.

Ok, that was probably the last post I’m going to do in a long time about management, even if it deals with people and programming. Other people write better about it (although perhaps not the two above).

Actually, feel invited to post any links to good blogs about programming managment below, because I don’t really know who these better writers are…

In my interviewing, I began to develop what I thought was an indicator of whether someone was going to be a good surgeon or not. It was a couple of simple questions: Have you ever made a mistake? And, if so, what was your worst mistake? The people who said, ‘Gee, I haven’t really had one,’ or, ‘I’ve had a couple of bad outcomes but they were due to things outside my control’ — invariably those were the worst candidates. And the residents who said, ‘I make mistakes all the time. There was this horrible thing that happened just yesterday and here’s what it was.’ They were the best.

However, the whole book can be summarized with the following koan from the Tao of Programming:

A manager went to the master programmer and showed him the requirements document for a new application. The manager asked the master: “How long will it take to design this system if I assign five programmers to it?”

“It will take one year,” said the master promptly.

“But we need this system immediately or even sooner! How long will it take if I assign ten programmers to it?”

The master programmer frowned. “In that case, it will take two years.”

“And what if I assign a hundred programmers to it?”

The master programmer shrugged. “Then the design will never be completed,” he said.