Monday, February 03, 2014

From an old grumble of mine. I doubt I'd change a single word:

The complexity of any given software project may informally be judged as proportional to the number of requirements the design must satisfy raised to the power of the number of programmers involved, and the likely reliability as inversely proportional to that complexity raised to some power greater than unity.

(It should be understood that the number of programmers used here is not limited to those actively engaged in directly writing code for the project, but must also include, in some suitably scaled fashion, those who "contribute" to any libraries, objects, tools or operating systems involved. I usually describe this process as "The more, the messier")

In practical terms the consequence of this is that the only chance there ever is of producing reliable code is to reduce the number of requirements for each project and use small teams or competent individuals who are responsible for designing the entire system. The history of computing and indeed engineering in general is full of examples of successful designs using this strategy, and also of alternative large-scale design processes that consistently fail, overrun deadlines and eventually produce bloated unreliable garbage when they produce anything at all.

I have been asked "if that is really the case, what is the solution?" a question I regard as fundamentally flawed. There is no short-term solvable problem here; it's a limitation of human intelligence and the overheads of communication. They're hard limits, and any software project that cannot be divided into fractions which are within the capability of of a single competent individual should be expected to be (a) unreliable and (b) delivered late if delivered at all...

In the long run the problem may be solved by the development of AI and the arrival of more competent individuals/reliable communication; given the intractable nature of intelligence and the inherent inefficiency of the software development required to produce them I would not expect this development to occur for several decades.


  1. That was brilliantly put.
    As someone who has tried to learn Java and OOP, along with so called 'modern programming' methods, I can certainly empathise with the negative feelings (and results) these methods engender.
    /Sigh/. Whatever happened to Structured Programming and abstracting out to subroutines?

  2. I'm still wondering what happened to pointers...

    1. My understanding is that the pointers decided to nip off to the pub for a swift pint or two. :)