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