TechComm Labs

Jeff Atwood had a gestalt on reading a paper by Tom deMarco.

I can publicly acknowledge what I’ve slowly, gradually realized over the last 5 to 10 years of my career as a software developer: what we do is craftsmanship, not engineering. And I can say this proudly, unashamedly, with nary a shred of self-doubt.

There has been this thing about trying to make the creation of the code required to make a computer do something a science or an engineering effort. It never quite fit. Proper “computer science” is really just a branch of mathematics. “Software engineering” is more of a management job that a software development activity – and management is not engineering.

Still, adding “science” or “engineering” to something has an appeal. But that doesn’t make it right.

With this paradigm shift from looking at software development as engineering to the craftsmanship point of view, many things make a bit more sense. One is the fact that some coders are orders of magnitude more productive than others. Another is the fact that some produce a much higher quality of work than others. Another is the fact that rank amateurs and self taught coders can create usable product. An engineer is trained but a craftsman develops skills via apprenticeship.

This idea has implications for the formation of teams and for the supervision and management of human resources. It could be worthwhile to think of software development as an effort of craftsmen and not as software engineering.

Mechanical Engineering Magazine has a rundown on Thomas Davenport and the invention of the electric motor – The blacksmith’s motor.

This was in the early nineteenth century when electricity and magnetism were being explored as usable phenomena.The Davenport story is one of an individual who would ride a horse near 30 miles to see an electromagnet in action and then take near any source of cash into playing with the phenomena.

Inventing a motor was one thing, getting the Patent Office to accept a patent in a new field was something else. That is where luminaries such as Joseph Henry, Stephen Van Rensselaer, and Amos Eaton come into the story as Davenport has to solicit the support of his invention from the prominent academia of the day to gain credibility with the Patent Office.

All in all, it wasn’t until near forty years after Davenport’s death that the motor began to move out of the bleeding edge category into something of commercial value. That was due to followers, such as Edison, who could solve the problem of finding power to drive the motor.

Good story, good read,

Design Line features a reminiscence of Jack Crenshaw about Calculating trajectories for Apollo program. This was an effort in the early 60′s in the Theoretical Mechanics Division at NASA, at Langley Research Center.

In those days, we didn’t have spreadsheet programs to draw graphs for us; we had to draw them ourselves. As low man on the TMD totem pole, I got elected to run parametric studies on the computer and plot the results. That task worked in my favor, though, because I gained an understanding of the physics of the problem and the relationship between parameters that I don’t think I would have gotten, otherwise. I wasn’t content to just make runs and plot curves; I wanted to UNDERSTAND what was going on, and I think that put us ahead of the Rand guys

The way to use a computer was to define a program to be written for the coders who implemented it in IBM 702 assembler. That would generate numbers which needed “desk checking” to make sure the program was working as intended. Then the numbers would be manually plotted to created graphs for analysis.

Generating a lunar trajectory is not easy. The problem is a two-point boundary-value problem, complicated by the fact that both points (the launch and return sites) are fixed on a rotating Earth, and we have the “minor” midpoint constraint that the trajectory come somewhere near the Moon. We quickly learned that simply trying to guess at suitable launch conditions was a hopeless venture. Therefore a large part of my energies went into building quite a number of patched-conic approximations, programs to solve the complicated spherical trig, front-end and back-end processors, and “wrappers” for GE’s N-Body program. My crowning achievement was a fully automated program that required only the barest minimum of inputs, such as the coordinates of the launch and landing points, plus a few other things such as year of departure, lunar miss distance, and lighting conditions at both the Moon and Earth reentry. The program would then seek out the optimal, minimum-energy trajectory that would meet the constraints.

To handle these calculations, the computers ran at the equivalent of about a 1 MHz clock with a 32K working memory. They did have hardware floating point capabilities and word lengths up to 60 bits which allowed for some serious number crunching. Batch mode, highly optimized assembly code, and no distractions made it work.

Those were the days – but kind of like realizing that modern toilet paper has a history of only 150 years or so – it certainly provides a perspective on how things have changed in this era.