Link: http://adhdocddba.blogspot.com/2010/01/why-being-agile-without-long-range.html

...Cary sent me another link recently - this one is a blog post by Jason Cohen titled 'Releasing early is not always good? Heresy!'. I like it because it captures what I see as the shortcomings of the Agile philosophy but I won't attempt to summarize this one. (I'd like to get a little sleep tonight) Instead I'll reference a few of my favorite points and let you read the original on your own.

Take a look at the section describing the general line of reasoning behind the Agile methodology and notice the difference in scale between the bullet points that follow. Think about it. While it is certainly possible to address bugs or rewrite an interface in a month, can you really address the root cause of a scalability problem in the same amount of time? Or fix a flawed architecture? These bullet items are not equal yet some Agile proponents treat them as if they are. Some components in a design need to be flexible and are expected to change many times over in the early design period. But replacing the architecture is a whole different magnitude from changing a screen or fixing a bug, and user feedback shouldn't be driving the architecture or data model anyway. Some components of an application should be transparent to the user and those components should be designed based on the long term goals of the application. True, you don't want to build the architecture now for future processing needs, but you can develop a plan for extensibility that will minimize disruption when those extensions are needed.

Perhaps the most important point Mr. Cohen makes is that great designs aren't built by consensus. If you get a group of people together with different viewpoints and skills, the result is likely to be average at best. Someone may suggest a truly groundbreaking idea but the more cautious team members are likely to push for less risk, while others will push for more resources in a different area and by the time all the compromises are added, the result is a lowest common denominator type of solution. (Congress attempting to pass the healthcare bill is a great example of design by committee with a less than optimal result) Great design needs to begin with a vision to provide a useful tool for the end user. There needs to be a plan with a desired destination and someone needs to make sure that the iterations keep the momentum moving in the right direction. Otherwise, you just end up nowhere very fast and that's not the kind of talk anyone wants to generate among their customers.

Posted by Robyn at 12:47 AM

Excerpt from article

Items against Agile

• The best ideas aren't built by consensus
• Apple doesn't ask customers what they want
• You're misinterpreting the 80/20 rule
• Mock-ups are faster than code iterations, without some of the drawbacks
• Releasing too early can ruin your reputation
• Ignoring architecture creates waste
• Untrue: "The worst thing you can do is built an unnecessary feature."
• Customers are notoriously bad at providing feedback

In the end, of course it's better to have more feedback than less, better to be more agile than less, and better to have technical debate with a successful product than a failed product. However, it's just not fair to present only one side of the argument!

Link: http://www.pythian.com/news/6891/more-fun-with-perl-and-inline-ifs/

My old arch-nemesis, the in-line if ($q = $q == $a ? $b : $c; ) reared its ugly little head again.

This time, it was in context of an web page that displayed some form values, something like this:

CGI::textfield({name => 'price_dollars',
width => '5',
value => ($mode eq 'Edit' ? $line_item[$count]->price_dollars() : '0') });
CGI::textfield({name => 'price_cents',
value => ($mode eq 'Edit' ? $line_item[$count]->price_cents(): '00' });

This carried on for 15 other fields on the form. So, we have 17 if else statements all checking to see if the form is in ‘Edit’ mode. If there were, say, ten line items on the form . . .  well no need to go any further, other than to say that is a whole lot of if statements.

While this does not take up much space, this multiplicity of ifs is not really necessary or even good, since to the compiler, an inline if and a bracketed one are the same. The inline is only a shorthand to make our code more readable.

We could of course just declare 17 scalars at each iteration, and then a use single if statment to set these scalars, like this . . . 

my $price_dollars = '0';
my $price_cents = '00';
if ($mode eq 'Edit') {
$price_dollars = $line_item[$count]->price_dollars();
$price_cents = $line_item[$count]->price_cents();
}

 . . . and then use them later on:

CGI::textfield({name => 'price_dollars',
width => '5',
value => $price_dollars}).
CGI::textfield({name => 'price_cents',
value => $price_cents });

Well at least this cuts down on the if statements, but now I have a whole bunch of single-use scalars hanging about–not very neat.

I could go for an Array or a Hash for my values, but as you might have already guessed, $line_item[$count] is an object of some form. So why not just use that?

So. At each iteration I check to see if I have a invalid line item . . . 

if (!$line_item[$count]) {
$line_item[$count] = Foo::Bar:LineItem->new();
}

 . . . and if I do, I simply create a new empty one, and then simply do this on my form:

CGI::textfield({name => 'price_dollars',
width => '5',
value => $line_item[$count]->price_dollars() });
CGI::textfield({name => 'price_cents',
value => $line_item[$count]->price_cents()});

Much simpler, and easier to read. Cheers!

Link: http://jonathanlewis.wordpress.com/2009/12/31/dbms_metadata/

The dbms_metadata package has a few convenient functions and procedures that allow you to generate the SQL to recreate parts of your database. The best-known function is probably dbms_metadata.get_ddl(), but every example of its use that I’ve seen on the Internet seems to use a “select from dual”, e.g.

select dbms_metadata.get_ddl('TABLE','T1','TEST_USER') from dual;

As a consequence of [...]

Link: http://ba6.us/node/150

If you are experimenting with gathering system statistics it might be helpful to archive your current settings and any intermediate settings you come up with along the way.

All the system stats info is held in the sys.aux_stats$ table. Since the format is a little wacky, I came up with the following table to hold stats and the following insert statement to populate it after every gathering of system stats.

read more

Link: http://rwijk.blogspot.com/2009/12/paper-about-grouping.html

In 2009 I have presented "Alles Over Groeperen" twice in the Netherlands and the English version "All About Grouping" also twice, once at the Oracle OpenWorld Unconference and once at UKOUG. If you haven't been able to visit one of these presentations, and you are interested in the subject, then you can catch up by reading the paper that I just finished.