|The Trick Of The Mind - Debugging As The Scientific Method|
|Written by Mike James|
|Monday, 12 December 2022|
Page 4 of 4
Fixing Programs is Easy!
Finding bugs is generally a difficult problem involving repeated iterations of the predict and compare cycle. However, once you find the bug, fixing it can be very easy. All you have to do is type some lines of code that do the job correctly. Even really difficult bugs only involve typing something to fix them. Compare the task of changing a program to that of changing say the design and implementation of a bridge or any big engineering project. If you suddenly discover a design flaw in a bridge that has been built and in use then fixing it can be a bigger problem than building it in the first place. For this reason most engineering projects strive to get things right before implementation begins – because getting it wrong is very, very costly.
Software Is Different – Move Fast and Break Things
As what happens is defined in a text document, fixing any programming problem is a matter of simple editing. Changes are quick and, compared to most engineering projects, cheap. There is a big tendency to try to turn programming into something more like engineering – there is even a subject area called “software engineering”. Such efforts are well-meaning, but they are likely to be throwing away one of the main advantages of software if they are taken too far. Software is very changeable and this in itself has given rise to approaches to the problem of creating it.
The antidote to software engineering is probably Agile programming, or its cousin eXtreme Programming. Both of these acknowledge the easy changeability of programs as part of their overall philosophy. It is also responsible for the Facebook programming motto “move fast and break things” which is what founder Mark Zuckerberg instructed his programmers to do. A little later he amended this to “Unless you are breaking stuff, you are not moving fast enough.” Such utterances are mostly incomprehensible to the more formal “engineering” world, but they are perfectly reasonable if you take into account the nature of the beast we are trying to tame. Software is so changeable that you can try things out very rapidly and this is a good way to learn what works and what doesn’t. Of course, the downside is that people trying to use the software have to suffer the breakages unless they are caught before they make it into the outside world.
This view of software as something that can be rapidly created and rapidly modified in comparison to other production processes is something that today is still under-appreciated. What everyone is familiar with is the fact that all software is buggy and the standard solution is to focus on the quality of the initial code rather than the rapidity of applying a fix.
Programs Are For People
This predict and test method of debugging, and it really is the only method, also forces us to accept another deeper truth. Programs are for people, not computers. The most crucial step in predicting what the current state of the program should be is understanding the program. You might at this point think that this is easy if you have just written the program. While it is easier, it is not always easy.
This is where everything we have been discussing has to come together to enable us to write programs that are fit for human consumption. In the early days programmers had to concentrate on writing programs that would satisfy their computers. Today we have the hardware that enables them to concentrate on satisfying other programmers. A program that is easy to understand is easy to debug and easy to extend without introducing further bugs.
Understandability is an obvious goal for programming once you start to think about it – unfortunately many programmers don’t think about it. As a practical craft, programmers can produce programs in much the same way a carpenter can create a piece of furniture. You don’t have to be a philosopher of wood to create wooden objects and you don’t have to understand what programming is all about to produce a program – it is an artisanal craft. However, unlike carpentry, we don’t all agree on what wooden objects are admirable.
Dijkstra summed up the situation and his comment still holds today:
"Two opinions about programming date from those days. I remember them now.
The one opinion was that a really competent programmer should be puzzle-minded and very fond of clever tricks; the other opinion was that programming was nothing more than optimizing the efficiency of the computational process".
Clearly neither opinion is appropriate. Programmers still value “clever” tricks over simplicity. They see programming as a testing ground where being smart is better than being simple.
Again Dijkstra summed up very well what he, and we, should hope for:
“As at the moment of writing the students that followed this course have still to pass their examination, it is for me still an open question how successful I have been. They liked the course, I have heard that they described my programs as "logical poems", so I have the best of hopes.”
Programs should be expressed in the simplest form possible but what constitutes simple? There is no easy answer to this and it is still very much under development. As programming and its philosophy develop we have new ideas of what is simple. What really matters is that we all try to construct logical poems in our programs and our more general thought.
The Trick Of The Mind - Programming & ComputationalThought
Buy Now From Amazon
or email your comment to: email@example.com
|Last Updated ( Monday, 12 December 2022 )|