Why is it called building the code?
Sometimes I wonder why we call the process of compiling and linking the code a build process. The final output is usually either running executable or library. We don't even call the output a building or a structure, in fact structures are found inside the source code itself. So, if we call it a build process, this will arouse many questions, we can list of them here:
1- If this is a build process of a product, where is the blueprints for that building?
2- Who is the actual builder, the human or the computer?
3- How to detect the build errors on level of blueprints to avoid wasting time?
These are philosophic questions and I don't know really an origin for who called it a build process, if anyone knows well the origin it will be worthy to share it among the WWW. However I am going to try to put answers to these questions, which could be useful for our day to day activities.
Where are the blueprints for the building?
If the process of building the source code results into a built product which the executable, then there should be blueprints for this process. This is the flesh of the discussion, the blueprints are usually the input to the builder to start doing their job. In this is case, is it the source code? the source code and other artifacts? In my point of view, it is the source code only. After all the builder of the source code has no idea about any other artifacts, and will never require them.
This make us have to pay more attention on source code, and ask, if we are working in a company, an earthquake has occurred, the building starts to fall down and you will be able to escape with one thing only in hand from the company building, which artifact you would keep with you? Is it the design document? specifications? architecture? or source code? In my point of view, it will be the source code, not because this is the deliverable to the customer, but because the source code contains the consolidation of all information and analysis of the system, it is an actual full design of the product which is ready to be baked and built to get our product ready.
Understanding that source code is the blueprint for the product will help us understand why successful companies will always try to devote much investments to optimize, standardize, and maintain source code. In the world of embedded systems, where the executable is part of the product, it will be efficient to have the source ready as soon as possible with minimum cost and maximum quality. The executable in its own cost nothing to be downloaded to the PCB, however the actual cost is in the effort of creating the executable itself. Having standard software components, standard libraries, and high quality software building bricks, is the factor which makes difference in the world of the embedded software development, and I think it is the same with other areas.
Who is the actual builder?
Is the actual builder the man who has written the source code, or the build system which will create the executable? In my point of view, it is the build system, and accepting it like that will make sense why people will need to have very efficient and high quality compiler tool chain, and build systems. A high quality make files system, and compiler tool chain can lead to better optimized software, more RAM and ROM efficient and even a faster more secure executable.
Compiler options play significant role in RAM, ROM, and Execution speed optimization, as well as security in modern CPU architectures. For example, a high end compiler could have compiler options to check array boundaries, uninitialized pointers, and may be even dangling pointers. These options could be affecting the executable ROM size, but will protect the software against malicious behaviors of other applications on the system.
In addition, nowadays compilers can also enforce some standards on the source code like ANSI C compliance, MISRA compliance, and many other standards. It can also go the extra mile to provide code quality checks like functions cyclometric complexity, line count, critical resources consumption like RAM and ROM. All of these activities will mean that the actual builder here is the build system, and designer of the product is the code writer, selection of a good builder will help you to get high quality product for sure.
How to detect the build errors on level of blueprints?
This is a strange question may be, why would I need to detect build errors on level of blueprints? In other words why I would need to detect compilation errors and linking errors on the level of software coding? A more elaboration for the meaning of errors will make the question logical.
Software development will involve one ore more software engineers writing code, and using other libraries most of time. With huge software design, incorrect casting error, misspelling a variable with other variable name, even incorrect parentheses is very common human mistake and sometimes it is normal, at the same time it could be one source of very stinky bugs. On the other hand, some bugs like referencing null pointers, dangling pointers, out of allocated memory access is very normal in a huge software dealing with many chunks of dynamic memory, files, shared memory, etc...
Using suitable code checking tools could save much precious time, and effort for the developers and the project manager who will pay for bug analysis and fixing activity. Sometimes it is a compromise between using or not using code checking tools, using free tools or commercial tools. As I know there are many tools free and could be used without any restrictions to do necessary code checking. The cost here is how to utilize the tool with the necessary automation scripts to get it working and maintain it with code versions. If somebody makes the math and find it is more cost effective to use these tools, then it will be better to use, otherwise if it is waste of time and effort never use it, as it will burden on the developers themselves to use tools they don't even understand why they have to use them. In my opinion, sometimes customers would ask about code checking tools and whether they are used or not, it will better to justify why you don't need to use them and keep your developers motivated rather forcing the developer to use them with no added value and getting them bored and demotivated.Using these tools or not is subject to the math and need as well.
Writing and maintaining optimized standardized code is what makes systems like Linux survive now, high quality easy-to-use build tool chain like GNU is now is leading the market with many ideas and de-facto concepts. And the last, code checkers could be peace makers and could be neighbors from hell, it all depends on which kind of tools you are going to use, and whether your software scale need them really.
I hope you may find my article to be useful to you, and I am opened to any comments, discussions, feedback, questions, and even ideas to discuss together about computer science and engineering.
Thanks for reading ;)
1- If this is a build process of a product, where is the blueprints for that building?
2- Who is the actual builder, the human or the computer?
3- How to detect the build errors on level of blueprints to avoid wasting time?
These are philosophic questions and I don't know really an origin for who called it a build process, if anyone knows well the origin it will be worthy to share it among the WWW. However I am going to try to put answers to these questions, which could be useful for our day to day activities.
Where are the blueprints for the building?
If the process of building the source code results into a built product which the executable, then there should be blueprints for this process. This is the flesh of the discussion, the blueprints are usually the input to the builder to start doing their job. In this is case, is it the source code? the source code and other artifacts? In my point of view, it is the source code only. After all the builder of the source code has no idea about any other artifacts, and will never require them.
This make us have to pay more attention on source code, and ask, if we are working in a company, an earthquake has occurred, the building starts to fall down and you will be able to escape with one thing only in hand from the company building, which artifact you would keep with you? Is it the design document? specifications? architecture? or source code? In my point of view, it will be the source code, not because this is the deliverable to the customer, but because the source code contains the consolidation of all information and analysis of the system, it is an actual full design of the product which is ready to be baked and built to get our product ready.
Understanding that source code is the blueprint for the product will help us understand why successful companies will always try to devote much investments to optimize, standardize, and maintain source code. In the world of embedded systems, where the executable is part of the product, it will be efficient to have the source ready as soon as possible with minimum cost and maximum quality. The executable in its own cost nothing to be downloaded to the PCB, however the actual cost is in the effort of creating the executable itself. Having standard software components, standard libraries, and high quality software building bricks, is the factor which makes difference in the world of the embedded software development, and I think it is the same with other areas.
Who is the actual builder?
Is the actual builder the man who has written the source code, or the build system which will create the executable? In my point of view, it is the build system, and accepting it like that will make sense why people will need to have very efficient and high quality compiler tool chain, and build systems. A high quality make files system, and compiler tool chain can lead to better optimized software, more RAM and ROM efficient and even a faster more secure executable.
Compiler options play significant role in RAM, ROM, and Execution speed optimization, as well as security in modern CPU architectures. For example, a high end compiler could have compiler options to check array boundaries, uninitialized pointers, and may be even dangling pointers. These options could be affecting the executable ROM size, but will protect the software against malicious behaviors of other applications on the system.
In addition, nowadays compilers can also enforce some standards on the source code like ANSI C compliance, MISRA compliance, and many other standards. It can also go the extra mile to provide code quality checks like functions cyclometric complexity, line count, critical resources consumption like RAM and ROM. All of these activities will mean that the actual builder here is the build system, and designer of the product is the code writer, selection of a good builder will help you to get high quality product for sure.
How to detect the build errors on level of blueprints?
This is a strange question may be, why would I need to detect build errors on level of blueprints? In other words why I would need to detect compilation errors and linking errors on the level of software coding? A more elaboration for the meaning of errors will make the question logical.
Software development will involve one ore more software engineers writing code, and using other libraries most of time. With huge software design, incorrect casting error, misspelling a variable with other variable name, even incorrect parentheses is very common human mistake and sometimes it is normal, at the same time it could be one source of very stinky bugs. On the other hand, some bugs like referencing null pointers, dangling pointers, out of allocated memory access is very normal in a huge software dealing with many chunks of dynamic memory, files, shared memory, etc...
Using suitable code checking tools could save much precious time, and effort for the developers and the project manager who will pay for bug analysis and fixing activity. Sometimes it is a compromise between using or not using code checking tools, using free tools or commercial tools. As I know there are many tools free and could be used without any restrictions to do necessary code checking. The cost here is how to utilize the tool with the necessary automation scripts to get it working and maintain it with code versions. If somebody makes the math and find it is more cost effective to use these tools, then it will be better to use, otherwise if it is waste of time and effort never use it, as it will burden on the developers themselves to use tools they don't even understand why they have to use them. In my opinion, sometimes customers would ask about code checking tools and whether they are used or not, it will better to justify why you don't need to use them and keep your developers motivated rather forcing the developer to use them with no added value and getting them bored and demotivated.Using these tools or not is subject to the math and need as well.
Writing and maintaining optimized standardized code is what makes systems like Linux survive now, high quality easy-to-use build tool chain like GNU is now is leading the market with many ideas and de-facto concepts. And the last, code checkers could be peace makers and could be neighbors from hell, it all depends on which kind of tools you are going to use, and whether your software scale need them really.
I hope you may find my article to be useful to you, and I am opened to any comments, discussions, feedback, questions, and even ideas to discuss together about computer science and engineering.
Thanks for reading ;)
Comments
Post a Comment