As programming languages excel to higher levels with OOP reuse and the vast availability of the once absent plethora of APIs, many of the thought processes have degraded especially in the business environment where the tendency to exclude efficiency in every-day coding habit of style is obvious. A plan for project scope is laid out, but without sufficient thought to design. Simply "Getting The Job Done" is too often the mentality. Efficiency and reuse can be employed in applications development with no impact on the unlikelihood of meeting expected milestones in time. The architectural complexity of a programming task is the first item to consider before coding. When a difficulty arises in designing the structure of a task, usually the situation will resemble a previous encounter of an identical situation in another programming task. Eventually you build up a database of techniques, or algorithms that are automatically triggered from your memory and you know that your prior solution will be amongst the best candidate solutions to the programming task at hand. Implementation reuse is the initial consideration necessary for every programming task solution plan. Recall any previous resemblance in implementation and work on that. It is therefore necessary to apply efficient techniques so that you have a good working solution for your next encounter. It is too tempting for programmers to apply the simple, inefficient means to completing a task as long as it is accomplished. The next time a similar situation is encountered it will prove invaluable to have already implemented an efficient solution. Structurally speaking, complexity is quality. Software engineering is a very complex field at all levels, but more so for the lower-level programmers that provide the rest of us with object reuse and APIs for more specific application development. Selecting the proper technique to completing a programming task is a skill that becomes a part of habit and eventually proves more beneficial to design consideration deja vu in all scenarios of application development.

Common data structure considerations: What method of data access should I use for a particular task? What successful technique did I implement in a previous design issue? Some methods include: hash table/associative index, quick sort/binary search, sequential sort/search, arrays, linked lists, binary or tertiary trees or a combination of these methods. Generally speaking, how many passes and nested loops will this task entail? Using complex data structures for data access, I should be able to reduce the depth level of nested loops for necessary comparison, search, sort or other operations required by a particular task. This in turn will reduce the big (O) notation of complexity from n^x to n. This is efficient, and performance is good.

What else needs to be considered? First of all, data structures are the basis upon which the rest of the implementation will shape the complete solution to a particular programming task. But the selection of data structures are affected by the following, second structural consideration:

Thinking in terms of separation or break-up of any task into two categories of specificity and generality is the key design principle to any task. The OOP methodology is based on this design principle. Separate the common (general) attributes of an object or concept from the specific attributes, and group the common functionality and attributes (data) into a class, whereas the specific attributes and functionality are grouped into the specific sub-class(es) of the generic parent class. The terms Common, general and generic are synonymous and refer to the parent class in relation to the children (sub-classes) that inherit the parent's attributes common to all children.

Example of a business application in the context of design: A GUI form is to be presented on-screen with various input controls and text labels containing names, monetary amounts, and various text properties such as style and alignment. Rather than coding a specific form it may be more beneficial to create a generalized routine that may take as input the various form elements from perhaps an array or other data structure with various parameters. The routine will handle the input based on parameters indicating the type of form to be displayed in various formats from tabular to custom layouts. The routine or class may also process a form for database read/ write procedures and data validation. This generalization could then be re-used to create or modify any number of different forms and would reduce development time and effort both immediately and for future modifications. Form-specific code is then reduced to parameters, whereas the code pertaining to logic is created only once as it is generalized for all common form-related functionality.