The Engineering Cycle
I guess I have been fortunate enough to been raised among brilliant minds and out of the box thinkers. My father was a researcher for a governmental facility in Brazil which performed experiments in corn and sorghum with the goal to maximize growth rate and survivability in different regions such as the Brazilian northeast that is the driest region of Brazil.
These people that my father hanged around were Engineers and Researchers from all different aspects and Engineering backgrounds. Being a researcher and an engineer does not take away the need of having a concrete solution for a problem and it is from this knowledge, that I have acquired from following my dad and his co-workers around, that the concept of the Engineering Cycle came from.
The concept is pretty simple but it is extremely robust. Robust enough to actually provide a guideline on solving the most complex of the issues and it is something that I truly believe in.
Every single solution starts at the same place, it comes from an issue, a challenge, a quest, or something that motivated its creation.
Even at its simpler form, you can always say that every solution came from an issue/challenge. We can affirm that the issue/challenge is, in fact, a seed, a source, for the solution created but it is getting to the solution that becomes a real challenge. How can you go from an issue to a solution?
Researchers use a very standard and simple way to approach any issue and scientifically generate a hypothesis, thesis, solution: You must start with research, develop your ideas and then adjust when necessary.
My dad used to do that constantly to better identify which type of herbicide would better work on a given crop for a given result.
As a computer scientist/software engineer/programmer/developer (labels) I have always done that in a way or another. I needed to develop a new feature, scribbled something on a piece of paper or the whiteboard, started the development and fixed bugs or created improvements based on feedback. By all means that is wasn’t so different from what my dad and his co-workers used to do.
For any given issue I was researching, developing and adjusting. I was performing the Engineering Cycle.
I’m presenting it as a pyramid because that is one of the strongest shapes that we have and it allows good visualization of the process. From the issue you research and then you develop and finally you adjust.
Research is the time spent to properly gather information about the issue/challenge at hands in order to generate a solution. It is important to remember that for any given issue/challenge you can have multiple solutions but your research should be focused on the preferred path even if, after research, a new path is taken. Research doesn’t need to take a great amount of time to be performed, just enough to determine a path of development.
Development is all the work that will be performed to generate the solution. This can be the longest portion of the engineering cycle. The time taken during development is directly impacted by the quality of the research, in other words, the better the understanding of the issue/challenge, the better will be the development of the solution.
Adjustments are either fixes, re-runs, improvements or anything necessary to ensure that the desired solution matches what is expected from it. Similar to the development phase, the adjustment phase time will be directly impacted by the quality of the research but unlike the development phase, the adjustment phase will incur more time if the research quality is bad.
Note: During the adjustment phase, a new cycle starts because now new challenges/issues have appeared.
It is the balance between these 3 phases that allow the generation of a good solution. This means that from research, development, and adjustments you can get into a solution which means that now we have a new pyramid but in the opposite direction.
If an issue/challenge requires a balance between research, development, and adjustment to get into a solution, a full engineering cycle will be represented by a combination of both pyramids.
Update: After some readers feedback I have changed the main image to this new one, where the arrows demonstrate the flow of the process. Although the graphic is mainly demonstrative the process is as it was described before.
Put this to a test and you will see that, doesn’t matter the issue, a solution can be found and sometimes, both the issue and solution will be broken apart.
I’m thankful to have been a part of this crazy scientist culture that my father was a part of, and even more thankful to have been a part on teams that carried a similar culture through my career. This culture created the concept of the Engineering Cycle and it is to proliferate this concept (and help) that I wrote this article.
Good luck on your next challenge and hope this cycle helps you as much it helped me.
