Opinion: Making Things Better

Tools and technology have put the act of making within easy reach of everyone. High level languages, cheap microprocessor boards, and mechanical interface boards have given everyone a chance to take a complex idea and turn it into reality.

And, once that idea becomes reality, human nature kicks in. We can not resist the opportunity to tweak, modify, update, and refactor our designs over and over again – usually until we break something or lose sight of what we were trying to achieve.

A traditional artist once told me that they spent about 5 years learning how to paint, and the next twenty learning when to stop. Where then, as coders and makers, do we draw the line? Here are my guidelines for optimizing your designs:

1. Profile Your Design

You cannot fight a hidden enemy, you need to identify problem areas in your designs before you can fix them. Use profiling tools to find out where you need to concentrate your efforts in code, and in the real world. Most importantly, ask the users of your design what they think of it. Check with them often, and use their feedback to optimize your design.

2. Excessive Optimization is the Root of All Evil

You only need to optimize something to a point where further optimization will achieve no further useful increase in performance. If the benefit of the optimization is negligible, then the process of optimization is probably redundant.

3. You Can Not Optimize for Everything

Striking the right balance is important. Some cars need to go very fast, while others need to use the minimum amount of fuel. You cannot design something that is high-performance in every possible way. There will always be a trade-off between resources, speed, or accuracy.

4. Be Firm of Purpose

You have to choose optimization goals for your design before you can start improving it. The goals must be realistic, and should not be longer than a single sentence when written down. Once an optimization goal has been decided, you should stick to it and not get sidetracked by other, less important considerations. You can not build a castle if you spend ten years designing the door handle.

5. The Algorithm is More Important than The Syntax

Algorithms are based in mathematics, and will remain constant regardless of the language that they are implemented in. Understanding an algorithm gives you a chance to improve a system before it exists in the real world. Examine your algorithms in detail before you build anything, and you will usually avoid the code/engineering equivalent of painting yourself into a corner.

6. Sometimes Optimization is Not Enough

There are cases when the route to a working product involves more than just optimization. You will either have to wait for the state of technology to advance, or start getting creative with what you already have.

Multiprocessing techniques, resource clustering, and GPU manipulation are brute-force solutions to computational problems, while high performance chemicals, specialist materials, and high power engines are there if you need them in the real world. Optimization is not magic. Sometimes the only solution is to go and get a bigger hammer.

7. Trust in Grok, not Zen

The word grok has its origins in the novel “Stranger in a Strange Land”, by Robert A. Heinlein. Roughly translated, grok is a complete and exhaustive knowledge of a particular subject.

Zen, on the other hand, refers to a blinding flash of inspiration or sudden understanding of a situation. Zen can sometimes occur as the result of deep grok, but is often just the result of a hunch that happens to pay off at the right time.

There is a temptation with armchair mechanics and programmers to work through a broken device or piece of code and start changing things at random. Blindly hoping that one of the things you change will fix the problem is not a solution. Hoping for a Zen moment is no substitute for actually understanding what is happening, and the only way to completely understand is through learning the theory behind what you are doing.

8. Implicit Functionality is Better than Explicit

In the real world, if a suitable component is readily available and well within your resources to acquire, it is not wise to design your own version from scratch. Common components (motors, gears, resistors, transistors, etc…) can be swapped out quickly in the event of failure, but a custom made part will take much longer to replace.

When programming, an implied loop written in C or Assembly will be faster than an explicit loop written in an interpretative language like Python or PHP. Don’t create an explicit loop when an implied loop is available, you will just waste time and energy reinventing a much less efficient version of the wheel.

9. Do Not Let Your Loyalty to a Particular Tool Hold You Back

Many people are loyal to a particular tool, product, or programming language – even to the point where they will make extra work for themselves by using that tool in place of another. Tools and programming languages don’t get lonely, and an Arduino will only cry into it’s beer if you program it to do so. There is no need to feel guilty about abandoning a favorite tool if there is another that will do the job better, because electro-mechanical love is unconditional.

10. You Are Not Alone

The online community is large, and there are always people that are ready to help a fellow maker. If you can’t figure out a particular problem for yourself, and the books don’t help, then you can always find someone that you can ask within the community.

Just make sure that you remember to give back to the community. If you have solved a problem, document it for other people to see. If you found some documentation confusing, consider rewriting so that other people can understand it more easily.

The more that you can give to the community, the more the community will be able to give back.


Be the first to comment

Leave a Reply

Your email address will not be published.


This site uses Akismet to reduce spam. Learn how your comment data is processed.