Dealing with Unexpected Outcomes As a Programmer

When it comes to plans to write software, there are two methods of design. There is the “90% design, 10% coding (90/10)” methodology, and the “Go with the flow” (gwtf) method of creating software. While the 90/10 looks appealing, the latter is actually done more. Some might say it is because programmers are just lazy, and want to start coding right out of the gate, but lets put that absolutely wrong assumption on the backburner. The reason most programmers like to use the “Go with the flow” method (even if they don’t like to admit it) is because they are scared of unexpected outcomes.

The 90/10 rule is gleaned from one of my computer science teachers. He suggested that you spend 90 percent of your time working on the design and working out as many possible threats or weaknesses your program might have before you start coding. He believed that when this is done, it can alleviate stress from an otherwise very high stress job. However, lets be honest, that only works when you are a teacher writing a syllabus for the semester. In the real world, you can not account for everything. There are so many external factors that go into your design and development. It does not make sense to try and account for every single little problem. This is why so many developers have floated towards to “Go with the flow” method.

The problem is that the go with the flow method in the long run is more expensive, and usually creates code that does not scale well when dealing with larger number of users. Go with the flow design plans are usually very narrow when it comes to depth, and create code that is not resusable. Typically, programmers will make code that they call “concept” code, but then use the ol’ copy and paste in the final version. Not good.

So how does one go about dealing with outcomes which design can not predict? By following a couple of these rules.

This gives you a strong guideline to use when these problems arise. Mission statements should not be more than one sentence, and they should be very vauge. To give you an example, Chick-Fil-A’s mission statement is “To Be America’s Best Quick-Service Restaurant”. There is no mention of chicken or any type of food. When they make management decisions, they always first make sure the decision fits inside the mission statement.

For my last iPhone development project, my mission statement was “To help users use the power of their own data”. It is very brief, and keeps my intentions in line with the project. A good mission statement can help make hard decisions very easy. When designing a project, the first thing that should be done is write a mission statement. When developers have problems, always consult the mission statement first.

When writing the software plan, keep a little message in the back of your mind that you will have problems that you can not account for. Do not get stressed when a little “oops” happens. Take a swig of rum milk and continue with your coding.

Unit tests can not only help figure out problems that might occur before even starting to code, but also give a clear pathway that some users of software might take. Unit tests are usually done when creating a software library, but can be used in an extended way when dealing with applications. Write down a couple of “processes” that a user might take when running the program, or calling a library function. Most programming languages have a standard way of writing unit test cases, so look into it with your language of choice.

This is a hard thing to grasp, especially if you think other developers aren’t as good as you because they think differently. The best example I can think of was when I was just starting out as a programmer. I was told to look at a file and figure out what was wrong. I looked through the code and had no idea why it was written like this. There were no comments and they did not do some things efficiently.  I decided to just rewrite the program. I spent a whole day rewriting it, and after I finally finished, I looked at how I did things, and was dumbfounded to realize that my code was almost no better than his. I had not accounted for a lot of problems, and when I was done, I realized why he did what he did and why it looked crappy.

Hopefully, this provides some stress reduction for someone.