This website uses cookies to ensure you get the best possible experience. See our Cookies Policy.

PMG Digital Made for Humans

Dealing with Unexpected Outcomes As a Programmer

4 MINUTE READ | August 9, 2011

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.

Insights meet inbox

Sign up for weekly articles & resources.

Hopefully, this provides some stress reduction for someone.


Posted by Chris Alvares

Related Content

thumbnail image

Get Informed

PMG Innovation Challenge Inspires New Alli Technology Solutions

4 MINUTES READ | November 2, 2021

Get Informed

Applying Function Options to Domain Entities in Go

11 MINUTES READ | October 21, 2019

thumbnail image

Get Informed

My Experience Teaching Through Jupyter Notebooks

4 MINUTES READ | September 21, 2019

Get Informed

Trading Symfony’s Form Component for Data Transfer Objects

8 MINUTES READ | September 3, 2019

Get Inspired

Working with an Automation Mindset

5 MINUTES READ | August 22, 2019

Get Informed

Parsing Redshift Logs to Understand Data Usage

7 MINUTES READ | May 6, 2019

Get Inspired

3 Tips for Showing Value in the Tech You Build

5 MINUTES READ | April 24, 2019

thumbnail image

Get Informed

Testing React

13 MINUTES READ | March 12, 2019

Get Inspired

Tips for Designing & Testing Software Without a UX Specialist

4 MINUTES READ | March 6, 2019

Get Informed

A Beginner’s Experience with Terraform

4 MINUTES READ | December 20, 2018

All POST