Any modern Linux distribution is made up of thousands of software packages usually maintained by incredibly large groups of people. How is this done without the entire process falling into chaos and disarray? The simple answer is a key concept called modularity. Modularity simply means building complex designs, such as a word processing program, in manageable modules. This technique is analogous to the “divide-and-conquer technique”. If a community of 10 people are working on a word processing program, they might divide the tasks needed to build the program into the skill sets in which each of the 10 members is the strongest. For example, 1 member might be an expert of building spell-checking functionality. This expert might build the spell-checking modules of the word processor. This modular design makes the software's code much easier to review and much easier to maintain. If the group wants to upgrade the spell-checking feature of the word processor, it is very likely that the code for the other parts of the word processor will not have to be changed very much, if at all. Most likely, only the code for the word processing module will have to be upgraded. This allows for a great deal of development independence. As long as the maintainer adheres to protocols that allow the different modules to communicate with each other, he or she can work on their individual module relatively autonomously. They can maintain a reasonable level of certainty that the overall program will continue to work. Periodic testing and communication between the module developers can verify this.

To delve into this topic in more detail, I will relate Linux software development to the development of programming code in C++. In C++, there are a set of standard functions that any C++ programmer can use. The functions have been built by other coders, freeing the programmer from having to build these functions from scratch. For example, one of the standard math functions in C++ is the fabs(x) function. The fabs(x) function returns the absolute value of whatever number is placed inside the parentheses in place of “x”. For example, fabs(-9.23) would return 9.23. The fabs(x) function is an example of a module. It is also known as a function, a method, or a procedure, depending on what programming language one is using. However, the concept remains the same. The programmer does not need to know the details of how fabs(x) does what it does. He or she only needs to know what the result of its calculation will be. Writing Linux software operates in a similar manner. The maintainer of the “export to alternate file format” module of our word processing example doesn't really care how the spell-checking module works, only THAT it works. The only people that really need to know the precise details of how the spell-checking modules works are those that maintain it. Good Linux programs are written the same way good C++ programs are written: the programmer combines pre-existing functions and classes with custom ones that he or she writes. In doing so, a functional program is created that meets the needs of solving a particular problem or set of problems. If you are writing Linux software, even in a language other than C++, the same basic principles and concepts will allow you to write good code.

So we have created a basic conceptual relationship between the disciplines necessary to produce good C++ code to producing good Linux programs. Linux programs can be written in C, C++, C#, D, Java, Pascal, or a host of other programming languages. The principles of writing good code in any application are the same. A good C++ programmer can become a good programmer in ANY language or application. How is this possible? A great professional athlete is always one who is well grounded in fundamentals. A player that is not strong in the fundamental skills can perform well in one game or one week, or even one season, but he or she cannot perform well for an entire career. Fundamental skills and good habits are a prerequisite for success in any field of endeavor. A good programmer forms and maintains good habits that can translate to any programming application. What are these fundamental habits?

1. Fully understand the problem.

• Let us imagine that you a Linux system administrator working for a large Fortune 500 company. Your boss says that he wants to deploy Centos on 500 desktops in a secure environment, giving each user access to Gmail, OpenOffice, the GIMP, and Pidgin. He wants you to set up the network such that all of the employees can communicate realtime using the instant messaging features of Pidgin. By the way, he wants this done in a week. It is really worth your time to give this problem a lot of thought. Do you have the skills to get this job done in the time that your boss has given you? Is his goal realistic? Is he effectively communicating to you what he really wants? You had better answer all all of these questions before you even start on the project. It is also important to be honest with your boss as to what is realistic and what is not. A good boss is flexible and understands that he or she may have to compromise on a deadline if he or she wants full functionality.

2. Planning, planning, planning.

• Adequate planning actually saves time in the long run. Once you fully understand the problem, you need to carefully plan out how to implement the solution. Will you download Centos to a “master” desktop and then replicate it onto the other 499 desktops? Is the hardware in all 500 desktop computers exactly identical? Answering these types of technical questions will help the administrator to come up with better solutions to the problem. This is exactly the same approach that our C++ programmer would take in solving a C++ programming problem.

3. Downloading, compiling, installing, set up etc.

• Now the actual work begins. In the C++ world, this is where the programmer would actually write the code. In our hypothetical Linux system administrator problem, this is where our administrator would actually begin to install Linux on the desktops and begin the configuration process. It is also important to generate easy-to-understand documentation for the process. This documentation should fall into at least 2 categories: technical documentation for the technical maintainers of the system, and non-technical documentation for the end-user. For example, the worker that wants to log on to his new Centos system and set up his or her Pidgin account may need a document to walk them through the steps of setting it up. Since users will always have different levels of technical expertise, you should always make documentation available to accommodate those who have the lowest level of expertise. Even those with the highest level of expertise will sometimes need documentation. Also, technical documentation may be needed if the person that originally set up the system leaves the company or gets promoted to a higher position. Someone will have to step into that person's place and maintain the system. Good documentation makes that task much easier.

4. Testing.

• Once the main tasks are complete, the system or code must be tested to make sure that it meets the required parameters. Any errors must be fixed before the final product is released.

5. Release the final product for production work.

• Once the final product passes all tests, it can be released for production work. Our Linux administrator can now allow his 500 users to log on to their systems and begin doing real work on them.

Once you master steps 1 through 5 above, you will be able to consistently solve any problem well, whether a programming problem, a Linux problem, or otherwise. Good luck applying these principles. I hope that they help you to tackle any challenges that you wish to overcome.