Computer Software Programming the “Right way”
Author: Edward C. Roughgarden
Teach Yourself Programming in Ten Years an article written by Peter Norvig Director of Research for Google.com gives an interesting perspective on learning Computer Programming. I tend to agree with most, but not all, of what he has to say in this article. Mr. Norvig indicates that you can’t learn to be a programmer in days. Just do a search for programming books at Amazon.com or Barnes and Noble to see how many there are that claim you can. Interestingly, many of the books claim it can be done in 21 days. I still don’t really understand what is so significant about the number 21, but I guess that fits into some psychobabble discussion you can find searching MSN, Yahoo, AltaVista, Lycos, HotBot, Ask or any of the other capable search engines. These books can no more teach you programming then how to be the next Tesla or Edison.
To be a programmer takes many projects over a long time. You need a few successful and some not so successful projects under your belt before you can truly call yourself a programmer. You learn good software design by doing. You should also be familiar with multiple computer languages. ‘C’, Basic, Fortran, Lisp, COBOL, etc. this list goes on and on and by no means is in any priority order. No single language is the “right” one. They all have their good points and bad. Some things are easier to do in one language and not so easy in another. Writing a financial application and a computer game are two totally different animals. One needs a high level of security and audit trail, the other may need direct access to the video card. Just because you can drag and drop some controls onto a form and compile it into an executable does NOT make you a programmer.
So what makes Peter Norvig or myself “gurus”? Why are we the expert programmers? “Expert” would imply that we are the best. Nobody is the best when it comes to programming. I have been in the programming business for over 27 years and still would not consider myself an expert. I can architect good software and make money doing it. Things change too quickly in this business to be an expert. You’re constantly learning new things. Of course if you go to experts-exchange on-line you would be led into believing that there are hundreds, if not thousands, of so-called “experts”. In fact, you can get an account and be one yourself! These “self proclaimed” experts can give you snippets of code to answer some “How to” questions but that does not mean that any of them can architect software. “Guru”, now that would be a better word to describe us. A guru as defined by Dictionary.com states that the word implies not only wizard skill but also a history of being a knowledge resource for others. Based on this definition you may find some gurus on experts-exchange but based on their ranking methods there is still no guarantee that even their highest ranked experts are good programmers. Edward Yourdon, now here is a self-proclaimed expert that wrote a sort of good book back in 1975, Techniques of Program Structure and Design. I guess he had a few others also but sometimes I think the man is off his rocker!
There are many web pages of code examples, even Microsoft, where the code is simply bad. I’m not saying that the code will not work. Most of the time it does. There are just some bad programming practices. A seasoned programmer can just look at some of this code and know that it is going to cause problems. You can even find multiple examples on how to do the same thing. Wait! How can there be multiple examples of the same thing in the same language! Which one is the right one? Programming is more of an art than a science. There are literally hundreds of ways to code the same thing. There is no “right way, but there are definitely “wrong” ways. The right way depends on the circumstances. What works for you is the right way. There are many that will tell you that “You must use Class Modules” or “With the proper Object Oriented design you can …” etc. etc. Bull! It’s all nothing but bull! If your boss is breathing down your neck or the client needs it tomorrow, the so-called right way goes right out the window. Does it do the job? Will it continue to work over time? Will it scale up to higher workload, if needed? Was it done in a reasonable amount of time? Is it maintainable? Do people want to use it? (Usability tests) These and some others are the main questions that determine the “right way”. Regardless, of “how” it was coded. Depending on the circumstances, the language doesn’t matter nor the method. It’s the outcome not the method that determines what is good software. You could be using the so-called perfect “right way” method, but if nobody will use it or you can’t deliver it on time then your product is useless.
During my career I have seen multi-million dollar projects fail due to cost overruns and missed delivery dates, doing things the “right way” with highly degreed expert programmers and software designers. I have personally engineered similar projects that were successfully installed and still operational, in multi-billion dollar companies, with half the staff, in a quarter of the time, using programmers with no college degrees. How is that even possible? Which one was the “Right way”?
There is no “Right way” to program computer software and don’t let any of the experts convince you otherwise. There are however, many methods to get your project done, on time within a reasonable budget, but that's another story.
Have a comment? Drop me a note: Comments@Roughgarden.com
