Not your everyday blog

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.

I recently attended a class on the problems facing internationalization within software engineering. It brought up a lot of good points that I had never even considered as internationalization problems. Having two internships and having to deal with internationalization problems I had kind of thought that I already knew my way around it and how to effectively deal with the problems. Most of the things I didn’t consider were little logic errors, not larger scale problems. Most notable being that in other languages, what is considered alphabetical, changes. One cannot always assume that if one is looking at a list, that the A’s will necessarily be in a row since the normalization of Á would turn into A but may not be locally recognized as the same.

Many of the problems discussed in the class focused around things that I would consider ‘learnable behavior’. Things such as making sure you are using Unicode encoding, being aware that an icon that has obvious meaning in America may have no meaning at all in another country. GUI design was another hot topic in the class. You have to consider that some language will read right to left rather than left to right. Many languages have words much longer than their English counterpart and could either be cut off in a label or possibly cause a line wrap. All of these things are true and should be the focus of any software engineer that wants to do well with internationalization. However, I believe that this isn’t truly the root cause of the problem. An engineer should be able to pick up simple concepts such as externalizing strings, swapping out icons when necessary, and using a new style of GUI design. I believe that the true problem lies in the environment in which the engineer is developed and kept.

The first true stumbling block of internationalization is the educational system. While in school engineers are only really forced to create programs for themselves that have a very narrow scope of operation. They are never expected to create a program that is to be consumed by any other end user other than themselves, their instructor, and perhaps a grader. The educational system should really take on some responsibility in how they teach students to create deliverables. This wouldn’t necessarily require any sort of major overhaul in the systems. I know that many schools require a sort of capstone class that has a student create a product that, in theory, could be operated by an end user. Since we now live in a world market it would not be outside the scope of a class such as this to incorporate ideas involved in internationalizing software. Some of this burden would be taken off of the educational system though if perhaps development books were written in a new way.

Development books are a cornerstone for the growth and education of any software engineer. The problem in these books however is that more often than not they focus on almost entirely over simplified examples. In introductions to languages this is to be expected and I don’t think that “Hello World” needs to be internationalized in an effort to expose new engineers to internationalization. Exposure should, however, be given soon after the basic concepts of programming are taught. I can’t entirely blame the book manufactures for producing code in this manner though because most current languages are only written in an English readable format.

An English readable format is perhaps one of the largest stumbling blocks that an engineer has to face when creating software that is to be internationalized. If a native English speaker is creating a program, more often than not, that language will read almost like English and will have a sort of familiar flow to it. It really distracts the engineer from the fact that it needs to be internationalized because in the mind of the developer it seems to flow so well. Languages are written in stone and there isn’t really any logical way, or reason, to go back and write C++ and Java so that it is absolutely unreadable to anyone. This does though allow a good metric on which to judge a software engineer and his dedication towards internationalization. If an engineer is able to distance himself enough from his own native language then he is a software engineer who is not only able to create programs that will conform to internationalization but also an engineer that should be seen as willing to push himself and constantly grow. Not all of these problems lie on the educational system and the engineer themselves. A good majority of this responsibility falls on the industry as well.

While an engineer may be put on a one way track through his education, and perhaps books if they study on their own time, industry is often guilty of endorsing such behavior. Once an engineer has finished school and heads into industry, there is usually a short time dedicated to educating that engineer. Most of this education focuses on business-centric education. More and more businesses are moving towards including internationalization education in their training and that is a major first step. Sadly it is only a baby step because once the engineer is in his position, education ceases and practice begins. In many engineering environments, engineers are expected to produce, produce, produce. While I am sure many engineers expected this, and industry loves it, I am pretty confident that it is not what is best for industry. While the industry is expecting engineers to produce they are unintentionally culturally isolating the engineer and, despite what they may think, actually lessening the expectations on engineers. While the expectation of work may have increased, the expectation of continuing education decreases. Many businesses offer incentives to continue education which sounds very appealing. However, when your work expectations are so high, it leaves little time to dedicate to continuing one’s education. If a company wants to see their engineers succeed in an international environment they need to dedicate their time to putting engineers on the front line and truly showing them the problems that are faced on an international stage. Many examples given involve how a GUI interface may mess up, but this is only the beginning of the problems seen in the international space. If an engineer is able to see how his work affects another individual from poor internationalization, it would allow them to have a more real understanding of how what they do directly impacts the global stage.

While many of these problems seem large and insurmountable, they aren’t. All it takes is a shift in the way people think and develop software. Luckily this isn’t a large shift in thinking and only minimal effort on the side of input to see a large change in the output produced by engineers. Until these small problems are addressed though, I feel that the problems seen in internationalization will continue to be an ongoing uphill battle.

I have learned in the past couple weeks that I will become a Java developer. I have always had a disliking towards Java for various reasons. Since attempting to learn it though in a corporate environment I have found that it does have an awful lot to offer the business world. With that said there are a few features it lacks that I feel should really be a mainstay of any major programming language.

The biggest advantage I have found with Java is probably how easily it is ported across systems. In previous internships I worked with Visual C++ and the idea of it working on a possible Mac client were pretty much out of the question. Moving to Java though allows developers to focus less on cross compatibility and more on the true function and desired outcome of the program. While it is more flexible in cross compatibility it is also more flexible when looking at things such as internationalization. C/C++ were made ages ago and there wasn’t really much of a character encoding standard at the time. ASCII was really just about it and that really didn’t give companies any advantage when it came to foreign markets. Libraries and workarounds exist for this in C/C++ I know but since Java was made much more recently these standards are inbred into the language a little more making it a lot more accessible and easier to use. I also like the ease the transition from C/C++ to Java has been.

