How to Write a Program/Architecture
Programming:How to Write a Program Back to Table of Contents
Programming architecture is an amazing thing. Some architecture forms are incredibly complex, requiring years of practice to effectively master. Other forms require little or no previous development experience, making this category the best option for beginners. Please note that this discussion centers upon general development theory and not language or platform-specific technologies. Such information is critical to your success as a developer but a foundation must be laid in the mindset of what it means to develop software as a programmer before venturing beyond the general in search of the specific language(s) of your choice, depending upon your goals, needs, and existing skill set(s). Here are a few simple concepts to remember about programming in general:
Logic is more than geometry, as that math subject is where the majority of individuals discover ancient concepts that still dominate our thought processes today. Logic is an orderly definable process that arrives at a conclusion using pre-determined rules agreed upon by all related parties. I define logic in this light as it is the center point of all development. Without logic, creating the desired software logic in a way that could be interpreted by a computer of any kind would remain an impossible task. Thus, logic lays a foundation upon which both man (humans) and machine (computers) agree to operate on the same playing field. This is one of the greatest tensions in application development, as software bugs often arise from a miscommunication in the area of logic. For example, if the developer/programmer desires X functionality, and mistaking codes the logic in a way that the computer interprets as Y functionality, the developer/programmer (I will continue to use these two terms interchangeably) must re-evaluate his code to see where his thought process (logically speaking) did not line up with the computer's interpretation of that process. One of the most frequent headaches for new developers stems from the fact that it is easier to visualize the software functionality in a creative way than it is to interpret that concept into an orderly series of commands, requests, and other functions required to build what the individual desires. I will deal with creativity next, but suffice it to say that programming is one of those few trades that will always be an artform and a science at the same time. For this reason, a programmer just beginning to develop software must learn to search out the uncommon answers (creativity) while keeping his/her feet planted firmly on the ground (logic) to make the desired functionality a reality.
Creativity is the second-most important asset a developer can bring to the table when writing new software. It is a system of thought processes meshing together that generate new options for solving unique development challenges. No developer truly worth his salt can exist in this industry without learning to open his mind to new ways of thought, expression, and recognition. Indeed, it is the personal belief of the original author that a lack of creativity hinders the potential of every programmer who doesn't learn the power achieved in overcoming the 'box' syndrome. Simply stated, programmers are notorious for thinking inside the realm of what has been discovered, mapped, and utilized by a predecessor or associate, resulting in an imaginary space called the 'box'. It is in this box that the developer works, associates meaning, and derives solutions. The mark of a talented developer is the innate (or learned) ability to dynamically resize or reconfigure the 'box' in him/her to meet the unique programming challenge at hand. Breaking outside the barriers of the box is daunting, as it requires a perspective that may not exist within the developer himself/herself. A wise person once said, 'When you stop learning, you stop leading.' I humbly modify this statement for the purposes of software development and say, 'When you stop learning, you stop the flow of software innovation.' Achieving results in a fixed box may work for a time, perhaps even years if the box is significantly developed. However, the nature of the programming trade stipulates constant learning for the purpose of maintaining an edge in the industry. I'm focusing on the 'box' concept as it is truly impossible, I believe, to impart true learning in the area of creativity. It must be experienced for yourself, as you begin to think about your world from many different perspectives. If you choose to develop software for others as an ISV (independent software vendor) or system integrator, you will need to hold interviews with every type of user your software will service. Getting into the minds of others and discovering their wants and needs in terms of software functionality is the most rewarding, and yet oftentimes most challenging, aspect of being a programmer. Embrace alternate perspectives and alternate learning approaches to bring more mental collateral to the table that will enhance your creative edge.
Abstraction, simply put, is the number of layers sitting between you and the underlying hardware you’re targeting in the development cycle. For example, an ASIC developer writing software mapping for a video chipset operates at an incredibly different level of abstraction than a script developer for web-enabled applications. These are two separate worlds for many reasons, but in fact the web-enabled application developer may indirectly utilize the chipset writer’s codebase if he references a graphical component on a system having that chipset deployed. Always remember that a high level of abstraction means the software functionality sits on top of many layers of logic ‘plumbing’ in comparison to low-level abstraction that sits directly on top of the hardware in use. Developers often gravitate to the abstraction level that best fits their present skills and abilities, but don’t let complex programming at a low-level of abstraction scare you from attempting to develop software in that space. Find a beginning niche and work your way toward a desired level of expertise in the area that fits your desire and needs best.
Further reading 
- Wiki:ArchitectureAntiPattern mentions that too often, people design overly-complicated architectures. It is far better (Wiki:CanAnArchitectureEmerge) to get a simple version working first, then later improve it.