The beginning of wisdom for a programmer is to recognize the differenc — Michael A. Jackson

"We follow two rules in the matter of optimization:"

"My first serious programming work was done in the very early 1960s, in Assembler languages on IBM and Honeywell machines. Although I was a careful designer — drawing meticulous flowcharts before coding — and a conscientious tester, I realised that program design was hard and the results likely to be erroneous. Into the Honeywell programs, which formed a little system for an extremely complex payroll, I wrote some assertions, with run-time tests that halted program execution during production runs. Time constraints didnt allow restarting a run from the beginning of the tape. So for the first few weeks I had the frightening task on several payroll runs of repairing an erroneous program at the operator’s keyboard ¾ correcting an error in the suspended program text, adjusting the local state of the program, and sometimes modifying the current and previous tape records before resuming execution. On the Honeywell 400, all this could be done directly from the console typewriter. After several weeks without halts, there seemed to be no more errors. Before leaving the organisation, I replaced the run-time halts by brief diagnostic messages: not because I was sure all the errors had been found, but simply because there would be no-one to handle a halt if one occurred. An uncorrected error might be repaired by clerical adjustments; a halt in a production run would certainly be disastrous."

"Systems engineering as an approach and methodology grew in response to the increase size and complexity of systems and projects. It "recognizes each system is an integrated whole even though composed of diverse, specialized structures and sub-functions..." (Chestnut, 1965) This engineering approach to the management of complexity by modularization was re-deployed in the software engineering discipline in the 1960s and 1970s with a proliferation of structured methodologies that enabled the the analysis, design and development of information systems by using techniques for modularized description, design and development of system components. Yourdon and DeMarcos Structured Analysis and Design, SSADM, James Martins Information Engineering, and Jacksons Structured Design and Programming are examples from this era. They all exploited modularization to enable the parallel development of data, process, functionality and performance components of large software systems. The development of object orientation in the 1990s exploited modularization to develop reusable software. The idea was to develop modules that could be mixed and matched like Lego bricks to deliver to a variety of whole system specifications. The modularization and reusability principles have stood the test of time and are at the heart of modern software development."

"A development method may be regarded as a path or a procedure by which the developer proceeds from a problem of a certain class to a solution of a certain class. In trivial cases, the method may be fully algorithmic; for example, there is an algorithmic procedure for obtaining the square root of a nonnegative number to any desired degree of accuracy."

"Jackson System Development (JSD) and Object-Oriented Design (OOD) have one major - arguably central - principle in common; namely that the key to software quality lies in the structuring of the solution to a problem in such a way as to reflect the structure of the problem itself. There should be a simple and demonstrable correspondence between a (real world) component of the problem and a (software) component of the solution. The two methods also use similar concepts to describe the problem domain (or real world). It is considered to consist of identifiable objects (entities in JSD) and operations that are either performed or suffered by these objects (actions in JSD}."