I have heard for some time now that people who have a background in C/C++ don’t have much of a problem transitioning to Java. I always though that this may have been people just trying to lure me over to the ‘dark side’. For the most part it has really been true, the syntax is almost identical, it is some of the logic that is throwing me off more than anything else. Even though it is causing me some trouble I must say that I am not coming at it from the other direction like a couple of my coworkers are. People who originally knew Java and are trying to move into the C++ realm are seeming to have a much harder time transitioning. A lot of it is stuff that I would consider trivial for the most part. When I stop and look at the differences in the two languages though it isn’t too shocking that someone who only knows Java is completely lost in a language like C++. The idea or using pointers or passing arguments as references is completely lost on some of these people. There have been several situations where someone has passed a class into a function, tries to change something, and it comes out completely untouched. I ask if they are passing by reference and they don’t even know what I am talking about. Something else surprising is some of the inheritance structures that these people are creating in C++. I guess I have taken for granted that C++ has multiple inheritance, something that Java ironically doesn’t have, I’ll get to that later. Some people have created classes that inherit through this giant tree of extends. This wouldn’t necessarily be bad but when you try to force something like this some of the relationships can become sketch at best.

Not having multiple inheritance may not seem like such a big deal but when you break down the foundations on which Java was built it truly seems to make pretty much no sense to me. It truly is ironic that a language built so heavily on the idea of OOP has no way to inherit multiple objects. While this may not be the death of the language it truly is something that I would expect from such a widely accepted and powerful language. Something else I find that Java is missing is a wide variety of primitive types. While Java has the basics: int, float, double, byte, char, boolean, and long, it doesn’t really have a way to expand on any of this. Java has eliminated SOME of this by creating the BigInteger() and BigDouble(). I don’t really find this to be a solution to my problem though because I am still awfully restricted. Initially looking at this list it may not seem too restricting, wait, there is more. Combining types or modifying types does not exist, that is to say I can’t made a long long, a long double, or anything of the sort. The one that really got me today was that there is no way to make a number unsigned inside of Java. This seems like a major oversight for any language that wants to gain any sort of major use and respectability. Sure I will probably not have a use for a number that goes all the way to 18,446,744,073,709,551,615 anytime soon but it still does take a huge chunk out of possible markets.

Despite the gripes about Java it truly is a pretty strong language. While its range of uses may not be as far reaching as some of the older lower level languages it really does pick up the slack in the ability to get something together and ship it out quickly among varying platforms. While efficiency may be lost there is a definite profit gain accomplished by using a language like Java over some of the other big names out there.

I feel like, after my little rant about the Bing commercials, I should weigh in quickly on Google’s first foray into TV advertising. Long story short, I liked it. Especially when I compare it against the original Bing commercials. It wasn’t obnoxious, too long, and borderline fear-mongering. It was clean and simple, exactly as we’d expect from the company with a compulsively simple home page. I liked how it focused on the features and capabilities of the search engine, something that Bing ads have more recently caught on to, and I liked that it managed to tell a short story which people can relate to without showing anything but the search pages, something that Bing ads have more recently failed at.

That said, I’m a little saddened that Google broke the tradition of no TV ads. I mean, I’m glad that it didn’t suck, and I do kind of like the one-upmanship of responding to Bing’s entire ad campaign with one Super Bowl ad. But it’s like that end of the era. Also, as was pointed out to me today, it’s a bit of an odd move to make France feature so prominently in a commercial aimed at the Super Bowl audience. Overall, though, I don’t think they’re hurting themselves with the move.

Through my entire schooling I always looked forward to the day that I would be done and be able to join the work force. Now that I am here it has led me to some conclusions about school and the life thereafter. Things I though were true have now been proven true and things I had always thought to be true are now false. Life has most definitely thrown me a curve ball and it is taking a lot of getting use to.

I always thought that school was expensive and stressful. I never was able to hold a steady job while in college and it seemed like I was in an eternal game of catch up that I would never win. Now that I am actually making money nothing has really changed. Now I just have more bills and more living costs. Expenditures have just seemed to grow in proportion to how much money I make not really allowing me any wiggle room or room to save. I know that as time goes on I will be able to bank more since a lot of my costs are in the up front costs of moving and not so much in the long term. It still is a lot of stress though and I think it may give me an Ulcer.

I figured once I got out of school I would be able to enjoy my free time a little more than while I was in school. This one has actually proven to be quite true. I will end up working into the day later than I anticipated but once I do come home that is entirely my time. Sure it is impossible to completely leave work at work in your thoughts but I am not forced to work on it in my free time like I was with home work in school. I have also come to appreciate weekends a lot more. When in school the weekends were a healthy mix between a time to relax and a time to catch up. It has now mostly just turned into a time to relax and I must say that I like it.

A lot of times when sitting in a class I found myself thinking, “how is this going to help me.” Well, unlike in high school what they have taught me has indeed turned out to be useful. Now that I am interfacing with students from other schools you can pretty easily tell which students focused just on theory, which focused only on application, and which had a healthy mix of the two. I have come to determine that Rolla has given me a good mix of the two and I must say that I am quite happy they did. I see many kids now who can give me the super details of why something is better or why it works the way it does. However, when these kids are asked to put it into an implementation they seem to freeze and have a hard time putting into words. On the other hand you have people who are able to churn out code faster than anyone I have ever seen. I can not help but think though that these kids really don’t have any understanding of what they are doing or if it is even best practice. It seems that they have basically just been sent to school to be code machines and to question absolutely nothing.

Whether I see life after school as better or worse is really irrelevant. I think for every problem I can find I am able to find a reason that makes seem so much better. It is definitely an entirely new experience that seems daunting and scary at first. You will find thought that in no time at all you find a certain pride in being on your own and truly making your own decisions. Whether they are good or bad decisions you can’t help but be happy that at least you made the decision and that you have truly made it to adulthood.