Software as abstraction – cognitive limitations

by daniel on January 11, 2009

As told in previous post, software is a figment of our imagination forged into an actual physical representation, encased in a physical box called a computer. This post deals with the cognitive limitations in the forging process and why software architecture and design can help overcome or at least minimize some of the limitations.

When the programmer sits to write some software he begins with an idea and a rough implementation guideline. Gradually, the rough guideline becomes details, and the idea if molded into the implementation. Unfortunately, since the imagination can cope with limited amount of details, there are discrepancies between the imagined guideline and the written code. The implementation process is also limited by the API capabilities and the intricacies of the programming language itself. In addition there are also some other limitations of the coding process:

  • Abstraction of ideas vs. the details of programming language.
  • The number of lines of code that can be handled in the head of the programmer.
  • Sometime failure in the logic and breakdown of the software.

It seems that the major hurdle in the process of forging software is the complexity of managing the details, so a method is required for managing the details and hiding them when not needed. My favorite way of managing the complexity is by using software (or system) architecture. A description of how software architecture is detailed in (hyperlink to rick book). In short, architecture defines the external properties of each building block and the relationship between blocks. By using this method, the software can be split into different modules, each one performing a function, leaving the details to a later time and different perspective. When implementing the internal module, the perspective changes, so the same method can be used for segmenting the module. In a recursive way, this method simplifies the complexity up to the point of making each module easier to implement.

There are some pitfalls to this approach, as detailed in this list:

  • Lack of context – the description of a module hides the other modules, so the programmer might loose touch with the original design.
  • Hiding of logical errors – detail hiding might mask logic errors that will be found later in the development.
  • Not intuitive – many people have problems with abstractions and need concrete details.

It’s important to remember that any of the above can mislead if the architecture is not properly documented. The documentation should be according to the decisions taken and be coherent with the needs of the organization, not only the developer.

To summarize, there are cognitive limitations to a programmer, essentially the complexity of any non trivial software. Thus a method is needed to manage the complexity and allow zooming in and out. Software architecture methods provide a basic tool, used effectively can reduce the complexity and give better control on the development process.

No tags for this post.

Comments on this entry are closed.

Previous post:

Next post: