Over the course of the past few classes, we have been examining common Software Design flaws. We have paid extra attention to the “architecture” of code and the various designs that code can undertake, and how each design can be a fit/ not a fit for a specific application.

Writing Code That Isn’t Needed

Writing extra code was a common problem for me when I was first learning to code. Sometimes, I still find myself designing an algorithm that gets much more complicated than it has to be. In the video, adding unnecessary features was mentioned. For example, if you are coding an algorithm that reverses strings, and then you add a feature that allows you to add numbers thinking that you might possibly use it in the future. The problem with this is that you might not use it, and even if you need a feature  like this, certain requirements might be different.

Another thing that was mentioned was assuming extra requirements. When designing software, you should never assume more requirements than were specified. The thing that most surprised me was that they found the comments unnecessary. Being an undergrad in various computing classes, we are required to comment our code, but the first thing that the developers in the video did was delete all of the comments. They looked at them as unnecessary and even condescending saying that coders should assume that people know how to read code and follow what is going on.

Not Making the Code Easy to Change

I found this video helpful in the fact that it pointed out that you need to think about the future without implementing the future. When you are using a number or value repeatedly, you should turn it into a constant in order for easy access later in case that value does need to change. This video again brought up that assumptions are bad, and should be avoided. The developers mainly encouraged considering anything in your code that could be changed in the future and doing all that you can to make this hypothetical transition easier (without implementing the change) because you never know the route that your software is going to wind up on.

Being Too Generic 


This section was described as the thinking of “I may need to do foo in the future, so I should do foo now”. This was kind of a play on the writing unnecessary code video, however a specific situation. The main issue with making your code too generic is that it consumes a lot of your time without much to show for your effort. The work that you do should actually deliver value to the user rather than trying to code for handling every possible input that you could possibly get. You should only be generic to not duplicate code, and that your design is simple and stable. Beyond these general requirements, you should step back and consider what you are doing.

Some tips for avoiding these common coding errors are:

  • Think through your design
  • Each time you add something new, it should look like it was a plan from the beginning
  • Build from the inside out (the useful core of the application to the extras that build on the core)
  • Think about possible future implementations without actually implementing them