The first thing that grabbed me about Best Software Writing is the table of contents. Don't you just want to know "How Many Microsoft Employees Does It Take To Change A Lightbulb?" Or "What To Do When You're Screwed?" Or indeed "Starbucks Does Not Use Two-Phase Commit" Immediately it's obvious this is not a dry-as-dust tome on programming. Indeed, with the exception of Bruce Eckel's "Strong Typing vs Strong Testing" and Why The Lucky Stiff's canter through Ruby there's barely any programming at all.
What we get instead is writing about writing software, about the processes involved. For instance, Eric Lippert's punchline to the lightbulb joke is actually an amusing piece on change control. There are essays on coding. Ken Arnold argues cogently that it does not really matter which set of coding standards your project uses providing it uses something and everybody adheres to it. I agree. For a long time I have felt that the most useful tool Quest Software sells is not TOAD but PL/Formatter: it obviates all that useless time spent debating, codifying and enforcing layout standards. Apart from anything else coding standards tend to define that which can be defined - capitalisation, indentation, line breaks - when the most important things are: does the program implement the required functionality? Does it do so correctly, reliably and efficiently?
There are pieces about UI design and system design. Gregor Hohpe muses on the way Starbucks sells coffee as a metaphor for exploring messaging architecture. There are essays on project management, hiring developers, remunerating developers, outsourcing developers. There's even stuff about Sales! There are several TLA-splattered mediations on the future of the Web and the current state of the technology used to build it.
As someone who has wrestled with the issues thrown up by building a rich client interface out of JSPs I found some interesting insights in John Gruber's "The Location Field Is The New Command Line". Users want something that works, reliably, rather than something that looks pretty or comes with lots of gee-whizz features. Leon Bambrick makes the same point visually by imagining Google with MS Explorer's search interface. The corollary of this is the importance of methodologies like RAD (DSDM, XP, Agile, whatever). In order to demonstrate that our software works we must put working software in front of users on a regular basis. Otherwise we end up with requirements, specifications and acceptance tests predicated on aesthetics and the quantity of functions included.
The mix of technology is revealing. This is Spolsky's personal choice so the articles are skewed towards Microsoft's products and their technology base. There is C, C++ and VBA. There is a bit of Python and Ruby but almost no Java. There's lots of stuff about front-ends and middle tiers but nothing about databases. Certainly nothing about Oracle. Does this mean there's no good writing about databases or just that Spolsky doesn't read it? Actually, probably the former: most database writing is abstruse lectures about relational theory, uninformed witterings on normalisation or polemical rants about the inferiority of relational databases compared to object-oriented programming. Not many laughs there.
I have been calling these pieces as "essays" but they are an assemblage of various verbal constructs. There are proper essays, true. But there are also blog entries, transcriptions of conference speeches, even cartoon strips. What they have in common is that all are available on the internet. Even the Introduction is published on Joel On Software. What this means is we could click over to Google and by entering the table of contents into the location field assemble a copy of the book very cheaply (free if we print it at work, not that we would ever use our employer's paper for personal printing). So why buy the book?
Well, for a start it's got a nice colophon. And an index. Spolsky adds some insightful introductions and comments to each essay. The book is a nice size for reading on the tube or in the bath, neither of which is yet pratical with a laptop. But primarily, purchasing the book is a way of acknowledging the contribution the authors have made to the software writing community.
Tuesday, August 16, 2005
Surveillance
Yesterday I spotted outside New Scotland Yard a lone protestor with a home-made (A4) placard sporting the message:
Well I think we can all agree that's a pretty serious accusation. But what exactly is a homophonic crime? Some examples...
As the author of this heinous piece I fully expect to be put away myself, for commiting pun crimes.
Anyway, it is strange that the Fulham constabularly don't investigate homophonic crimes, as they ought to be partcularly alert to homophones. After all, the supporters fanzine of the local football club is called "There's Only One F In Fulham".
Fulham Police won't investigate homophonic crime.
Well I think we can all agree that's a pretty serious accusation. But what exactly is a homophonic crime? Some examples...
- A negligent road maintenance department that let the tarmac melt in the summer heat could be charged with Highway Rubbery;
- People who insult the village priest ought to find themselves investigated for committing Offences Against the Parson;
- There are a number of jazz-influenced buskers on the tube who ought to be locked up as Sax Criminals;
- Several violent Scotsmen should be locked up under the Dangerous Dougs Act;
- Could I get away with one about Jordan and the Dangerous Dugs Act? Probably not. Still, two homophones for the price of one!
As the author of this heinous piece I fully expect to be put away myself, for commiting pun crimes.
Anyway, it is strange that the Fulham constabularly don't investigate homophonic crimes, as they ought to be partcularly alert to homophones. After all, the supporters fanzine of the local football club is called "There's Only One F In Fulham".
Tuesday, August 09, 2005
Java "Not a Memory Hog" shock!
According to Xiaobin Lu on Java.net it is just the way the JRE maps the jar files in memory that makes Java look like it has a big footprint in (say) Task Manager. So they've rewritten the mapping in the latest build of Mustang. The really interesting thing is that the new mapping technique on Linux and Solaris works the way it always did on Windows and so saves 12-13% on real memory usage, as well as reducing the perceived usage. Java more efficient on Windows than on *nix - who'd have thunk it?
Friday, August 05, 2005
BCS MiniSPA: Refreshing and Invigorating
The BCS SPA group organised a one-day sampler of their SPA conference in London. Not being a member of the BCS I have never attended the actually conference (they are rather pricey). But this was free so it was not a hard sell to my bosses. Boy am I glad I went! It was a chance to immerse myself in ideas and issues that I just don't get the chance to ponder in normal working life.
Heuristics for improving Precision in UML Models
Mitchell presented (with James chipping in) a case study on the application of OCL to UML type diagrams. As I have only a shaky grasp of UML and know nothing about OCL I was surprised by how much of this talk I could follow. It was addressing a similar problems that are faced in Entity Relational modelling. If you have an optional One-To-Many relationship, what rule defines when there are no children? If you have an entity that has two different relationships to another entity is that one instances or two instances of the child? Always?
The rules are annotations to the Type diagram, consisting of a comment, which is the rule in natural language, and a OCL specification. Mitchell starts by formulating the rule in English. He leaves it for a while before converting it to OCL. It is important to understand the rule informally before expressing it formally, because that's the way the brain works. Finally he uses the result of the OCL formalisation was used to polish the natural language version of the rule so that it can be understood by the business experts.
This process is an iterative one, drilling down through the ambiguities in the data model. Frequently the exercise reveals contradictions or omissions in the business rules, which require the modeller to ask deep questions of the business experts, questions which sometimes they cannot answer. The presenters described some interesting customer reactions in reesponse to the process. The first said, "Your rules are different to mine. Yours are easier to understand." Another accused Mitchell of lying in their first interview, on the grounds that the questions he was asking were so perceptive he must have had prior experience of the business domain before starting work. A third customer has been so atagonised by software modellers asking difficult questions about their business that they have abandoned visual modelling and have returned to giving developers written specifications (probably in Word).
Architectural Evaluation for Fun and Profit!
The only presentation I attended by some one I was familiar with. Eoin Woods discussed two methods proposed for the SEI for evaluating a software architecture1. Actually it seems to me that this is a process for validating a proposed model to ensure that it satisfies all the requirements rather than a technique to compare different architectural approaches. Although I suppose there's no reason why we couldn't apply these techniques to the process of choosing an architecture.
The first technique, SAAM, is a walk through of the architecture by the various architects. It is focused on the functional requirements only. Its chief merit is that it is easy to understand and learn. The second technique ATAM is an evolution of SAAM. It is more complicated, as it prescribes two phases. However, in its favour is that it evaluates the architecture against all requirements, functional and non-functional. Also the second phase involves all the stakeholders not just the architects.
Definitely one to be filed under I wish I'd known that last year.
Creativity, the Path to Innovative Requirements
One way of looking at this presentation was that it was an extended advert for workshops run by Suzanne and James Robertson and Neil Maiden, but that would be grossly unfair. This was an engaging and enlightening discussion of how creative thought can be fostered, even compelled. The goal is to produce a set of requirements for the system that the customer doesn't yet know he wants. In this regard, Maiden sees the requirements gathering process as being the start of the design phase as much as the end of the analysis phase. Controversial stuff.
The working definition of creativity is thinking that is both novel and useful. People are very good at describing the constraints on a system. The key to creativity is to get them to think about how the system could work if those constraints no longer applied.
Lots of thought and preparation goes into these workshops. They need to generate an atmosphere of fun, freedom and safety, and yet must remain focussed on the goal. So the planning includes not just a deep understanding of the problem but choosing music, games and talks from experts in analogous fields to relax the particpants and spark ideas. The faciltators must keep the workshops running to a rigourous timescale. So it's quite hard work.
One common thought from developers on allowing their users' imaginations to run wild when it comes to requirements will be that the users will end up asking for the moon on a stick. Maiden and co have a radical suggestion that keeps the requirements within the bounds of the possible: the participants in the workshops represent all the stakeholders, including the developers.
The meeting ended with an invitation to nominate the most surprising thing we had learned. After some consideration I chose an insight from Neil Maiden's presentation:
This is a striking thought but also quite obvious once you think about it. The user has a problem (my job is to ensure planes don't crash into each other) and their requirement is the solution to that problem (the system will allow me to see the exact location of planes in my airspace). What was genuinely surprising was that some people hissed when I stood up and said this. Presumably because software developers tend to equate "solution" with "implementation". But if the requirements are feasible, coherent and validated, and developers have been involved in the specification of them, what's wrong with that?
1. Software architecture is the termininology used by the SEI, because they are sponsored by the US DoD, who have different definitions of hardware! Software architecture includes hardware platform, operating system, etc. (back)
Heuristics for improving Precision in UML Models
Presented by Richard Mitchell and Rob James
Mitchell presented (with James chipping in) a case study on the application of OCL to UML type diagrams. As I have only a shaky grasp of UML and know nothing about OCL I was surprised by how much of this talk I could follow. It was addressing a similar problems that are faced in Entity Relational modelling. If you have an optional One-To-Many relationship, what rule defines when there are no children? If you have an entity that has two different relationships to another entity is that one instances or two instances of the child? Always?
Your brain is not a formal engine.
The rules are annotations to the Type diagram, consisting of a comment, which is the rule in natural language, and a OCL specification. Mitchell starts by formulating the rule in English. He leaves it for a while before converting it to OCL. It is important to understand the rule informally before expressing it formally, because that's the way the brain works. Finally he uses the result of the OCL formalisation was used to polish the natural language version of the rule so that it can be understood by the business experts.
This process is an iterative one, drilling down through the ambiguities in the data model. Frequently the exercise reveals contradictions or omissions in the business rules, which require the modeller to ask deep questions of the business experts, questions which sometimes they cannot answer. The presenters described some interesting customer reactions in reesponse to the process. The first said, "Your rules are different to mine. Yours are easier to understand." Another accused Mitchell of lying in their first interview, on the grounds that the questions he was asking were so perceptive he must have had prior experience of the business domain before starting work. A third customer has been so atagonised by software modellers asking difficult questions about their business that they have abandoned visual modelling and have returned to giving developers written specifications (probably in Word).
Architectural Evaluation for Fun and Profit!
Presented by Eoin Woods
The only presentation I attended by some one I was familiar with. Eoin Woods discussed two methods proposed for the SEI for evaluating a software architecture1. Actually it seems to me that this is a process for validating a proposed model to ensure that it satisfies all the requirements rather than a technique to compare different architectural approaches. Although I suppose there's no reason why we couldn't apply these techniques to the process of choosing an architecture.
Bubbles don't crash
The first technique, SAAM, is a walk through of the architecture by the various architects. It is focused on the functional requirements only. Its chief merit is that it is easy to understand and learn. The second technique ATAM is an evolution of SAAM. It is more complicated, as it prescribes two phases. However, in its favour is that it evaluates the architecture against all requirements, functional and non-functional. Also the second phase involves all the stakeholders not just the architects.
Definitely one to be filed under I wish I'd known that last year.
Creativity, the Path to Innovative Requirements
Presented by Neil Maiden
One way of looking at this presentation was that it was an extended advert for workshops run by Suzanne and James Robertson and Neil Maiden, but that would be grossly unfair. This was an engaging and enlightening discussion of how creative thought can be fostered, even compelled. The goal is to produce a set of requirements for the system that the customer doesn't yet know he wants. In this regard, Maiden sees the requirements gathering process as being the start of the design phase as much as the end of the analysis phase. Controversial stuff.
Creativity is not unstructured thinking.
The working definition of creativity is thinking that is both novel and useful. People are very good at describing the constraints on a system. The key to creativity is to get them to think about how the system could work if those constraints no longer applied.
Lots of thought and preparation goes into these workshops. They need to generate an atmosphere of fun, freedom and safety, and yet must remain focussed on the goal. So the planning includes not just a deep understanding of the problem but choosing music, games and talks from experts in analogous fields to relax the particpants and spark ideas. The faciltators must keep the workshops running to a rigourous timescale. So it's quite hard work.
One common thought from developers on allowing their users' imaginations to run wild when it comes to requirements will be that the users will end up asking for the moon on a stick. Maiden and co have a radical suggestion that keeps the requirements within the bounds of the possible: the participants in the workshops represent all the stakeholders, including the developers.
Wrap up: The reflective practitioner
The meeting ended with an invitation to nominate the most surprising thing we had learned. After some consideration I chose an insight from Neil Maiden's presentation:
A requirement is a solution.
This is a striking thought but also quite obvious once you think about it. The user has a problem (my job is to ensure planes don't crash into each other) and their requirement is the solution to that problem (the system will allow me to see the exact location of planes in my airspace). What was genuinely surprising was that some people hissed when I stood up and said this. Presumably because software developers tend to equate "solution" with "implementation". But if the requirements are feasible, coherent and validated, and developers have been involved in the specification of them, what's wrong with that?
Thursday, August 04, 2005
What I learnt about Oracle today
SQL> SELECT id, some_date
2 FROM tst1
3 ORDER BY some_date
4 /
ID SOME_DATE
---------- ---------
8 03-JAN-05
10 10-FEB-05
1 18-FEB-05
2 24-FEB-05
6 26-FEB-05
9 01-MAY-05
7 20-MAY-05
4 29-MAY-05
3 18-JUN-05
5 09-JUL-05
10 rows selected.
SQL> SELECT id, to_char(some_date, 'DD-MON-YYYY HH24:MI:SS') AS some_date
2 FROM tst1
3 ORDER BY some_date
4 /
ID SOME_DATE
---------- --------------------
9 01-MAY-2005 09:58:09
8 03-JAN-2005 11:00:33
5 09-JUL-2005 21:01:44
10 10-FEB-2005 03:19:58
1 18-FEB-2005 00:46:04
3 18-JUN-2005 03:06:05
7 20-MAY-2005 08:20:05
2 24-FEB-2005 08:17:43
6 26-FEB-2005 07:12:51
4 29-MAY-2005 14:21:38
10 rows selected.
SQL> SELECT id, to_char(some_date, 'DD-MON-YYYY HH24:MI:SS') AS the_date
2 FROM tst1
3 ORDER BY some_date
4 /
ID THE_DATE
---------- --------------------
8 03-JAN-2005 11:00:33
10 10-FEB-2005 03:19:58
1 18-FEB-2005 00:46:04
2 24-FEB-2005 08:17:43
6 26-FEB-2005 07:12:51
9 01-MAY-2005 09:58:09
7 20-MAY-2005 08:20:05
4 29-MAY-2005 14:21:38
3 18-JUN-2005 03:06:05
5 09-JUL-2005 21:01:44
10 rows selected.
SQL>
Hmmm....
Oracle's SELECT statements support column aliases in the ORDER BY clause. Now when did that happen? Actually Oracle's been doing so for years, since at least 8i. It's one of those things I feel a fool for not knowing about, but at the same time I'm glad there's still things about even very basic Oracle that I have yet to learn.
A piece of seventeenth Taoist wisdom, cited in The DailyZen Journal:
If people want to do the finest thing in the world, nothing compares to learning. If they want to be the best of learners, nothing compares to learning the Way.
Wednesday, August 03, 2005
Meanwhile, back at the Strategy Boutique
I see the government's procurement body is now called OGCbuying.solutions (sic). Such a dense melding of typographical tricksiness and trendy jargon, it's virtually a black hole of faddishness. And it probably only cost the taxpayer a couple of million in consultancy and rebranding costs.
However, the home page shows that while the OGC call-off catalogue is called Catalist the bespoke procurement brand (sic, sic) is the rather boring Managed Services. That's not really trying. How about a competition to come up with something zappier, more Zeitgeist-y? My suggestion is OutSauce.
However, the home page shows that while the OGC call-off catalogue is called Catalist the bespoke procurement brand (sic, sic) is the rather boring Managed Services. That's not really trying. How about a competition to come up with something zappier, more Zeitgeist-y? My suggestion is OutSauce.
Monday, August 01, 2005
Instant surrealism
I googled an e-mail domain this morning to see where an OTN forum poster was (literally) coming from. When I found it was a Chinese web site I couldn't resist clicking on the Translate This Page option. It's obviously an entertainment site and a description of a movie (or several movies???) generated this cool surrealist poem:
Neat icy cold one summer with beautiful woman bright one both eyes
- < Comedian clown wonderful soldier > wears the mask ??
- " Love map " three metropolises foreign lands love
- " Fords grain language " the militarism reactionary gang history
- < Sentiment confuses forbidden fruit > the Russian desire metropolis
- " Thirstily strives for ?? " and likes to the ethyl alcohol relying on
- " The Paris person " the amphoteric war initiation disputes
- " Paris sweetheart, New York sofa " fate
- " Milk price " lover and cows
- " Red apricot leaves wall " the classical family ethics piece
Andre Breton, you should be living now!
Subscribe to:
Posts (Atom)