Another fine mesh. In reply to http://stream.red56.co.uk/post/23811614242/when-i-care-about-my-work

This is  great. Some random thoughts.

Don't worry about the list of things you want to write about - just worry about the next thing.
Pedantic point Haruki Murakami stole "What I talk about when I talk about running?" from Raymond Carver - "What we talk about when we talk about love."

We could try ping pong writing.  What's the best time of the day for you to write?  For me it's first thing in the morning, with a weird second period from about 4:30pm to 6:30pm, although just then when I write I feel like death. 

Some thoughts on what you wrote.  I think Ward Cunningham's concept of the system of names is really brilliant, but I've read the article and he does almost nothing with it.  I think it would be worth an ethnographer looking at a bunch of discussions around software - how many of them are about name changes? Name systems. Which is also to your point about how easy it is to change names.  Always a good question - what's easy? What is hard? I dread to mention this but have you seen Alan Blackwell and Thomas Green's stuff about cognitive dimensions? It disappeared up its own fundament (why are you not surprised?) but I think there was a genuinely useful set of questions about what sorts of things and what sorts of things were easy in a given notation.  In software that is easily maintainable, name changes need to be trivial (possibly with some some kind of history/undo capability).

Another thought on this: when I worked with front-end developers at Wiley they told me they could tell which sites would be cool to work for from the URL's.  Could you have some kind of coding language where URL's were first class objects - they are in HTTP, but not in any of the languages that support it. A web site truly is a system of names - if it isn't, it's probably a ball of mud.

One final thought about software quality.  It's interesting how the work I've been doing recently Kansas has made me think over and over of the Taiichi Ohno book "The Toyota Production System." And the books by the two American guys Womack and Jones.  The people who manage the "autonomated" (automated just enough) rather than automated machines are supposed to tidy up when for some reason they aren't busy doing something else.  They are supposed to sweep their stations.  In the American car companies which recently required bailing out, some other guys come in and sweep the stations.  We desperately need an understanding that tidying up is a hugely valuable and useful part of any software process and we need languages and tools that allow this to be done and shown as valuable.  Do that tie into work-flow somehow? Could we somehow show that a period of sustained development results in cleaner more maintainable code.

Just one more thing sir, I've been reading the "User Stories Applied" book and one of the descriptions of requirements gathering is as a series of trawls, with possibly a broader and then finer-grained mesh.  This is my experience of working with an issue-tracking system like Jira - it's how I worked as a scrum master, I trawled Jira for various things: all the work still to do in the backlog.  All the work still to do in the backlog that hasn't been broken down enough to play into an iteration.  All the defects that need fixing. All the issues that are "On-hold."  It strikes me that it would be really good to adopt a similar strategy for tidying up code. What would be a suggestion for some of the trawls.

A software system is a system of names.  Any modification to it is a series of trawls, what would be a big mesh trawl? What would be a fine mesh trawl.

74 views and 0 responses