Programmer Productivity Pumped Post Picture-Picking Paradigm?

Mitch Barnett responds to No Silver Programmers with a discussion of visual programming in BizTalk:

[Y]ou drag n dropped onto the canvas (kinda like Visio) and then you would set a bunch of design time properties and sometimes call out to some C# assemblies, or web services or adapters, but most often it was a matter of using the design surface, which included a designer for mapping one file format to another and a rules engine design surface, etc.

If you thought of the designers as “raising the level of abstraction” or a visual Domain Specific Language, in a lot of cases, not much real C# code was written ? you spent most of your time in this abstract kind of world.  Point being, when I was hiring programmers, like in the traditional sense of yeah, I can write lots of C#, I found that some programmers found using the designers, very easy and others, just could not get their heads wrapped around, to the point, that they could not actually do the job ? period. 

Meaning that in this specialized instance, I found programmer productivity was totally dependant on how well your head dealt with abstractions and not traditional programming constructs ? to the point where some of my guys could whip out a BizTalk solution in a matter of days, others maybe a week or so and others, never.

[Emphasis Added]

Just to be a skeptic, I’m not sure that there’s just 1 thing (raising the abstraction level) going on when you’re developing on a design surface. You’re engaging the visual and spatial and pattern-recognition components of a your mind in a way that, perhaps, leads to different problem-solving skills (whether inherent or learned). I dunno’. The interesting thing would be to study the problem-solving ability of developers using a visual design surface with an equivalently high-level abstraction that used a text representation (block_1 = new Foo; block_2 = new Bar; block_1.outputPlug1 -> block_2.inputPlug1; etc…)

A related point, and an important one, is that different languages “engage” your mind in different ways and part of the joy of being a computer programmer is finding a good match (or better yet, good matches) for your particular wiring. Personally, I quite like pictures in some development tasks, but have never found a visual design surface that actually delivered a high-enough level of abstraction (in terms of “things you can do with code,” i.e., meta-programming, reflection, code generation).

Hackstat : A Framework for Software Development Process Data

Philip Johnson tells me by email of Hackystat:

[A]n open source framework for collection, analysis, visualization, interpretation, annotation, and dissemination of software development process and product data….

Hackystat aspires to be the “Apache” of software engineering measurement systems: open source, standalone, scalable, extensible, and platform and technology neutral.

Our current thrust with Hackystat is “Collective Intelligence for Software Developers”, and we are thinking about things like annotable Simile/Timeline representations, mashups with Facebook and Twitter, and other ways to create a kind of collaborative sense-making between man and machine so that metrics can be reliably and efficiently refined into actionable knowledge.

I’ve long been a fan of metrics, but traditionally programmers have resisted the introduction of metrics due to a (probably reasonable) fear that simplistic measurements would be tied to performance reviews, e.g., “Gee, you didn’t add nearly as many lines of code to the system as Bob. No raise for you!”

Hopefully, the time of such fears has passed and Hackystat or a similar project will start giving us some of that missing data.