ia play

One of the themes I’m always interested is the way some things seem new but have clear echoes in the past. I was fascinated (and slightly horrified) to read this history of computing article: Factory concepts and practices in software development (Open Library).

Most of the examples are describing problems with IT projects in the 1960s but they could as easily be applied to the projects I’ve worked on over the last decade. The table summarising aspects of the  1968 Nato Report on Software Engineering Problems (PDF) is scarily applicable.

• Lack of understanding in system requirements on the part of customers and designers.
• Large gaps between estimates of costs and time with actual expenditures due to poor estimating techniques, failure to allow time for changes in requirements, and division of programming tasks into blocks before the divisions of the system are well-enough understood to do this properly.
• Large variations, as much as 26:1 in one study, in programmers’ productivity levels.
• Difficulty of dividing labor between design and production (coding), since design-type decisions must still be made in coding.
• Difficulty in monitoring progress in a software project, since “program construction is not always a simple progression in which each act of assembly represents a distinct forward step.”
• Rapid growth in the size of software systems.
• Poor communication among groups working on the same project, exacerbated by too much uncoordinated or unnecessary information, and a lack of automation to handle necessary information.
• Large expense of developing on-line production control tools.
• Difficulty of measuring key aspects of programmer and system performance.
• A tradition among software developers of not writing systems “for practical use,” but trying to write new and better systems, so that they are always combining research, development, and production in a single project, which then makes it difficult to predict and manage.
• Rapid growth in the need for programmers and insufficient numbers of adequately trained and skilled programmers.
• Difficulty of achieving sufficient reliability (reduced errors and error tolerance) in large software systems.
• Dependence of software on hardware, which makes standardization of software difficult across different machines.
• Lack of inventories of reusable software components to aid in the building of new programs.
• Software maintenance costs often exceeding the cost of the original system development.

Source: Naur and Randell.

Must remember to ask my dad about his  early programming experiences and see if this fits.