Deconstruct to Construct
Reverse-engineering something may be used mostly to copy someone else’s work, but it can also be used as a thought exercise to aid original design. The exercise of taking a system apart to see how it works also applies to the creative process to better serve application areas, improve subsystem design, and create new processes.
Let’s take a very mature system, the fossil-fuel car. As Arthur Clarke once said, “any sufficiently advanced technology is indistinguishable from magic”. The personal motor vehicle can certainly claim that title, as one not only rarely (often never, especially if the vehicle is taken in for routine maintenance) needs to look under the hood, they don’t even need to understand how it moves or how any of the subsystems work. Unless you push the envelope of performance, the average vehicle is simply a box with chairs in it that can take you anywhere as long as you keep feeding it.
In every fueled vehicle there are several (extremely complex in themselves) major subsystems involved: chemical-based internal-combustion mechanical energy to move the wheels, current-driven motorized systems, voltage-dependent electronic systems (and the related communication bus(es)), hydraulic braking, water-based engine cooling, oil-based lubrication , and interior design and upholstery. When one creates a car, one must address each and every one of those systems, not only in their internal functionality, but also how that functionality serves the system and can be managed by the user.
This applies to any device or tool. The time when you first start to flesh out your idea to create something is also the time to first deconstruct it to better understand it and how it fits in with the overall application goal. By considering how the design fits into the application at all levels, in every facet, and addressing the underlying infrastructures and components and how they serve that goal will pay off big dividends when you create your first prototype. Many designers discover what was originally a small oversight has ballooned into a big problem as it becomes hardware (although this also applies to software products) and gets tested in the real world.