Another developer paradigm shift.

Everyone has heard this quote

“Completeness isn’t achieved when nothing can be added, but when nothing can be removed.”

I may not be a master haxor but I do my best to apply this when I make software. I however believe I made a classical interpertation error I had only realized after listening to a podcast from an Apple developer.

“The way to succeeed is just uncompromising simplicity”

Let me back up here. My simple minded interpertation of the first quote was nearly 100% directly applied to the code itself. Simply put I would create an object that did what it was supposed to do and I would refactor it until it could not be any more efficient. A simple example would be if I had the need to create X out of Y I would first figure out how to do it and then refactor it down to it’s simplest form and even pull it from the whole program and create it as it’s own class or even just a function as to slim down all the other parts of the program so it can just call up that function and get the job done. Then, late down the road I will change the function so it becomes a little more flexible so more parts of the software can use the function effectively making the whole process more efficient. I’m sure you get the idea. You can apply that initial quote to STRICTLY coding software. How wrong could I be? Extremely wrong. With that said, here is another quote from Apple.

Any fool can make something complicated

I’m sure you know where I’m going with this now. From my perspective, if I needed a form to submit information to a database I would create the form to submit information to a database and work tirelessly on the code to make sure it will do what it is supposed to do efficiently every time it was called to duty. I have never, and I hang my head saying this, created software with end user simplicity in mind. It was always “this has to be done, this is how it can be done, now let me work on the code so it works” It has always been black and white like that.

Here is a very good and extremely simple example of exactly what I mean. Let’s say you need to make phone book software. You will obviously need a phone number field. For me, phone number fields would have been one of two types of fields. Either three fields for area code, prefix, and number or one field for 10 digits of phone number. Black and white. I would then store that 10 digit number and have a function to make it pretty with brackets around the area code and a dash after the prefix for viewing. At this point, I would make the code work as best it could and call it a day. That is where I’m going totaly wrong. Why have those stringent phone number entry details? Why not let them put the phone number in any way they want and have higher quality error checking and parsing? Why not focus on end user simplicity? .. Becuase the end user is the person using the software! Many arguments can be made on this example but it is just a teeny example to show a big flaw.

Although efficient software was my goal, it wasn’t the end users goal. As a matter of fact I don’t think the end user could give a rats ass if one click of the mouse puts an 80% processor load or a 5% processor load on the server as long as that button does what it is supposed to do in a timely manner.

I will cut this windy post off there. Call me retarded but I have once again had a paradigm shift over the most obvious item I had previously overlooked.

End user simplicity is as important as code efficiency