Most of the software I write is based on business processes, which surely won't even last 20 years (more likely 2 to 5 years), and/or technology (I work at an I

Most of the software I write is based on business processes, which surely won't even last 20 years (more likely 2 to 5 years), and/or technology (I work at an ISP and data center provider, so we manage stuff like IPs, VLANs, Hardware, Racks) which likely also won't last 200 years. The example from the article about accounting software is another good example: legal requirements change, which means that the software must also change; book keeping software from 30 years ago is utterly useless today, not because it wasn't done well, but because too much changed. Another example from the article: parking tickets. There were no parking tickets 100 years ago (80 years ago according to http://theexpiredmeter.com/2009/08/first-parking-ticket-issued-in-1935/ http://theexpiredmeter.com/2009/08/first-parking-ticket-issu...), and I doubt that however traffic looks in another 100 years, it will have not much in common with our current structure. My takeaway is that we shouldn't worry too much about longevity of the software; the more important aspect is the data formats. They should be open and well-documented, so that folks in the future have less trouble dealing with our data footprint. Maybe our data will still be of value in 200 years; at least some of it, and at least a bit. But I doubt our software will be, regardless of how we write it. I do agree with his points about the need for better review processes and oversight. Update: Forgot one important point: Input method and user input devices change a lot. Who wants to use software today that assumed a max screen resolution of 600x400 or even lower? And no mouse, no touch screen, no audio or image or video input, even it would be highly desirable for the problem domain?