Programming as Theory Building

https://algoritmos-iii.github.io/assets/bibliografia/programming-as-theory-building.pdf

The passages discuss a view of programming as theory building. The author argues that the primary aim of programming should be for programmers to build a theory of how problems can be solved through program execution, rather than just producing programs and documentation.

Building a theory involves explaining how the program relates to real-world tasks, justifying why the program is designed in a certain way, and being able to respond constructively to modification demands. This knowledge cannot be fully captured by documentation alone.

The author draws on philosopher Gilbert Ryle's notion of a theory as knowledge that allows one to not only perform certain actions intelligently but also explain and argue about them. Having a theory of a program means understanding how it applies to different problem domains.

Seeing programming as theory building has implications. Program modifications are difficult as they rely on recognizing similarities, which only those with the underlying theory can do. Documentation alone is insufficient for program understanding or "revival." Methods provide secondary guidelines rather than dictating a programmer's primary theory building activity.

This view suggests programmers require high status as knowledge workers, and education should emphasize theory formation through hands-on problem solving rather than just teaching skills and notations. Overall, the passages make a case that understanding programming as theory building leads to better insights into challenges like program maintenance and modification.

Theory building and why employee churn is lethal to software companies

Software development relies on programmers building accurate mental models of how the code works. This theory-building process is crucial for understanding complex software. Constant churn in a development team hinders this process, as new programmers lack exposure to the initial development and must spend time rebuilding lost mental models. The most stable teams are composed of a majority of "first-generation" programmers who were present from the start. Frequent rewriting of code can indicate that no one on the team fully comprehends it anymore due to programmer turnover. As a result, excessive churn is devastating to a project and often leads to failed deadlines and software that acts like disposable products. Maintaining stability in programming staff is vital for software success.