Doing It Right – The Second Time Around
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 design:
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.
2. Excessive Optimization is the Root of All Evil
You only need to optimize your code 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 Everything
Optimization is all about striking the right balance. Some engines need to run very fast, while others need to use the minimum possible amount of resources. 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 an optimization goal for your design before you can start improving it. The goal should be realistic, and should not be longer than a single sentence. Once the optimization goal has been set, 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 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 prototype 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 octane fuels, composite materials, and high torque motors are there if you need them in the real world. 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 device 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. There is no need to feel guilty about abandoning a favorite tool if there is another that will do the job better, because electromechanical love is unconditional.
10. You Are Not Alone
The making 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.