Great books never read

The Telegraph has a piece about great books you’re too embarrassed to admit you’ve never read.

http://www.telegraph.co.uk/arts/main.jhtml?xml=/arts/2008/07/22/bonever122.xml

I didn’t quite read the whole piece. For me my list of unread classics is too long to bother with. What does embarrass me are the books I’ve read where I come to the end, kind of wake up and say to myself, ‘whot was all THAT about?’

The way we were

I’m working on a book on business analysis/systems analysis as done by non-technical types, by users, (any publishers out there interested in a query letter?) and as part of that, I have been wondering what happens to old programmers.

I have the impression most people do not work that long as programmers, they drop out after a few years. Morph into some other technical discipline or, mostly, get into another line of work altogether. So, unscientific survey time: if you were, or are still are, a programmer could you send me a note and let me know how long you were a programmer, if you changed jobs or careers, what made you switch, and how you feel about the change. Thanks!

Incrementalism

More on change to an existing system. Development projects spend about 80% of their time (I made the figure up) just to recreate the existing feature set. I would think that users would ask why the heck we waste so much money just to get back to the starting line, but I suspect the reason is they have no idea what we’re doing, why we’re doing it or even if it really needs to be done. There are a number of good reasons why we have to recreate the world every time, but more to the point we like our incompatible, disruptive technologies. It makes us feel creative. Personally, I got tired to writing the same basic business all the time.

Design v Requirements, part 1

I am working on the Great American Novel (joke. Does anybody still think in those terms, BTW?) And I use Scrivener, not Microsoft Word. Scrivener seems much more attuned to the process of writing. Which is a lot messier and more chaotic than Word hints at. But Scrivener is not perfect and I was thinking about how I would improve on it. I would keep all that it has already, in the form that it has it. Just add a feature here, a feature there. But this thought process led off onto issues for business analysis–which is always there in the back of my mind.

Two things: in programming it is often difficult to just add features to an existing software system. In this case because I don’t have the source code and can’t just glue new stuff onto the existing code. Another situation is where the existing system is so incredibly old (like in COBOL and CICS) your programmers won’t touch it and tell you it has to be rewritten from the ground up. Well, recreating all the old stuff is very difficult and expensive. For me, it isn’t worth it. Better to adapt myself to what Scrivener offers. And bend Scrivener to my evil intentions. 

Second, I got to thinking that if we were in this beginning systems analysis class and I told the students to write the requirements for a ‘word processor’ I could expect them to write the requirements for Word. Not because Word is the last word in word processors but because what we are used to is the foundation for what we desire. (What was the line in Silence of the Lambs? “We covet what we see…every day”?) We have to be careful about this constriction of vision when we practice business analysis.

More on both thoughts next time…