What is the "Parallel Programmer" Problem?

Brook's Law famously states:

Adding manpower to a late software project makes it later.

A slight generalisation of this law is that, even before a project becomes late, there is a limit to how much faster we can complete a programming project by adding more programmers to it.

The reason that this law and its generalisation apply is that programmers working on a project are never completely independent of each other – different parts of the code being worked on by different programmers interact with each other, so developers must communicate with each other and each developer must understand the design and intentions of the code being written by other developers.

If the programmers were independent of each other, then they could work in parallel. And the more finely the programming tasks could be divided into sub-tasks while maintaining independence, the faster the project could be completed.

The Problem of Communication Overhead

In the real world of software development, this independence does not exist. Different components of a software project interact with each other in many different ways, and different developers working on a project have to communicate with each other. The more developers there are, the more developers each developer must communicate with, and this communication requirement adds overhead.

Enter APTROW

The idea of APTROW is to use advanced programming technologies to provide read-only web views of Enterprise data. In the case of assisting with a software development project, the relevant "data" is the application itself, i.e. its source code, its run-time state, as well as the business data that the application acts on.

APTROW promises two benefits with regard to communication overhead:

• Because the APTROW applications are read-only, interaction between APTROW applications and other applications is limited. All dependencies are in one direction only (i.e. the design of the APTROW application depends on the structure of the data that it is providing a view on). Therefore the APTROW developer does not need to communicate very much at all with other developers.
• The intent of the APTROW application is to provide a better view of the target data, i.e. the application. Thus the APTROW application reduces communication overheads between all people working on the software project, including developers, designers, testers and possibly even end users. It does this because developers, designers and testers can take advantage of the APTROW web view to more easily see what is happening on the project, and in particular to see how different components connect to each other, for example the relationships between design specifications and software source code, or between each of those two and actual business data.

In other words, if we add an APTROW developer to a software project, to write an APTROW application which provides a web view of the application (from as many different perspectives as possible, including source code, run-time state and application data), other developers do not have to communicate with the APTROW developer, and, the APTROW application will help other developers to communicate with each other, in as much as the nature and structure of the application artefacts will be made more obvious and transparent to anyone using the web view provided by the APTROW application.

There will of course be some exceptions to the promise of no additional overhead. For example, if the meaning of some application artefact is very, very obscure, then the APTROW developer may not be able to determine with confidence what that meaning is, and they might have to actually ask other developers what the artefact means. (This does add some overhead, but at the same time it amounts to the discovery that something in the design or documentation of the application is so broken that the developers should fix it sooner rather than later. So the benefits should justify the additional overhead caused by the interruption to the application developer's development workflow.)

APTROW: Skillset Required

APTROW is most likely to deliver on its promises if the chosen APTROW developer has the required abilities. In particular:

• The APTROW developer should have sufficient knowledge and background to develop an understanding of all aspects of Enterprise applications without requiring excessive communication from other Enterprise workers.
• The APTROW developer should have a sense of how to make a good web view. A bad or confused web view could be worse than no web view at all. To give a particular example, a web view on a configuration XML file should be clearer and more informative than looking at the XML file directly (i.e. in a text editor or in a generic XML editor), and any links implicit in the file data should be presented as corresponding web links to web views on other artefacts.
• The APTROW developer should be familiar with APTROW tools, libraries and frameworks. (None of these exist yet, so this is currently hypothetical. Anyone doing APTROW right now will have to take part in the construction of those tools, libraries and frameworks. Hopefully some of them can be developed and shared as open source projects.)