Software is People

Software is People(battlehardened.wordpress.com)

16 points by kentonwhite 14 years ago | 4 comments

gruseom 14 years ago |

What is saved in the source code is less important than what is stored in the brains of the people who wrote it.

Very much so. The classic articulation of this is by Peter Naur (the N in BNF) in his 1985 paper "Programming as Theory Building". A software system is a set of concepts ("theory") residing in the minds of the people who build it. Source code is a lossy expression of this.

I often wonder would come out differently if one took that insight as a starting point for organizing software work and rigorously followed its consequences regardless of convention.

6ren 14 years ago | |

Thanks, sounds like exactly my perspective. google viewer version of Naur's paper https://docs.google.com/viewer?url=https://blog.itu.dk/SASU-...

People have tried to put more of the theory into the source e.g. literate programming. UML and design patterns can be seen as a (not entirely successful) attempt at this.

Crucial to a "theory" is the "data". A test-suite can record this data, suggesting that tests need not only be about the software (or testing it, or documenting it), but also about the problem.

On theories: Sometimes when a project expands in scope, a different theory is needed. Not to cope with the greater load, but to interpret it differently - like how uncropping an image can reveal a different interpretation.

gruseom 14 years ago | | |

Things like better documentation and diagrams are bound not to suffice if Naur's view is correct that the program lives in the minds of the people who build it. To say, "Oh, the source code doesn't tell us everything, therefore we'd better produce additional documents that do," misses that point.

The best contribution I know of that works well with Naur's idea is Eric Evans' concept of ubiquitous language.

Darmani 14 years ago |

All information about software is contained in the software itself. Looking through an executable can be like reading a historical document. Programmer's quirks, late-night hacks, and beautiful insights all become visible. Eventually, the overall architecture and design appears, and we gain glimpses of the environment that produced it.

But unlike the executables, our source code is designed for humans to read, and only incidentally for machines to execute. When important information is hidden away in design documents and our heads, the code slowly changes from an orchard into a minefield. When you need to ask someone how something works or how to change a module rather than glance at a few lines or diagrams, we begin to lose our status as masters, and become trespassers. When we entangle our code, we entangle ourselves.

As programmers, we strive to put our souls in the code, making it a timeless artifact that can stand on its own. Creating software that can live apart from its creators is an ideal that few reach, but it is necessary if we wish to avoid spending a lifetime on child support.