written by owen on 2015-Mar-07.

"Programming challenge; write the most verbose program/puesdo (in any language) to do this calculation; 1+9=10. "

This is a thought experiment on change vs complexity. It was inspired by Dale's fizzbuzz thing. You should look at my completed code on the project page then continue reading because the whole article is based on my progression through the six versions of the code in the project.

Understanding why you do what you do

You will notice that I start out by adding simple bits of new functionality and coding until I have a complete running version in each step.

Its one of the ways to avoid programmer burnout by not trying to over extend my effort on making increasingly "general" OOP constructs all in one go. Iteration is key to understanding what you are doing and blazing a path of positive progress. Because there is also such a thing as negative progress (long video, watch it later). You'll code yourself into a black hole or a rabbit hole or eat your own dog food.

Each version is essentially a "complete" program. I set a "nice to have" goal, complete it, ship, then repeat. It makes no sense in executing things "all the way" if you are gonna end up not shipping anything. You end up in a "progress trap".

A "progress trap" can be something as simple as creating the "calculator" class in the first version of your code. By creating the calculator class so early, you commit your self and your brain to writing an unknowable amount of lines of code before you can reach completion. This is a progress trap. A program is like a baby. You can't see any result until you implement all the interfaces you designed in your brain, fancy UML or whatever you use to plan out before you start coding. Every program is new and yet old at the same time.

Another reason why I did not create the calculator class in the first version is because I train myself to keep my eye on the goal of the original project specification and optimize my time. The original spec states that I should increase the "verbosity" of the program. So as a programmer the first thing that comes to mind is "how can I achieve the goal before I die or better yet before I have to get back to doing something more important", That is where version 2 comes into being. Version 2 achieves the primary goal and the secondary goal in as little as 15 minutes. Setting little goals keeps you on track. Keeps you focused.

Time and space is as important in everyday life as it is in programming software. You have to always be able to keep your goals in check and be able to complete a step and show progress. if you start out with a calculator class you may or may not reach version 6 in any reasonable amount of time, if at all. You might code yourself into infinity.

When to stop

Version 6 is where I stopped coding. I could go further but I ran out of ideas. Paul suggested I add interfaces but I started feeling like I was straying from the original specification. And whenever you stray from the original spec you end up wasting time. This is why I have a class called "one" and a class called "nine". These classes are the detailed in the original program 1+9=10. Sticking to specification allows you to save time and allows you to reach to a point of completion so that you can move on to other things and solve other problems. You do not want to spend six months writing interfaces that you will never use or the client does not want. Nice to have features are nice to have but you have to practice self discipline. You need to stay productive.

Conclusion

Sticking to specification requirements does not mean you are going to do the bare minimum. While sticking to spec you should always leave room for future enhancement without wasting time in the present. Present time is more important than tomorrow. The present goal is to complete the task as fast as possible. If you have time left over after you have met your initial goals THEN you can try to iterate. Keep yor intial goals small and you will finish more goals faster. If you work this way you reduce the risk of getting burnt out spending months writing interfaces and not giving you brain the positive reinforcement of reaching point(s) of completion (even if its just a simple thing).

permanent link. Find similar posts in Articles.