A different perspective
As you know1, I am a mechanical engineer, with the passion for personal computers and informatics. I started in 2014 a self-learning and experimenting experience with no prior background in informatics but with a strong background in mechanical engineering. I filtered everything that I did and learned thru the lens of mechanical engineering. There is nothing that I could do about it because this is the way the human brain learns new things: we humans learn by continuously making comparisons and finding differences, similarities and parallelism between the things that we know already and the new thing that we are currently learning. In this post, I would like to share with you my thoughts, as a mechanical engineer, about the field of software engineering. I hope that you would share your thoughts back with me and leave a comment in the post.
|
| Fig. A - Design, Production and Product |
When I consider any activity from the birth of the idea to the realization of the same, I think of three distinctive steps: design, production and product (Fig. A). The design phase ends with a draw. The draw is a symbolic language, full of conventions, which describes, to the people that can read it, everything about the thing to be manufactured. In the mechanical engineering degree, I had to pass two exams to learn how to read, interpret and write such technical drawing. The technical draw is the start point for the manufacturing process. Based on what is written in the technical draw about dimensioning tolerances, surface roughness and other things of the kind, the production people select the best suitable tools, they set the cutting speed, decide the right grinding and so on. Once the production is done, you have the product. The very first ones are prototypes used for internal testing which are useful for fine-tuning of details on the draw and on the production process, but, in the end, the production outputs a series of products for the sale to the customers.
Having said that, I think that the same scheme applies to software engineering as well but I also saw a lot of software-people making a lot of confusion. For this reason, I felt like writing this post and try to take the confusion away.
|
| Fig. B - Mechanical and Software engineering in parallel |
In Fig. B I show the parallelism that, in my opinion, exists between mechanical and software engineering. The first step is always the design phase which, in case of software engineering, ends with a flowchart. The flowchart is the equivalent for software engineers of what a technical draw is for mechanical engineers. The second step is the production: the realization of the idea. This realization of the idea, in the case of software engineering, is done with the action of writing the program. Unfortunately, I have to say that many software people don't realize it and they jump immediately ahead in writing code. In this way, those people confuse the production phase with the design phase. They think that the actual act of writing code corresponds to the design. This is the source of the confusion and the source of many problems or bugs related to the creation of software. In the field of mechanical engineering, nobody would even think about going close to a milling machine (or any other production machine) without having read and studied the draw of the piece to manufacture. So, how could some software people even jump and start writing lines of code without having seen any flowchart?
In the field of mechanical engineering, the people doing the draw are other than the people setting the production line and running the manufacturing. This clear distinction between the two groups of people, makes also clear the separation between the two conceptual phases: drawing and manufacturing. In the field of software engineering, the same person is in charge of the two roles: design and production. The same person that should do the flowchart (drawing), writes the program (manufacturing). This fact has fused the two phases (realization of the flowchart and writing of the program) in one and by the melting of the two, the realization of the flowchart has almost disappeared in the common awareness of software people. During my hobby hours, I find a lot of programs but few (almost any) flow charts on the internet. In this sense, I also contribute to this perception from the internet since I publish programs in my DOWNLOAD AREA but no corresponding flowchart for them. I do the flow chart every time. Sometimes just with a pencil on a piece of paper and sometimes I have even published the flowchart as in the post "Design and build the space shuttle". Maybe I have to publish more flowcharts in the future (if the audience likes to have them too), but I think that everyone has to make the flowchart before start writing the program. Drawing the flowchart is the key to see if the logic of the program works and if not to fix it in the flowchart before writing any line of code. This is better than spending hours writing code and debugging on the Integrated Development Environment just to realize that what needs a fix is the logic behind the program itself.
Comments
Post a Comment