Pople On Dirac's Famous Remark

The Schrodinger equation is easily solved for the hydrogen atom and found to give results identical to the earlier treatment of Bohr. With inclusion of the relativistic corrections via the Dirac equation, almost perfect agreement was found with experimental spectroscopic data. However, exact solutions for any other system was not found possible, leading to a famous remark by Dirac in 1929:

"The fundamental laws necessary for the mathematical treatment of a large part of physics and the whole of chemistry are thus completely known, and the difficulty lies only in the fact that application of these laws leads to equations that are too complex to be solved."

This was a cry both of triumph and of despair. It marked the end of the process of fundamental discovery in chemistry but left a colossal mathematical task of implementation. In retrospect, the implied finality of the claim seems excessively bold.

In 1929, there had only been one preliminary approximate quantum-mechanical calculation on the hydrogen molecule by Heitler and London, leading to a value of the bond energy of only about 70% of the experimental value. Nevertheless, the physicists were highly confident and most moved on to study the internal structure of the nucleus during the 1930s. In fact, their boldness was apparently justified, for no significant failure of the full Schrodinger-Dirac treatment has ever been demonstrated.


Nobel Lecture: Quantum chemical models
John A. Pople
Reviews of Modern Physics, Vol. 71, No. 5, October 1999, page 1287.

Where Is Software Development Really Learned?

Back in April, Bob Martin of ObjectMentor wrote a blog post, entitled “Master Craftsman Teams,” about software development, team structure, and “maybe this is where Agile got it wrong.” It came out on April First and was a good bit of a departure from Agile and XP which Bob has been a major proponent for as long as anyone. Some would even say the post was anti-Agile.

The controversial post generated a lot of reasoned and well thought out responses. It was described by one commenter as, “a thought experiment.” I would tend to agree. Sort of a “let's shake up the status quo” and see what falls out.

Martin's post was very similar in spirit to an essay written by Peter Gill about density functional theory (DFT) called “Obituary: Density Functional Theory (1927-1993).” Peter’s essay style was like… well an obituary, with a bit of tongue in cheek fun, and was intended to generate discussion about DFT and hopefully provide a jump start to physicists and chemists on atomic and molecular theory. Though in his essay, Peter did not propose a new direction as Bob Martin is doing in his post.

Bob proposes, as his title states, a team of craftsman for software development. This team would have at its center a Chief (Master) Programmer along with several Journeyman programmers and several Apprentice programmers per Journeyman. Bob gives the background for this proposal and describes the basic responsibilities within this hierarchy, the cost benefits, and where to find the apprentices for this craftsmanship. Though I disagree with Bob on several of his points, which I will not address now, he has some very interesting points.

In the article Master Craftsman Teams, I feel the real point that really came out of the post and comments was, “Where is software development really learned?” In school …. On-the-job … self-study, or where?

Unfortunately, in the end I think it is primarily a combination of on-the-job and self-study. As for myself, since I have an applied and computational physics background, then I know it was through on-the-job training and self-study. And, except for a few good exceptions, the work environment was not conducive with learning good software development. Many of the experienced scientific programmers just were not interested in improving their skills for software development. They reached a point and said it was good enough or had other issues to on their mind. Thus often many who are learning under them are content not to grow far beyond their mentor.

Now, I naively thought I was just learning the hard way what C.S. students already knew. But the more I interacted with C.S. students the more I realized that often many of them did not learn it in school either if they learned it at all. My guess is they learning it the same way I am learning it except their surroundings may be a better learning environment.

This leads me to believe the sooner a developer gets real hands-on experience developing software the better. Especially with people who care about software development and continually improving at their craft. This is why I am beginning to think internships and mentoring programs within the software industry and concurrently with formal education is really important.

Here at Los Alamos National Laboratory, there are student mentoring programs for high school through graduate school. There can be perfect opportunities here for those who want to do scientific programming. The real problem is hooking up with folks who do not want to rest on their software development laurels but who really want to be better developers and continually grow.

The sooner you start learning and caring about software development the better. And you do not have to wait for school, internships, or a job. There is a lot of information on the internet to start reading about and learning to prepare you for that first internship or job. Just care enough to do it.

Also see Steve McConnell's blog Chief Programmer Team Update that sheds more light on the IBM development in the 60's.

"For the CPT model to work, the Chief Programmer doesn’t have to be 10x as productive as the worst programmer. He has to do the work of eight or nine people put together, which means he has to be 10x as productive as the average programmer, not 10x as productive as the worst. That’s a very tall order" - Steve McConnell

Beck: Thought on Design Cost

"Design isn't free. ... When you put more design in today, you increase the overhead of the system. There is more to test, more to understand, more to explain. So everyday ... you pay a little design tax."
- Kent Beck's Extreme Programming Explained.

With more experience this is becoming truer and truer. As the design gets more general and seems to be preparing for potential future needs then there is more to test, understand, and explain. And yes it is that simple. That is not even counting the cost of the thought and white board time ( meaning less coding time ) going into the extra design.

Is it often worth the cost?

I am beginning to think not necessarily. Maybe the YAGNI question needs to be applied more thoughtfully to design and design decisions.

Scott Meyers: Good Library Design

Some principles that make for better libraries:

• Make classes and functions easy to use correctly, hard to use incorrectly.
• Obey the principle of least astonishment.
• Avoid gratuitous incompatibilities with the built-in types.
• Use const whenever possible
• Avoid duplicating code.

Scott commented that the first principle listed is a "Hallmark of a professionally designed library."

And the for the third principle listed, "When in doubt, do as the ints do."

This is from material and notes taken at the 2002 C++ Seminar in Boston during the session about Library Design and the C++ Standard Library by Scott Meyers.

These still seem like sensible principles to keep in mind as one develops code.

VAX/VMS

Recently, I found another blast from my past. I used this VAX/VMS book to write many of my DEC Command Language (DCL) scripts back while at Texas Tech in the late 80's and early 90's. I really enjoyed VMS and DCL. Tech, like many universities back then, had DEC systems for mainframes and even the physics department had a MicroVax.




I liked DCL over Unix script languages since DCL used command and keywords that made sense. Unix which uses "grep" for a search command whereas DCL used "search." Tell me which one is intuitive to remember? Of course grep is probably more powerful.




Recently I was lamenting about the VAX/VMS and found out that the cancelled F-22 fighter used the VAX/VMS OS! This was pleasant surprise. Cool.