Program Efficiency: A Preemptive Strike
Developing efficient programs is a multifaceted problem with so many proposed solutions that it often becomes confusing to decide what work flow to follow. Rather than focusing on the development of a program directly this post is going to focus on what can be done to create more efficient programs before a single line of real code is even written. Pre-programming standards have seemed to deteriorate as programming has grown older.
The first step in creating an efficient program is to have some sort of over arching goal in mind. While in school usually this sort of thing is done by the assignment itself and it is up to the student to develop the program based on the design. The designs laid out by school projects are obviously not ideal and not something you would usually expect to see in a sort of corporate environment. Many designs however are rather slim with only the basic functionality laid out leaving a lot of guess work on the developers side. Once you introduce any sort of indecision into a software project you have opened the door to inefficiency. A developer may try to fill in the holes in the design with what they think is right. Something completely simple could be over complicated in code because someone did not write out in any for of design how two components were expected to communicate and relate with one another. Even if the developer has good communication skills and does come to ask for clarification often the document designer writes so many documents that the ideas they had during the design phase may be gone or fuzzy.
Some of this could be done better by simply having a more dynamic software design phase. Rather than having a single person responsible for designing how it is that a program should function it should be a community effort with input. This approach really helps in two major ways. First it puts more eyes and opinions on a project. Every developer has their own level of expertise and may catch some silly design or logic mistake right up front that someone else may not have caught. Second, this allows a wide range of developers to be aware of the thought process in developing the software. When a single person creates a design and put off on a single developer it often narrows the doorway of information flow. Only one guy knows what he was thinking and how it was originally planned to work while the rest of a development team is required to sort of guess and try to interpret the desired outcome and design.
One practice that has seemed to go the way of the dinosaurs is writing pseudo code before beginning a project. Some people write out a basic sort of pseudo code before starting a project but it never seems to be something that is quite in depth enough to really catch any sort of logic errors that a developer may run into. Back when fixing a programming mistake took more than simply hitting the backspace key a few time pseudo code was a much more integral part of the development process. A developer couldn’t easily just throw out some code, see if it would work, make a few changes, and try again. The idea that you can even try to fly by the seat of your pants when developing is completely absurd. It is a terrible method to follow when developing any major software and creates perhaps one of the largest openings for inefficiency.
Most developers have had those moments in school when they start to develop a program, get most of the way though, then realize that they misunderstood the assignment and need to start over almost entirely from scratch. The best method to fix this sort of problem would be to truly scratch the whole project and start design again from the ground up. Instead most people will take what they have already written, try to salvage what they can, and in the process create a horrible inefficient beast. This beast may function and possibly work as desired but is no where near as good as it could be because the time was not taken to truly create any sort of design. This happens in large scale projects all the time. People don’t really take time to hammer out some in depth pseudo code and truly look at their program before they even start writing it. Instead people just start programming with only a bare bones idea of what they outcome should be trimming and rewriting where necessary. Many projects have portions of code in them that do absolutely nothing at all because they were written in there in a previous state of the program and no one ever bothered to take it out.
Lets put together an idea situation of how developing software should go. A group of developers should get together with their ideas of what a program should do, how it should operate and how it should look. Everyone puts in their input and does their best to mold it into the best possible design. Once the design is completed the individual responsible for a portion of the code should take time to write really in depth pseudo code. Really focus on how the flow of the program should go, how loops should be formed, what basic calculations are going to be needed, how this code with interact with another part of the project. Once completed they should have another developer take a look at it to double check that the logic is sound and that there aren’t any outstanding problems. Once it has gone through some discussion and redone it should finally be coded in an efficient, well planned out, manner.
While this may not entirely fix the problem of programming efficiency it is definitely a good start. Rather than relying on a developers over bloated self confidence to create something it truly puts a level of responsibility on them and the their peers. With this sort of approach the “fly by night” style of programming should be less prevalent and truly well thought out programming standard and design should be applied.