Biblical Model Of Training

From what I can see as a recurring theme, the recurring variety of training we see in the Bible is life-on-life.

Jesus poured his life into twelve men and many benefited from the overflow. Several years ago at OOPSLA, ChristopherAlexander remorsed (paraphrased) "You pour several years of your life into some people and have an impact. They in turn influence others. But the whole process is too slow." My response to this is, if it is the path the God of the universe chose to follow, we should not expect to come up with something better.

Before the Israelites went into the promised land they were told "You shall teach [his commandments] diligently to your sons and shall talk of them when you sit in your house and when you walk by the way and when you lie down and when you rise up." (Deut. 6:4). I.e. all the time.

There are many examples throughout scripture of "following" and many of the contexts seem to imply "following example". It is about seeing how truths are applied. This is true for life, and software development is just something we do when we are living it.

Certainly there are many words exchanged (both written and verbal) but people learn by doing, by example, and by using discernment in how to apply things differently based on context. They need to encourage each other and hold each other personally accountable.

People are more important than process. I realize that learning by example can be called a process...and we have processes for a lot of small things (e.g. ContinuousIntegration). The point is that the processes we use should be subject to the importance of the people using them, not the other way around.

-- KenAuer

I agree with the above. However, I must make a couple of notes. The truths God is teaching through His methods are universal and forever. Better yet, only He knows how long He has. Speed is less important than depth.

OTOH, there may be other ways to teach temporal truths. For example, ExtremeProgramming is based on certain assumptions about the complexity of software and the maturity of tools. We think it works well around year 2000, know that it would have failed badly in 1980 (we just didn't have the hardware for it), and it may well be obsolete by 2020. Sometimes, we just don't have the time to run our students through the desert for forty years to make sure that they get the point.

--RobMandeville

Concur. It's kinda hard to compare the way He teaches His Truth to the world at large versus the way we need to convey a very narrow range of skills to a very specific audience. His Way is eternal; our way is ever-adapting. There really isn't a good way to draw parallels here, is there?

Okay, I can dig the part about concentrating your efforts on a small group of disciples, but after that the analogy stops working. For sure we should all be searching for those truths about software development that transcend time, tools, methods, product domains, and people. But the entire field of software development is so young as to make such an effort nearly meaningless; there simply isn't enough history behind the creation of software to really tell what will be true in twenty years, much less a hundred.

Stay tuned, folks, the ride is just getting started.

-- MartySchrader