This was actually a rather trivial example. Consider the problems faced by governments building databases of people entitled to claim benefits, or who need to pay taxes. If the initial methods of structuring are incorrect then small inconsistencies in the data mean that we cannot reliably and consistently interpret the data as information. The inconsistencies will cause ever increasing problems, and new layers of software need to be added to stop the inconsistencies spreading and corrupting the whole database. The reason we hear so often that Government IT projects go over budget and sometimes fail completely is that the the design problems really are extremely complex and difficult to get right - and unfortunately it is not always the case that people employed to commission these large system, or even those who build the systems are adequately qualified and experienced. (Really good IT experts can normally earn much more outside government!)
Most programs that are worth writing in the first place normally experience multiple cycles of subsequent modification. (Only completely unsuccessful programs or completely perfect programs - I have never seen one - never need to be modified.) All of us who work with software know the nightmare of "legacy" systems that have to be given new functionality in spite of less than adequate initial design. We often spend more time papering over the inconsistencies associated with the original structure than we do on delivering the new functions. (Ideally, of course, one should start again, and indeed it is often likely to be cheaper to do so - but try explaining all this to managers with little knowledge of software engineering. A system was apparently doing everything it should do last week, and it really requires only a small amount of new functionality, doesn't it?)
Even on the smaller scale, in my experience it is much more common to find that a program becomes difficult to modify because the information handling is badly structured, rather than that the algorithms are badly structured. It is, in fact, often fairly straightforward to reallocate essential algorithmic code into sensible subroutine hierarchies. (I have had to do this many times.) Correcting the information structures, on the other hand, can be like trying to replace the foundations of a house: difficult, expensive and by no means guaranteed to produce satisfactory results. I have insisted on complete redesign of certain software systems when faced with this problem. (You need a lot of credibility with management to get away with this.)