Additional profile information on Alfred Thompson at Google+
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.
While I write here primarily for computer science teachers I know that many who read this blog are professional developers and others who may be interested in this sort of educational/professional development opportunity. It's probably only of interest to those of you in New England but if you are it may be very interesting.
Bob Familiar and Chris Bowen have "decided to take their long winded rants and questionable demos to a city near you." Specifically:
Both of these guys know their stuff. They will be focusing on things related to .NET Framework 3.0 including Windows Communication Foundation, Windows CardSpaces, Workflow Foundation and Windows Presentation Foundation. There is much more information on their blogs. (Bob's blog Chris' blog)
This year National Engineers Week (in the US at least) is February 18 through the 24th. There is some good information about engineering as a career at that web site including the following links:
Discover Engineering OnlineIntroduce a Girl to EngineeringThe Sightseer's Guide to Engineering
It's nice to know that there is a week to honor engineers and the engineering field. This may be an opportunity to point your students into a different and possibly new area.