Going through my GoF Design Patterns a while back had me arrive at the relevation that all the underlying complexity is not necessary. Not everyone needs to have atomic comprehension of the underlying details in order to architect and construct. The design patterned future will strike a proper dichotomy between the design-patterned architect and the computer scientist and engineer.

I think someday, design patterns will formulize into architectural languages of the sort where you call forth your observers and factories and flywheels and assemble them into place at a high level. Does an architect need to know the metalurgical analysis proving the steel beams or the rational behind the heights of door frames to architect well? Not really.

I think in the earlier days of Microsoft even, the definition of a good computer programmer was a person who can write a quicksort in the smallest, tightest, cleverest and most succinct piece of C code. When people applied for a job at Microsoft, the person who wrote multi-line commented sorts was penalized, and the person who leveraged the system qsort() function was looked down upon, and the guy who wrote something clever in 3 lines was hired. Interestingly, the emphasis to reinvent the wheel, but more clever each time led to products universally accepted as bug ridden and terrible. I think in the recent years with the adoption of high level patterns we're starting to see fruits of that in a lot of their software.

I think the discipline of software engineering, in order to make the design/architectural leap forward has to stop penalizing the lack of algorithmic knowledge of every little thing that spins beneath the surface, and reward the big-picture thinkers. Which is not to say that fundamental knowledge is not necessary or important -- just not a critical requirement.

The guy who wrote up the solution for 7 instructions versus the "optimum" 11, the code does not resemble the proper solution in any way. It used some kind of oscillating counter that doubled as a way to calculate the sequence and as a way to modify the running code itself. He explained it to me with an analogy of climbing a ladder. Something like that.

Calvin