I hesitate to describe an article on computer law, especially one about the enforcement of software contracts, as "interesting" but there is no doubt that this is an important area for all of us. Of course, one side applies primarily to product vendors and consulting developers but we are all of us on the customer side of the fence. So everybody ought to read Cem Kaner's piece on an American Law Institute initiative to write a new Principles of the Law of Software Contracts.
He has also published his presentation to the Conference of the Association for Software Testing on this topic. This contains lots of insights into the evaluation of licensing law but it does also contain screens full of legal small print (literally).
The focus of Cem's analysis is on the enforcement of warranties. In particular, the proposals would make software suppliers liable for damages suffered by their customers as a result of bugs which were known to the supplier but not disclosed to the customer. You can see why lawyers might be keen on this proposal: Have you suffered from Blue Screen Of Death? Turn those bugs into £££! Calls Claims Direct now!
On the other hand, certain things would become freer. For instance, under a "standard-form transaction" (i.e. one used by the general public, as opposed to an individually negotiated one) companies such as Oracle would be unable to prevent the publication of the unauthorised benchmarks. There might also be implications for certain aspects of the OTN licence, such as the recently discussed confusion over whether we can use a database downloaded from OTN at home for instructional purposes.
Tuesday, July 24, 2007
Roy Batty writes ...
It's official - I am not a robot. Blogger's team of blade runners has given my blog a Voigt-Kampff test and determined that it is indeed the work of a human being. This verification was necessary because last week Blog*Spot put me under an Anti-Spam-Blog Order. Their anti-spam bots ( ASbots???) had locked my blog as it has "characteristics of a spam blog." Hmmpfff. So what are those characteristics?
"spam blogs ... can be recognized by their irrelevant, repetitive, or nonsensical text", which is possibly the rudest thing anybody has ever said about Radio Free Tooting. It was the other characteristic which rang a bell: "...along with a large number of links, usually all pointing to a single site." The opening paragraph of my last post before the ASBO descended contained three links to pages on BCS SPA web-sites so I guess that's why the ASbots suspended my posting rights. This seems a rather tenuous reason but it's the best I can find. The ASbots don't have to offer explanations.
Spam blogs or - ugly neologism alert! - splogs are an increasing nuisance[1]. Given the number of sites which require monitoring it was inevitable that the task of policing Blog*Spot would be delegated to automatons. Still it seems strange that the giant brains who invented page-ranking can't come up with some better heuristics: perhaps checking the Google Analytics reports and my Technorati rankings, or even just looking at my posting history. On the bright side, I was only off the air for a day or so, and it's not like I had anything I needed to say.
One final thing. The ASbots don't send an e-mail. I suppose this is because most of the sites they bust really are sploggers, so notification would just generate a wasteful amount of spam e-mails. You only find out you've been ASBO-ed when you sign in to post something. The order includes this sentence:
Another good reason to have a backup of your deathless prose.
{1} - Especially for Blog*Spot. Apparently it's not such a big deal for WordPress. Although whether this is due to WordPress's superior technology or just because Blogger has the biggest mindshare is open to question.
"spam blogs ... can be recognized by their irrelevant, repetitive, or nonsensical text", which is possibly the rudest thing anybody has ever said about Radio Free Tooting. It was the other characteristic which rang a bell: "...along with a large number of links, usually all pointing to a single site." The opening paragraph of my last post before the ASBO descended contained three links to pages on BCS SPA web-sites so I guess that's why the ASbots suspended my posting rights. This seems a rather tenuous reason but it's the best I can find. The ASbots don't have to offer explanations.
Spam blogs or - ugly neologism alert! - splogs are an increasing nuisance[1]. Given the number of sites which require monitoring it was inevitable that the task of policing Blog*Spot would be delegated to automatons. Still it seems strange that the giant brains who invented page-ranking can't come up with some better heuristics: perhaps checking the Google Analytics reports and my Technorati rankings, or even just looking at my posting history. On the bright side, I was only off the air for a day or so, and it's not like I had anything I needed to say.
One final thing. The ASbots don't send an e-mail. I suppose this is because most of the sites they bust really are sploggers, so notification would just generate a wasteful amount of spam e-mails. You only find out you've been ASBO-ed when you sign in to post something. The order includes this sentence:
"If we do not hear from you, though, we will remove your blog from Blog*Spot within a few weeks."
Another good reason to have a backup of your deathless prose.
Tuesday, July 17, 2007
MiniSPA 2007: Better than working
I took yesterday off to attend the 2007 MiniSPA conference. This was a greatest hits compilation of sessions from this year's SPA conference. I almost typed "presentation" but relatively few sessions actually consist of a speaker at the front of the room reading PowerPoint slides to a passive audience. The SPA principles value interactivity and participation. Instead there is a variety of sessions types, most of which involve the audience in some way; tutorials, case studies, workshops, panel discussions, simulations and goldfish bowls. So agenda decisions have another dimension ("how much thinking do I feel like doing?").
The opening session was a think tank. We were divided into teams and each team had to complete the following sentence in no more than ten words:
Each team had to agree on its own phrase; then everybody voted on the phrase they liked the best. The secret of these things is to come up with something snappy and comprehensible. One team came up with a suggestion which had three clauses and used bullet points. That is a dead loss. You can't buttonhole somebody in the corridor and then ask them to wait whilst you boot your laptop and fire up PowerPoint. Here are a few of the final sentences.
That last slogan was the one for which most people voted, thus proving that people repsond to the clarity and focus which abstraction provides.
Mike Hunt (Mandu Ltd) led this workshop. Working in teams we had to build models of workspaces out of art card, Lego, Plasticine, Playmobil and various other craft materials. In the first round we had to build a bad working environment, then in the second round we had to build a good workspace. Although each team had a different scenario, the various models had certain common traits. The bad environments all tended to be cramped with people working in fenced-off isolation and with inadequate space for intra-team communication. Fans and other symptoms of poor air-condition featured a lot. The good workspaces were all spacious, with different rooms for different work modes. Bespoke desks and lots of whiteboards were common, and fresh fruit and/or baked goods were provided.
The striking thing was how much closer to real life the cartoon bad environments were. Most of the laughs came from recognition. The good environments on the other hand were largely wish fulfillment, and not just the ready availability of pastries. Floor space is expensive, particularly in London, and I doubt whether most companies would be prepared to devote so much square footage to pamper the developers. It is also unlikely that minions would be given so control over their own working environments. I was also amused to see that I had collaborated in designing an office which was basically open plan. I currently work in an open plan office (albeit cramped), and it can be very hard to concentrate. Sometimes a walled off cubicle seems a very attractive notion,
One interesting aspect of the process was how each team used the materials provided. In the first round we all tended to use the stuff closest to hand. The team with the Plasticine on its table had lots of blobs. Another team had been very creative with card. My team had the Lego so our office was largely built out of plastic bricks. However in the second round we had seen how the other teams had used different materials, so the good workspaces were a lot more heterogeneous in their construction. One team devoted lots of time to writing down the characteristics of their environments. Not surprisingly their models were the least-well realised. An object lesson in the perils of Big Design Up Front.
This session vindicated my decision to take a day's leave to attend the conference. "Logo, Plasticine and Playmobil? And you're trying to say you're working? Get outta here!"
Key lesson: developers want to be free range
This tutorial was an attempt by David Harvey (Sibelius Software) and Peter Marks (indie) to persuade us that JavaScript is a proper richly-featured programming language, and not just a mechanism for undermining the robustness and security of web sites. I'm not sure they entirely succeeded. It didn't take long to discover some quirks in the language. For instance how JavaScript doesn't seem to be consistent in how it evaluates empty or undefined things.
JavaScript is an embedded language. It has no I/O routines of its own and a very small core library. It inherits most of its capabilities from the environment it runs in, which is part of the reason it has such a poor press. We normally come across it in browsers, which are Teh Suck as programming platforms.
JavaScript rarely raises exceptions. For instance strings are immutable, but we can assign to a string without an exception being raised (the assignment is just ignored). Another example: dividing 1 by zero returns
Key lesson: JavaScript - it's not just for irritating pop ups.
The last session I attended was a simulation run by Mark Delgarno (Acumen Software). Again we were in teams. The point of the game was to develop a range of mobile telephones. Marketing had provided us with a list of models, with mandatory and optional features and development costs. Each team started with the same pot of money. The challenge was to decide which features we would develop for a specific product, which we develop as reusable components and which we wouldn't bother with at all. The game was played over two rounds, with our revenue from the first round's models funding working on the second round's new models. Part of the fun was that we only knew the specs for the first three models. So we could hazard guesses about which features would be useful in the second round but we couldn't be sure.
Our team (Yodafone) spent a lot of time discussing the merits of developing Java as a reusable component in the first round, because the marketing brief hinted that it would be on increasing importance in the second round models. However, of the first round models, only one could use Java, which meant a return of a $2m on an outlay of $10m. So we decided instead to develop a reusable SMS component and a product-specific monochrome display for the starter model. We were the only team to bother with the entry-level model (I blame Idiot Toys). But our strategy paid off because Yodafone won the first round which meant we had more money than the others to spend in the second round.
When we got to see the next three models we had to develop a Java component, because it was mandatory for one of the models. However it was also a lucrative optional feature for the other two. So developing it as a reusable component in the second round still generated a profit. Building it earlier would have cost too much money without generating compensating revenue, whereas the reusable SMS component paid for itself in the first round and made lots of money in the second round too. The upshot was Yodafone actually increased its lead at the end of the game. Win or not win, there is no try.
Obviously this simulation is not very realistic. In real life it is often difficult to assign costs and predict returns in such a clear cut fashion. But it was a pointed lesson in making the best of constrained resources. I think something like this game would be helpful as a warming-up exercise to play with users at the start of a requirements workshop.
Key lesson: YAGNI rules in even the unlikeliest of places
Overall I found this to be a very invigorating day. I'll be honest and say that not much of it will be immediately relevant to me in my day job, but the MiniSPA experience gives me some lessons for me as chair of the UKOUG Dvelopment Engineering SIG.
With the UKOUG the rooms always have serried ranks of chairs facing a screen. By contrast the SPA rooms are setup on the presumption of interactivity, with six chairs arranged around smallish tables. In the UKOUG we ask every presenter for their PowerPoint before the day, so we can print them out and put them in the delegates' packs. The feedback form even includes a question about the quality of the presenter's slides. At the SPA only one of the three sessions I attended featured any PowerPoint at all, and that was just to set the scene. The session chairs often weren't presenting at all; rather they were acting as facilitators.
The other thing was that the sessions were about a variety of things. In the UKOUG we tend to have presentations about Oracle's product sets. So it's usually a cookbook format: how to tune a query, how to code a drop down list in JSF, how to call a web service. It's all good, useful stuff which people need to know but it does rather tend to induce a passive receptivity in the audience. By contrast, these SPA sessions tended to deal with practices, and in particular practice improvement. The games and exercises weren't a gimmick: active engagement with the topics stimulated creative thinking, which is the start of the improvement process.
So the challenge for me is to inject some of this excitement into the UKOUG or at least the DE SIG.
In his introduction to the day, the SPA chair David Harvey said that developing software was the third most fun thing we could do with other people. I never did manage to ask him what the second thing was....
The opening session was a think tank. We were divided into teams and each team had to complete the following sentence in no more than ten words:
"Hey, I hear your business depends on delivering software. Well the most important thing about software development is ..."
Each team had to agree on its own phrase; then everybody voted on the phrase they liked the best. The secret of these things is to come up with something snappy and comprehensible. One team came up with a suggestion which had three clauses and used bullet points. That is a dead loss. You can't buttonhole somebody in the corridor and then ask them to wait whilst you boot your laptop and fire up PowerPoint. Here are a few of the final sentences.
- If it's any good, software lasts a long time.
- It encodes people's knowledge of the business to provide value.
- Get the best project manager you can.
- It's about people not computers.
That last slogan was the one for which most people voted, thus proving that people repsond to the clarity and focus which abstraction provides.
Designing Collaborative Workspaces
Mike Hunt (Mandu Ltd) led this workshop. Working in teams we had to build models of workspaces out of art card, Lego, Plasticine, Playmobil and various other craft materials. In the first round we had to build a bad working environment, then in the second round we had to build a good workspace. Although each team had a different scenario, the various models had certain common traits. The bad environments all tended to be cramped with people working in fenced-off isolation and with inadequate space for intra-team communication. Fans and other symptoms of poor air-condition featured a lot. The good workspaces were all spacious, with different rooms for different work modes. Bespoke desks and lots of whiteboards were common, and fresh fruit and/or baked goods were provided.
The striking thing was how much closer to real life the cartoon bad environments were. Most of the laughs came from recognition. The good environments on the other hand were largely wish fulfillment, and not just the ready availability of pastries. Floor space is expensive, particularly in London, and I doubt whether most companies would be prepared to devote so much square footage to pamper the developers. It is also unlikely that minions would be given so control over their own working environments. I was also amused to see that I had collaborated in designing an office which was basically open plan. I currently work in an open plan office (albeit cramped), and it can be very hard to concentrate. Sometimes a walled off cubicle seems a very attractive notion,
One interesting aspect of the process was how each team used the materials provided. In the first round we all tended to use the stuff closest to hand. The team with the Plasticine on its table had lots of blobs. Another team had been very creative with card. My team had the Lego so our office was largely built out of plastic bricks. However in the second round we had seen how the other teams had used different materials, so the good workspaces were a lot more heterogeneous in their construction. One team devoted lots of time to writing down the characteristics of their environments. Not surprisingly their models were the least-well realised. An object lesson in the perils of Big Design Up Front.
This session vindicated my decision to take a day's leave to attend the conference. "Logo, Plasticine and Playmobil? And you're trying to say you're working? Get outta here!"
Key lesson: developers want to be free range
Serious JavaScript
This tutorial was an attempt by David Harvey (Sibelius Software) and Peter Marks (indie) to persuade us that JavaScript is a proper richly-featured programming language, and not just a mechanism for undermining the robustness and security of web sites. I'm not sure they entirely succeeded. It didn't take long to discover some quirks in the language. For instance how JavaScript doesn't seem to be consistent in how it evaluates empty or undefined things.
JavaScript is an embedded language. It has no I/O routines of its own and a very small core library. It inherits most of its capabilities from the environment it runs in, which is part of the reason it has such a poor press. We normally come across it in browsers, which are Teh Suck as programming platforms.
JavaScript rarely raises exceptions. For instance strings are immutable, but we can assign to a string without an exception being raised (the assignment is just ignored). Another example: dividing 1 by zero returns
infinity, a magic value like undefined or NaN. I suspect this tolerance of wrong code explains why so many JS enabled web-pages seem to hurl.Key lesson: JavaScript - it's not just for irritating pop ups.
The Scoping Game
The last session I attended was a simulation run by Mark Delgarno (Acumen Software). Again we were in teams. The point of the game was to develop a range of mobile telephones. Marketing had provided us with a list of models, with mandatory and optional features and development costs. Each team started with the same pot of money. The challenge was to decide which features we would develop for a specific product, which we develop as reusable components and which we wouldn't bother with at all. The game was played over two rounds, with our revenue from the first round's models funding working on the second round's new models. Part of the fun was that we only knew the specs for the first three models. So we could hazard guesses about which features would be useful in the second round but we couldn't be sure.
Our team (Yodafone) spent a lot of time discussing the merits of developing Java as a reusable component in the first round, because the marketing brief hinted that it would be on increasing importance in the second round models. However, of the first round models, only one could use Java, which meant a return of a $2m on an outlay of $10m. So we decided instead to develop a reusable SMS component and a product-specific monochrome display for the starter model. We were the only team to bother with the entry-level model (I blame Idiot Toys). But our strategy paid off because Yodafone won the first round which meant we had more money than the others to spend in the second round.
When we got to see the next three models we had to develop a Java component, because it was mandatory for one of the models. However it was also a lucrative optional feature for the other two. So developing it as a reusable component in the second round still generated a profit. Building it earlier would have cost too much money without generating compensating revenue, whereas the reusable SMS component paid for itself in the first round and made lots of money in the second round too. The upshot was Yodafone actually increased its lead at the end of the game. Win or not win, there is no try.
Obviously this simulation is not very realistic. In real life it is often difficult to assign costs and predict returns in such a clear cut fashion. But it was a pointed lesson in making the best of constrained resources. I think something like this game would be helpful as a warming-up exercise to play with users at the start of a requirements workshop.
Key lesson: YAGNI rules in even the unlikeliest of places
Lessons for the UKOUG
Overall I found this to be a very invigorating day. I'll be honest and say that not much of it will be immediately relevant to me in my day job, but the MiniSPA experience gives me some lessons for me as chair of the UKOUG Dvelopment Engineering SIG.
With the UKOUG the rooms always have serried ranks of chairs facing a screen. By contrast the SPA rooms are setup on the presumption of interactivity, with six chairs arranged around smallish tables. In the UKOUG we ask every presenter for their PowerPoint before the day, so we can print them out and put them in the delegates' packs. The feedback form even includes a question about the quality of the presenter's slides. At the SPA only one of the three sessions I attended featured any PowerPoint at all, and that was just to set the scene. The session chairs often weren't presenting at all; rather they were acting as facilitators.
The other thing was that the sessions were about a variety of things. In the UKOUG we tend to have presentations about Oracle's product sets. So it's usually a cookbook format: how to tune a query, how to code a drop down list in JSF, how to call a web service. It's all good, useful stuff which people need to know but it does rather tend to induce a passive receptivity in the audience. By contrast, these SPA sessions tended to deal with practices, and in particular practice improvement. The games and exercises weren't a gimmick: active engagement with the topics stimulated creative thinking, which is the start of the improvement process.
So the challenge for me is to inject some of this excitement into the UKOUG or at least the DE SIG.
The Unanswered Question
In his introduction to the day, the SPA chair David Harvey said that developing software was the third most fun thing we could do with other people. I never did manage to ask him what the second thing was....
Tuesday, July 10, 2007
A fresh view on Oracle licencing
Oracle licencing is an arcane area, which has given us all much puzzlement and hilarity over the years. The abstracts submitted for the UKOUG conference included two papers attempting to explain Oracle's policies. Recently, Mark Brinstead has stirred up the Oracle blogosphere with his open letter on the licencing of the AWR and ASH packages. Personally I would like to see Partitioning brought into the Enterprise Edition but I'm not holding my breath.
Niall Litchfield has come up with an alternative insight into the relative value of Oracle licences. His article comments on Kevin Closson's analysis of a recent TPC-C benchmark which compared Oracle and MS SQL Server. Niall noted that the benchmark was undertaken using Oracle Standard Edition rather than Enterprise Edition. Kevin's conclusions related to value for money so Niall has done the maths for an EE licence instead, with interesting results. Not the least of which is:
One of my colleagues points out that IBM's Quad-Core servers qualify for Standard Edition licencing, which could push the SE price performance even further.
Niall Litchfield has come up with an alternative insight into the relative value of Oracle licences. His article comments on Kevin Closson's analysis of a recent TPC-C benchmark which compared Oracle and MS SQL Server. Niall noted that the benchmark was undertaken using Oracle Standard Edition rather than Enterprise Edition. Kevin's conclusions related to value for money so Niall has done the maths for an EE licence instead, with interesting results. Not the least of which is:
"One Oracle EE license equates to 32gb Ram and 400 disk drives in round numbers."
Update
One of my colleagues points out that IBM's Quad-Core servers qualify for Standard Edition licencing, which could push the SE price performance even further.
Don't only CONNECT
What's wrong with this code?
Of course, CONNECT is a role which (prior to 10g) has a standard set of privileges granted to it, including CREATE SESSION as well as CREATE TABLE, CREATE SEQUENCE, etc. So there is no need to also explicitly grant CREATE SESSION.
The use of CONNECT role has long been discouraged because lazy DBAs and system designers - present company excepted - tended to grant it by default rather than considering which system privileges a user actually needed. As it happens, the CONNECT set of privileges is wrong for both developer accounts and regular user accounts in almost all cases.
CONNECT is wrong for developers because it is incomplete - it doesn't include more recent privileges like CREATE TRIGGER or CREATE TYPE. Also, developers ought to have the privileges granted to their accounts directly, so that they can build stored procedures on those privileges. CONNECT is wrong for users because most users should not be creating tables or other objects. Users who are application owners and need to create database objects should be granted the necessary minimum of system privileges.
In 10g Oracle officially deprecated the CONNECT role. It now just has the CREATE SESSION privilege. This is sensible but I know from the OTN forums that it catches out some people. These are the people who haven't read the Upgrade docs. So reactively lazy DBAs will be protected from one small consequence of their (in)action. Proactively lazy DBAs will probably just write a script to create a replacement role and grant all the privileges to that instead. But at least they've chosen that path.
create user joe_soap identified by password
/
grant create session, connect to joe_soap
/
Of course, CONNECT is a role which (prior to 10g) has a standard set of privileges granted to it, including CREATE SESSION as well as CREATE TABLE, CREATE SEQUENCE, etc. So there is no need to also explicitly grant CREATE SESSION.
The use of CONNECT role has long been discouraged because lazy DBAs and system designers - present company excepted - tended to grant it by default rather than considering which system privileges a user actually needed. As it happens, the CONNECT set of privileges is wrong for both developer accounts and regular user accounts in almost all cases.
CONNECT is wrong for developers because it is incomplete - it doesn't include more recent privileges like CREATE TRIGGER or CREATE TYPE. Also, developers ought to have the privileges granted to their accounts directly, so that they can build stored procedures on those privileges. CONNECT is wrong for users because most users should not be creating tables or other objects. Users who are application owners and need to create database objects should be granted the necessary minimum of system privileges.
In 10g Oracle officially deprecated the CONNECT role. It now just has the CREATE SESSION privilege. This is sensible but I know from the OTN forums that it catches out some people. These are the people who haven't read the Upgrade docs. So reactively lazy DBAs will be protected from one small consequence of their (in)action. Proactively lazy DBAs will probably just write a script to create a replacement role and grant all the privileges to that instead. But at least they've chosen that path.
Friday, July 06, 2007
Marketing WTF
The Register reports on a bizarre Oracle marketing campaign: Alan Armstrong received a cardboard "laptop" full of shredded paper. It appears to be part of a marketing campaign for Oracle's Enterprise Content Management product. The trouble is, stunts like this rather invite waggish retorts about the cost of Oracle licences.
Wednesday, July 04, 2007
Papa's got a brand new BAAG
The BAAG Party (Battle Against Any Guess) is a recent initiative by Pythian's Alex Gorbachev. As the name suggests, its prime purpose is to promote the solving of database performance problems through evidence gathering and informed deduction rather than by guessing. After all, as Alex wrote in reply to an Oracle-L posting yesterday:
The thread in question had been started by somebody who had a query which had started running slowly after a a couple of months of satisfactory performance; furthermore the errant query requires a lot of CPU. What, asked Joe Armstrong-Champ, might be the cause? Several Oracle-L regulars replied with things which could cause excessive CPU consumption. Even Cary Milsap, who through his work with Hotsos might be regarded as the Pope of evidence-based tuning chipped in a few guesses of his own. As Alex pointed out, nobody replied with suggestions for investigating the problem in a methodical fashion.
So guessing is obviously innate. Why might that be? Well, Michael "Rands" Lopp, in a classic Rands In Repose article, has the answer:
Rands' argument is that in times of emergency we don't think. Rather, we flip through a mental rolodex of similar experiences and do whatever it was we did last time. In his words, "Panic is the mother of the path of least resistance". This is why the forums and listservers are the first resort of weak swimmers. They do not have a catalogue of previous experiences to draw on. So they simply post a half-baked question, probably with an generic subject - URGENT! PLZ HELP!!!!! - and a message usually lacking both useful information and any regard for mixed case. The galling thing is that we often respond to their panic with guesses, which is Teh Suck. There has to be a better way.
In his article, Rands proposes that we do are thinking at the most conducive time. Coming from a product perspective, his time for deep thinking is right after a major release, when the lessons are still fresh in everybody's mind and nobody is yet panicking about the next deliverable. Then is the time to think about what went wrong, how things could have been done better and to put a plan of action in place to avoid those things next time. Other jobs have other reflection points.
A couple of weeks back I got to hear Spike Jepson talk about his time as leader of the Red Arrows, the RAF's acrobatic display team. After every sortie (practice flight or real display) the team gathers for a debriefing. The team leader kicks off the session by going over his own mistakes. This creates an atmosphere in which the other team members can admit their bloomers without recrimination. This is crucial for the next step, which is to address the underlying issues and devise strategies for avoiding them next time.
The debriefing session finishes off with the team leader lobbing a problem at somebody - "Red two, we're coming out of a diagonal somerset into an obverse corkscrew over the heads of ten thousand people at Eastbourne when your engine catches fire. What do you do?" The team member then has to step through every action he would take to minimise the risks to himself, the rest of the team and the watching crowds, whilst not disrupting the display too much. In other words, rehearse the emergency procedure in a situation of calm, when no lives are at stake. Consequently, everybody knows what to do in a real emergency. Because when you're hurtling through the air at 400mph mere inches from several other airplanes there is no time for thinking, only for reacting.
Obviously we don't operate at such extremes. But the principle still holds true. We all have some form of mental toolkit which we bring to bear on tuning problems on our own databases. The most advanced will have a set of Perl utilities, tailored SQL scripts and an archive of benchmarks; the stragglers will have bookmarked some URLs on the Wait Event interface. The thing is, when we are faced with somebody else's problem it is quicker to toss out a few guesses than it is to properly engage with them. If your MO is predicated on having archived performance profiles which you have custom generated for your system it is hard to know where to start with somebody who hasn't even heard of Statspack. After all, this response is an e-mail or a forum post squeezed in during coffee time: nobody has the time to write a comprehensive explanation targeted to the original poster's specific problem.
This is where BAAG can help. It provides an obvious focal point for people who want to make things better and who have the required expertise. In the long run BAAG ought to be a compendium of resources and advice for the guess-prone. But as a starting point I think it should have a comprehensive (and comprehensible) list of questions we need to ask every poster with a performance issue. For instance
Once BAAG has such a list of questions we can respond to ill-formed posts simply by linking to it. Requiring the OP to answer these questions means we are forcing them to learn how to solve their own problems. Of course, it is incumbent on BAAG members to exercise willpower and not succumb to offering random suggestions.
After it, if it is truly the Battle Against Any Guess, then it doesn't just apply to when we ourselves are in shtook. We have to fight guesswork when we're troubleshooting other people's problems too.
"Why on earth do we still rely on guesswork in other troubleshooting tasks especially when more deterministic paths are available?"
The thread in question had been started by somebody who had a query which had started running slowly after a a couple of months of satisfactory performance; furthermore the errant query requires a lot of CPU. What, asked Joe Armstrong-Champ, might be the cause? Several Oracle-L regulars replied with things which could cause excessive CPU consumption. Even Cary Milsap, who through his work with Hotsos might be regarded as the Pope of evidence-based tuning chipped in a few guesses of his own. As Alex pointed out, nobody replied with suggestions for investigating the problem in a methodical fashion.
Thinking - we've heard of it
So guessing is obviously innate. Why might that be? Well, Michael "Rands" Lopp, in a classic Rands In Repose article, has the answer:
"Why can't you think when you're busy? Because you're not thinking.. you're reacting."
Rands' argument is that in times of emergency we don't think. Rather, we flip through a mental rolodex of similar experiences and do whatever it was we did last time. In his words, "Panic is the mother of the path of least resistance". This is why the forums and listservers are the first resort of weak swimmers. They do not have a catalogue of previous experiences to draw on. So they simply post a half-baked question, probably with an generic subject - URGENT! PLZ HELP!!!!! - and a message usually lacking both useful information and any regard for mixed case. The galling thing is that we often respond to their panic with guesses, which is Teh Suck. There has to be a better way.
In his article, Rands proposes that we do are thinking at the most conducive time. Coming from a product perspective, his time for deep thinking is right after a major release, when the lessons are still fresh in everybody's mind and nobody is yet panicking about the next deliverable. Then is the time to think about what went wrong, how things could have been done better and to put a plan of action in place to avoid those things next time. Other jobs have other reflection points.
Red Five, where are you?
A couple of weeks back I got to hear Spike Jepson talk about his time as leader of the Red Arrows, the RAF's acrobatic display team. After every sortie (practice flight or real display) the team gathers for a debriefing. The team leader kicks off the session by going over his own mistakes. This creates an atmosphere in which the other team members can admit their bloomers without recrimination. This is crucial for the next step, which is to address the underlying issues and devise strategies for avoiding them next time.
The debriefing session finishes off with the team leader lobbing a problem at somebody - "Red two, we're coming out of a diagonal somerset into an obverse corkscrew over the heads of ten thousand people at Eastbourne when your engine catches fire. What do you do?" The team member then has to step through every action he would take to minimise the risks to himself, the rest of the team and the watching crowds, whilst not disrupting the display too much. In other words, rehearse the emergency procedure in a situation of calm, when no lives are at stake. Consequently, everybody knows what to do in a real emergency. Because when you're hurtling through the air at 400mph mere inches from several other airplanes there is no time for thinking, only for reacting.
Obviously we don't operate at such extremes. But the principle still holds true. We all have some form of mental toolkit which we bring to bear on tuning problems on our own databases. The most advanced will have a set of Perl utilities, tailored SQL scripts and an archive of benchmarks; the stragglers will have bookmarked some URLs on the Wait Event interface. The thing is, when we are faced with somebody else's problem it is quicker to toss out a few guesses than it is to properly engage with them. If your MO is predicated on having archived performance profiles which you have custom generated for your system it is hard to know where to start with somebody who hasn't even heard of Statspack. After all, this response is an e-mail or a forum post squeezed in during coffee time: nobody has the time to write a comprehensive explanation targeted to the original poster's specific problem.
This is where BAAG can help. It provides an obvious focal point for people who want to make things better and who have the required expertise. In the long run BAAG ought to be a compendium of resources and advice for the guess-prone. But as a starting point I think it should have a comprehensive (and comprehensible) list of questions we need to ask every poster with a performance issue. For instance
- Which version of the database are you using?
- Which version of which operating system?
- What sort of application is it?
- Is this problem intermittent or reliably reproducible?
- Does this problem occur on all instances of your application or just in live?
- Did this query used to perform well? If so, what has changed?
- Do you have benchmarks (eg Statspack archives) for your system?
- Have you run 10046 and 10053 traces against this statement?
Once BAAG has such a list of questions we can respond to ill-formed posts simply by linking to it. Requiring the OP to answer these questions means we are forcing them to learn how to solve their own problems. Of course, it is incumbent on BAAG members to exercise willpower and not succumb to offering random suggestions.
After it, if it is truly the Battle Against Any Guess, then it doesn't just apply to when we ourselves are in shtook. We have to fight guesswork when we're troubleshooting other people's problems too.
Monday, July 02, 2007
Where does he find the time?
Jonathan Lewis has started answering questions in the OTN Forums. A normal person might think that running the Co-operative FAQ site, writing a blog, answering questions in the Oracle-L listserver and the comp.database.oracle.server forum, being a director of the UKOUG, writing award-winning books and holding down a proper job might be enough to fill all the hours of the day.
But not for Jonathan. He obviously has a few minutes left over which he wants to spend explaining the pointlessness of rebuilding indexes to newbies. Or perhaps he uses voice-recognition software to dictate articles in his sleep. Whatever, I guess us forum old lags will have to look to our game.
But not for Jonathan. He obviously has a few minutes left over which he wants to spend explaining the pointlessness of rebuilding indexes to newbies. Or perhaps he uses voice-recognition software to dictate articles in his sleep. Whatever, I guess us forum old lags will have to look to our game.
Subscribe to:
Posts (Atom)