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.
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.
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:
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 is most likely to deliver on its promises if the chosen APTROW developer has the required abilities. In particular: