Program Efficiency: A Preemptive Strike
- April 11th, 2010
- Posted in Programming
- By netadptr0719
- Write comment
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.
That’s actually a sentiment I’ve been feeling for a while, after having had a few 300′s level classes under my belt. And that scale is still far inferior to the “real world” project level.
I’ve been trying to force myself into writing pseudocode in advance, but with a bit of a twist. Pull open your IDE, create the file you’re going to write, and start writing. Not code, but “pseudocode” in plain English. Then, once I’m satisfied with the completeness of it, I go back and fill in the gaps with real, compilable code. The end result is two birds killed with one stone: a well thought out project and very thoroughly documented code – when I do it. =)
I feel the downfall of this solution is twofold. First, I feel that you are equally likely to under-define the pseudo code as you are to under-define the original implementation document. Second, if people are doing complete pseudo code, they are effectively writing every program twice. What you propose would effectively double time of development. Now I know that measure twice cut once holds in computing, but I feel that everyone from programmers to high level managers would think it a waste of time.
I’ve always found that if you can reduce the size of a functional block in your design, you can avoid a lot of the problems you listed. If I effectively split the original problem into very small, easy to understand chunks, I can produce efficient code.
I also think a more direct approach may be to attack peoples unwillingness to scrap sections of code that was designed incorrectly. If you can convince people to go back and do it right instead of hack it till it works I think you can greatly improve code quality.
The thing is that it wouldn’t really double the time in which it took to develop. Once you have written everything out and discussed it most of the legwork is done. It isn’t like someone would work really hard to develop the pseudo codes logic, throw it away, and do it again for the code. A big portion of this argument too is the “more eyes on it idea”. I have seen quite often people will write an entire program without going to others just to go into an end product code review, have everyone hate it, and start back from square one. THAT doubles development time way more than writing out pseudo code first. This is really the meat of the argument I think. In most cases documents are seen as the “Doc Developers job” and not a team effort. Some Doc Developers have code experience, those dev teams are lucky, and some don’t. My method at least somewhat forces a person of development knowledge, at least one, into the process.
Splitting into small chunks would work with what I have listed. As long as there is an upfront development cycle rather than jumping head first into code it will reduce the end work. The end work is what REALLY kills the software development model. Industry has this idea that even though the quarter is almost over that they have forever to work on it. They then realize 1 week before it is over that they DON’T have forever and soon start rushing stuff. Things get cut, things don’t get implemented right for the sake of getting it out the door, and all around the released product isn’t ever nearly as advertised.
If you moved more of this work to the front of the cycle you would be able to get a lot of this done way before it was even an issue. You’d be worked really hard at the beginning of a cycle and be able to coast to the end working mainly on enhancements and fine tuning of the product. This is completely opposite of industry where everyone has a lazy state of mind thinking “I will so it later”. As business logic dictates you would want to get as much of this out of the way up front as possible so that a larger chunk of the quarter is focused enhancing the software.
TLDR; Kinda but no.
Reducing functional block size is good programming practice anyway. In most cases, combined with good function naming, it can take the place of comments. That should definitely be a part of the design process.
I can’t figure out, however, how being willing to scrap blocks of bad code is conducive to solving the problem of not hacking together code. Writing/rewriting just seems to be another face on the same coin. If you really want to stop code hacking, I think that a more involved, lower leveled design phase is one of the best solutions – if not the best.
You don’t have to pseudocode everything down to a subatomic level, but at least break it down to something less than polymers. Just think how easy it could be if a design was agreed on before a single line of code was written. If you knew each function that needed to be written and already had pre/post conditions for each one.
That, to me, is where you separate the hackers from the computer scientists and the code poets from the code monkeys. Or, as Sun Tsu put it, “Victorious warriors win first, then go to war, while defeated warriors go to war first, then seek to win.”
@netadptr0719
It isn’t that I feel people would write the pseudo code, then start over, or that the pseudo code itself wouldn’t reduce the time to actually code the program. My point is that if you tell developers that they need to create pseudo code that is expressive enough prevent any misconceptions, then ask them to re-implement it in a high level programming language, they will feel it a waste of time. The doubling I mentioned was poorly placed, as I meant that your idea has a lot of points where many people would be performing a job that is currently done by one person. I agree this will likely reduce later problems, I just don’t see people liking the overhead.
@Azurite_Dragon
To clarify, what I mean by scrapping code is that I feel a lot of shit code originates when someone is would rather be lazy than do it right. If you wrote a section of code that almost works the way you want and you can either delete half of it and make it perfect or slap a twenty line workaround on it, most people pick the latter.
What I am saying is, yes you may get it wrong at first, but fix it the right way if you do. I just don’t if its possible to preplan and pseudo code your way to mistake free code without making the pseudo code exactly as complex as a high level programming language.
Could you clarify what you mean by “efficient”? The first time I read your article I thought you meant performance: how quickly the program executes or how little memory it consumes. Now that I’ve read it again, I think you’re talking about the code having a clear and understandable architecture.
I think performance concerns are usually red herrings. For the majority of software development, asymptotic times and clever algorithms don’t matter: everything’s fast for small values of n.
Architecture is a trickier problem, especially when working on a team. The root issue seems to be a lack of communication among developers. Like crooked politicians, ugly architectures can’t thrive in the open but will fester if kept behind closed doors.
At my workplace we practice pair programming, which means every decision has at least two pairs of eyes on it. If the pair feels like their design is likely to have repercussions outside of the section of code they’re currently working on, they bring in other team members to have a just-in-time discussion. For really big problems, developers from other teams might be invited to give their input.
This approach seems to be working fairly well, but I’m still new. Ask me again in five years and I’ll give you a more concrete opinion.
The original intent of this was to focus more on creating efficient programs by having a developer overlook his work first and have others see it before committing it. The line of what I meant is kind of blurred because I am proposing a more efficient architecture style to create a more efficient program.