Programming Proverbs 3: Use the top-down approach

This is the third of a series of posts based on the book Programming Proverbs by Henry Ledgard. The index for the series is an earlier post and discussion of the list as a whole is taking place in the comments there. Comments on this "proverb" are of course very welcome here.

When the book Programming Proverbs was written a new paradigm of programming was struggling to become accepted. It was called "Structured Programming" and it was a powerful new way of thinking about coding. I was a college student at the time and my professors were early adopters of this new way of thinking.  We were treated to lectures both at university and other places on the topic. There was great discussion about could this new way of programming be used with the languages of the day (FORTRAN and COBOL were huge, BASIC was being used as the new teaching language) or would new languages have to be developed. Dijkstra's screed against the GOTO statement was widely discussed.

The top-down approach was gaining ground as a design methodology that supported structured programming. Today we tend not to talk about it so much. We don't talk about structured programming as such either. that is just the way things are. Although admittedly object oriented program is the way we think about both structure and design there is a lot of top-down and structured programming at its heart.

I still like the idea of top-down design today. Basically the idea is that one takes the overall project and breaks it down into small and smaller parts until basic building blocks are designed. I think that is still the right way to go even if the building blocks we use today as often objects rather than old-fashioned subroutines.

One of the comments to the index to this series references a claim that things like IntelliSense encourage bottom up design. I think that is incorrect though. I think it leads to writing code from the bottom up but that is not the same as designing from the bottom up. I think that if you are following the first two proverbs of "defining the problem completely" and "think first, program second" that you know what the classes and methods you are going to write are going to be. Once this happens you can either program from the top down or from the bottom up. If the design is done and done correctly either way will probably world.

In fact I would argue that the work of a large system can actually be split up with someone doing the top level, others doing the middle level and still others doing the lowest level at the same time. It will work if the design has been done well. It will of course fail miserably if the design has not been done well. But then without a good design any method of coding will fail.

One can write a lot of classes with wonderful methods and data structures but if the design is not already done there is no point in doing so. Unless there is agreement on how those bottom pieces will fit together into larger ones something is bound to go wrong. Starting at the top is the way to go.

Technorati tags: programming proverbs, education, coding, design