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.

Summary

• Finding bugs in programming involves skills that go beyond programming.

• As an initial response to your program failing to work correctly, you can try rewriting the program to see if you can identify a discrepancy.

• The problem with this method is that if the error is in your conception of the program you are doomed to repeat the error forever and never find the bug.

• Debugging takes us well beyond programming to the scientific method. Adopting this approach means the programmer has to predict what the program will do and implement tests to disprove the prediction.

• When the predict and test method identifies a discrepancy the bug has been found and the program can be corrected.

• One of the biggest problems in the predict and test approach is inventing tests and predictions that pin down a single cause for the bug. Some programmers find this hard, some are very good at it.

• Test Driven Design (TDD) takes this idea to its limit and advocates writing tests that prove the subroutines do what they are claimed to do as the program is constructed. This is an extension of the top-down method to include testing.

• Of particular interest in testing are edge cases, when inputs to a program are at extreme values, and corner cases where more than one input is at an extreme value.

• The task of creating a program is often likened to general engineering, hence “software engineering”, but this misses the fundamental difference between software and hardware – software is easy to change.

• Programming methodologies such as agile or eXtreem Programming try to take advantage of the malleability of software.

• Programs need to be understood by humans. To aid understandability they should be kept as simple as possible.

The Trick Of The Mind - Programming & ComputationalThought

Buy Now From Amazon

Chapter List

1. The Trick Of The Mind

2. Little Languages
      Extract: Little Languages Arithmetic

3. Big Languages Are Turing Complete

4. The Strange Incident of The Goto Considered Harmful
      Extract: The Goto Considered Harmful

5. On Being Variable  

6. Representation

7. The Loop Zoo
      Extract The Loop Zoo
      Extract Advanced Loops ***NEW!!

8. Modules, Subroutines, Procedures and Functions
      Extract Modular Programming

9. Top-Down Programming 

10. Algorithms
       Extract: Binary Search 

11. The Scientific Method As Debugging 

12. The Object Of It All
       Extract Why Objects 

 <ASIN:1871962722>

<ASIN:B09MDL5J1S>

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info