The Future of Programming
The world greatly depends on computers, in the future it will become even more reliant upon them. But how much of a future is there? The physical computer is nothing without the programmers who tell the computer what to do and how to do it. While there is no shortage of programmers there is a vast shortage of creativity and innovativity among them. What’s worse is how the term quality seems to have been forgotten in the shuffle, with more and more programmers not paying attention to the details that once allowed them to create quality software. Not only do we risk a future of a standstill on standards but a future where the quality of the programs continues to degrade.
I originally got involved with programming computers because I couldn’t resist the possibilities. With life and reality there are many limitations and restrictions. What fascinated me with programming computers is there are no limitations, you are only limited to however far your imagination can take you. You can create things that have never been seen, heard, or even ever thought of before. You can create and do things that would be impossible in real life, from making applications that do things hundreds of times faster then a human could, to creating games that take you to new worlds and places that could only exist in one’s mind. It can all be done with computers, and it is all made possible by good programmers.
iD Software made and broke many of the rules of programming and computing when they created Wolfenstine, Doom, and Quake. All defied what people thought could be done and broke many of the standards of their respective times. The innovative programmers at iD Software never let what had/hadn’t been done or what other people said could/couldn’t be done stop them. They pushed ahead by conceiving new ideas and developing those ideas/dreams into their software thereby making those ideas a reality. For gamers around the world iD has earned themselves a name that very few other companies can compete with. All because they refused to accept the way things were. They decided to take a risk and step into the unknown, designing/developing something that had never been attempted on such a scale before.
Microsoft has done much the same things with their programs. Constantly pushing them to the limits implementing new features and integrating new ideas into them. Over the years we have come from a text based MSDOS to a fully graphical Windows95/NT. They have increased the productivity of computer users around the world by countless amounts. MS has brought the world of computing to the future and even as you read this they continue to bring us even closer to it. This is what separates the good from the great. The great are never satisfied, they can always improve on their work taking it to the next step in computing and pushing their programs ahead to the future.
New Ideas, New Methods – The Push to the Future
Don’t get me wrong, standards in programming are there for a reason. But a programmer set those standards and it will be a programmer who steps up to the plate to create the new standards. As all of the creative/innovative programmers decline who will be here tomorrow to progress programming to the next level? If nobody creates the new standards then computer software will go no further. As an example, If iD software hadn’t improved on the standards/ideas they set forth with Wolfenstine, Doom and Quake never would have evolved.
Rather then being encouraged to come up with their own ideas and work towards a better way of doing things, most programmers are taught one way of doing things and are warned never to deviate from that allotted method. Maybe it’s a flaw in the teaching methods not allowing for individual thought and ideas, or maybe it’s a flaw in programmers nowadays looking for the easy way of doing things. But no matter what the reason, it is most definitely a problem. Very few programmers and even fewer companies nowadays try to set new standards with their work.
The programming industry needs more programmers that don’t accept things the way they are. Programmers that are constantly trying to improve on pre-existing programs, and programmers that will conceive and create totally new programs unlike anything else in the industry. There are very few companies that seem to promote this, Microsoft being one of the only ones that comes to mind. They even run contests promoting creativity, new ideas, and new standards offering prizes to those that can design the best ActiveX controls etc.
Quality Starts at Home
On a more individual basis the industry needs programmers that genuinely care about their work and programs, and that continually find more ways to improve on them. If each programmer took a greater interest in the quality of their work, the programming industry would be a better place. There is a saying shared by many cultures from around the world that talks about how a part of your life, a part of your essence, and a part of you is kept in everything you make. Each of us puts of ourselves into the different projects/things we create in our lifetime. If you don’t do the best you can on a project it does nothing but reflect badly upon you. The legacy of many of the programs and standards we create now will be around long after we are gone, so how do you wish to be remembered?
There are many things that make a program into a quality program. From a good/easy to use user interface, to optimizing your code to work at peak performance, to using some of the lesser known trade secrets, to providing a lot of functionality in your program, all the way down to creating an easy to understand yet comprehensive on-line help system. Many programmers seem to neglect these nowadays. For instance a lot of programmers think performance must be sacrificed to provide more functionality. However, many programs offer a full range of functions without sacrificing performance. A good example here is to compare the performance of MS IE 3.0 vs. Netscape 3.0, both offer pretty much the same options but IE is considerably faster then Netscape. If you optimize your programs correctly you can add more functionality with little to no performance drop.
The key here is to take the time needed to produce the quality software. Rushing things does nothing but create cut corners and programs of lesser quality. With the ever growing time constraints being placed on programmers to get the job done, more and more programmers are sacrificing the high quality of their work just to get the job done faster. This just shouldn’t be done. If it can’t be completed in the estimated time the last thing you should ever do is sacrifice the quality of the work or cut corners. I know of many companies that do this and the thing I always hear back is how sorry they are they did it. People pay for the software thinking it will be of the high-quality that they have come to expect form that company and get nothing but disappointments. In the end what happens is as the word gets out that the software isn’t’ as high quality as previous versions the sales drop off and the companies name/reputation becomes tarnished. It’s better to take an extra week or to give slightly larger estimates of how long a project will take to make sure that the quality is still there. As a rule of thumb, if you are not 100% satisfied with your work or you are not proud to have your name on the project, it probably isn’t fit to be released.
Final Thoughts
So in the end, my best tip is to never stop looking for new and better ways to do things. Just because you hear or read something telling you how to do things or what can or can't be done. Don't accept it. There are many ways to accomplish that which you want to do. Programming methods, when designed, are integrated to do a certain function the development team had in mind. However, many times the advanced programmer can find ways to use those very same methods to do things they were never intended to be able to do.
Keep the quality software coming, if you aren’t overjoyed with it’s performance and appearance, then it’s not done to the level of quality it should be. Never be afraid to take your time. A company would much rather have software that performs and works better then the competition then have shoddy software that they then have to fix later on. Always overestimate how much time a project will take, this will give you some extra breathing room should something go wrong or the quality standard not be met. Always try to meet your deadlines, just not at the cost of the quality of your programs. If your project runs over the estimated time you may wish to take yourself off the clock so that the company paying for it isn’t getting stuck with the bill.
To the beginners, don’t jump in head first. You don’t jump into the deep end of the pool without knowing how to swim. Start with something easy and work your way up to more complicated programs. A good program to start with is a text editor like Notepad, then gradually work your way up. Always keep backups of your work in many different secure places. Having a HD sector go bad or a HD crash can be quite detrimental to a project if it’s not backed up. Also keep archives of your backups so you can go back and unarchive the backups form a couple days ago if you need to.
I Wish You Success In Your Programming Endeavors,
Dave Sherman ( WHiZ )
One of the finest books on programming I've ever read was not related to any specific programming language. The book, "Code Complete" (Steve McConnell, (c) Microsoft Press, 1993) is "A Practical Handbook of Software Construction", and details problems and solutions in the programming process. The book focuses on the actual construction phase, which partly encompasses design and testing, but primarily focuses on Coding and Debugging. This is a book which every programmer should read. And while I certainly can’t replace his book, nor would I even try, I will attempt to discuss one of points which has had the greatest impact on my programming accuracy and performance. So I urge you to consider this concept in your programming, and to read Mr. McConnell’s book as soon as possible!
Procedure Definition Language
Programmers are doers. We like to get in there and make things happen. However, we too often don’t think things through before we dive right into code. Then we get halfway into a complex procedure and find ourselves with an overly complex solution to what we thought was a simple problem. Why does this happen? Because, to use a potentially painful metaphor, we dove into the pool and found out too late which end we were at. Even worse, we whip out a function, and then a month or so later we need to go and make a change, and can’t remember how it works because we forget (in our rush to make things happen) to comment our code.
Fortunately, there’s a very helpful and easy to use technique to help avoid both problems. That technique is PDL - Procedure Definition Language. PDL is not written in any computer based language, but in clear English. Its a step by step listing of all the things a procedure needs to accomplish, in order, including decision branches and calls to other procedures. In essence, its writing out comments before you write a word of code. All too often we get halfway into a process before we realize we’ve got to go back and change what we’ve already written. Every programmer gets attached to their code, and having to go back and change it after we’ve invested "blood sweat and tears" into it hurts. By using PDL, we write out simple steps in English which can be modified or rewritten very easily before we invest a single line of code into the procedure. In addition, it helps early on to identify areas of a procedure which really belong in their own function. The ultimate result, then, is increased efficiency due to better planning, well commented functions, and faster production time because of heightened accuracy writing the code the first time.
Building a PDL procedure is done in two parts. The first part should be a comment block which identifies the purpose of the procedure being written, and a general concept of the flow of that same process. The second part is to expand that comment block into a series of step by step instructions. These instructions should be specific enough to outline specific steps which need to be taken in the procedure. This isn’t to say that there should be as many lines of PDL as there ultimately are of code, of course. However, the more granular the PDL, the better comments as well as the planning, and the more likely that algorithm-bug free code will be the initial product.
Below is an example from an application I’m currently working on. This particular section of code controls the startup of the application. The first section is the PDL which was written prior to the actual construction of the code. The second section shows the actual completed code.
Private Sub Class_Initialize() ' This routine performs the actual application startup. All necessary connections
‘ are initialized, object structures created, etc. frmSplash.SetStatus is used to
‘ keep the user informed of the current activity and show progress. (Perception of
‘ action makes the application appear faster, even though the actual
‘ implementation slows it down slightly.)' Set hourglass
' Initializes application and all child objects
' Locate the application options storage area. (INI file in 16 bit, registry in 32 bit)
' Bring up splash screen
' Connect to data sources - if it fails, exit
' Once connected, get local user information such as username, level, etc.
' Load the mdi frame into memory
' Prep account structure
' Prepare starting screen - list of accounts
' Load external component references
' Display the MDI Frame and list
' Remove splash screen and hourglassEnd Sub
Private Sub Class_Initialize()
' This routine performs the actual application startup. All necessary connections
‘ are initialized, object structures created, etc. frmSplash.SetStatus is used to
‘ keep the user informed of the current activity and show progress. (Perception of
‘ action makes the application appear faster, even though the actual
‘ implementation slows it down slightly.)Dim mp As Integer
Dim DbName$, UserName$, Password$, ODBCConnect$
Dim TempRS As Recordset, SQL$' Set hourglass
mp = Screen.MousePointer
Screen.MousePointer = vbHourglassWriteDebugFile "Initialization", "Application.Initialize"
' Initializes application and all child objects'Locate the application options storage area. (INI file in 16 bit, registry in 32 bit)
WriteDebugFile "Access initialization parameters", "Application.Initialize"
#If Win32 Then
gINIFile$ = App.Name
#Else
gINIFile$ = App.Path & "\UDSS.INI"
#End If' Bring up splash screen
frmSplash.Display
frmSplash.SetStatus "Connecting to Database", 5' Connect to data sources - if it fails, exit9
If Not ConnectDatabases Then ' This process updates the splash screen to 70
frmSplash.Quit
Me.Quit
Exit Sub
End If' Once connected, get local user information such as username, level, etc.
SQL$ = "SELECT USER_FIRST_NAME, USER_LAST_NAME, _
USER_UDSS_LVL FROM "
SQL$ = SQL$ & DBCreator & ".CATUW12_USER WHERE _
USER_UDSS_ID = '" & gCurrentUserID$ & "'"
Set TempRS = OpenBackEndRecordset(SQL$)
gCurrentUserName$ = Trim$(TempRS.Fields("USER_FIRST_NAME")) _
& " " & Trim$(TempRS.Fields("USER_LAST_NAME"))
gCurrentUserLevel% = TempRS.Fields("USER_UDSS_LVL")
Set TempRS = Nothing' Load the mdi frame into memory
frmSplash.SetStatus "Initializing MDIFrame", 75
MDIFrame.Hide' Prep account structure
frmSplash.SetStatus "Initializing Object Tree", 80
Set Me.Accounts = New Accounts' Prepare starting screen - list of accounts
frmSplash.SetStatus "Preparing Account List", 90
frmAccounts.Init' Load external component references
frmSplash.SetStatus "Locating Components", 95
GetComponents' Display the MDI Frame and list
frmSplash.SetStatus "Underwriting DSS Initialized", 100
MDIFrame.Display
frmAccounts.Show' Remove splash screen and hourglass
frmSplash.Quit
Screen.MousePointer = mpEnd Sub
Hopefully, by comparing these two examples, you’ll see how building the flow of the program into the comments first helps planning and efficiency. If you’re not convinced, consider this: I have never had to debug this procedure. In fact, the most I ever had to do was add a line or two to the "get user info" section when we added more information. By writing the PDL first, I had a map telling me where to call other functions, when to do logical tests, and so on. Its when I don’t spend enough time in PDL that I wind up with code that gets tweaked and tweaked again.
One final point. If you fail to comment and properly plan out your code, then one day someone may come along and develop a strong desire to find you and punish you for your sins. If you’re a solo-programmer, that person may very well be you. I can’t tell you how many times I’ve gone back to a program I wrote a few months earlier and been totally lost. By use of PDL, I make code maintenance much easier, and the long-term savings of easy to maintain code should be self-evident.
This is by far not the only area where programmers tend to fall short. If you are serious about developing not only good coding skills, but also good programming methodology, you will get Steve McConnell’s book.
See you on-line!
Charles Haeberle ( TJack )