The specification and the TODO-list

Sigfrid Lundberg's Stuff 2009-11-01

Bookmark and Share

People within any profession or trade should continuously be involved in discussions of quality. I describe my profession as web developer and my trade as digital libraries. These areas are no exception.

Like many web developers I spend a better part of my day on coding and other activities related to software development. But so do people involved in non-linear oscillation simulators. The web is an application area, but like non-linear systems it is also an area of research on its own right, and so is digital library research.

There is more to digital libraries than just software development. There are all research concerning resource description, and how it relates to usability. There are also extensive standardization work going on. Now, how much digital library knowledge would a programmer need to know in order to build a good service?

The specification and the TODO-list

In theory nothing. If the specification is good enough, then the product should be good enough and this could, again in theory, ensured by unit tests.

The problems here are, first, the quality of the specification, and, secondly, the Two Cultures (developers and editorial staff do not always understand each other). The two problems are related to each other.

The specification is a part of the agreement between the programmer and his or her customer. The work is completed when everything in the spec is in place. Programmer's need to know when they can send the bill.

We who write software, we're a kind of mathematical people. We will feel secure if we know that the axioms are in place, that the theorems are there as well, and that the deductions are correct.

For instance, if a piece of software is intended to assist an aircraft both at take-off and landing, then the specification should say so. Even if we thus kind of state the obvious, or if could imagine that there is no space in the sky for all planes that wouldn't be able to land.

The web and software as services

The web changed this. Not entirely but to a very large extent. There's a fundamental difference between being a vendor and being a service provider. The service provider try to get more users all the time which calls for continuous development.

Through the web, a software vendor and a service provider could all of a sudden compete on the same market. The software vendor use the traditional specification, but a service implies software which is in continuous development. Strictly speaking, there are no projects anymore, just different activities. No specifications anymore, but TODO lists containing incidents, bugs and requests for features ranked by importance.

And there is a continuous need for innovation.


Subscribe to Stuff from Sigfrid LundbergSubscribe to my stuff

stuff by category || year


My name is Sigfrid Lundberg. The stuff I publish here may, or may not, be of interest for anyone else.

On this site there is material on photography, music, literature and other stuff I enjoy in life. However, most of it is related to my profession as an Internet programmer and software developer within the area of digital libraries. I have been that at the Royal Danish Library, Copenhagen (Denmark) and, before that, Lund university library (Sweden).

The content here does not reflect the views of my employers. They are now all past employers, since I retired 1 May 2023.

Creative Commons License
This entry (The specification and the TODO-list) within Sigfrid Lundberg's Stuff, by Sigfrid Lundberg is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.