Software Engineering discussion

More debugging discussion here, which has me wondering about the downside of the invention of interactive debugging. Now, a programmer can sit and churn code with little thought, trying to get it to work. The batch debugging approach forced some think time. I am not suggesting a step backwards, but I think that is a big factor in overall debug productivity.

Again, it is interesting to see the origins of change control, along with the introduction of "new" ideas like stepwise refinement and structured programming.

The one surprise, at the very end, was the suggestion that small, frequent changes to a code base would be chaotic and large, infrequent changes preferable. The agile and daily build experiences these days counter that view.

This chapter reminded me of the "... Ant Fugue" from GEB, specifically the REDUCTIONISM, HOLISM, and MU picture.

I'm certainly guilty of using interactive debugging as a crutch in many cases. Although, I think there are many cases where interactive debugging saves time and is very useful as a teaching tool too.

Yes, the top-down refinement sounded alot like going from Use Case diagrams through an OOA&D process.