SD West: Software Requirements: 10 Traps

Next up: Karl Wiegers talks about the 10 Traps of Software Requirements.  I plan to check out processimpact.com  for sample documents and spreadsheets (the requirements prioritization example spreadsheet sounds especially useful). 

Lots of good advice and pointers to resources in the talk.  He had somevaluable points regarding the different views of what a 'requirement'is to different stakeholders.  He presented a frameworkfor separation into business (why), user (what), and functional(high-level how) requirements, and how to categorize requirements intothis framework to help avoid confusion.  This becomes particularlyimportant when doing incremental development (which is what almosteverybody does):  It's OK to be fuzzy on some of the functionalrequirements before starting a project, but the business requirementshad better be very clear and solid.

Regarding change control boards, I asked how one can scale a CCB so itdoesn't become a bottleneck in a large program.  He said (interpretinga bit) that the way to scale a CCB is to identify policies so that youcan distribute responsibilities among CCBs -- only escalating changerequests up to a central CCB if its scope truly warrants it. 

The slightly depressing part about this talk was that I knew most ofthe solutions presented; however, none of them helped to solve thereally hard people problems that actually are the root cause ofmost requirements issues. 

On a side note, the wireless network stopped working for me during thistalk.  I started seeing packet round-trip times of >>1sec to reachwhat was supposedly our DNS server.  I think this highlights one of thenonfunctional requirements that should have been part of the requirements for the Santa Clara Convention Centernetwork:  When you build a wireless network for a convention center inthe middle of Silicon Valley, make sure that it can handle a fewthousand software engineers with laptops!

SD West: Understanding SOA

First up: Mike Rosen presented Understanding SOA. This talk was oriented very much towards enterprise developers who areconcerned with automation of business processes -- in some ways, adifferent world from where I operate most of the time.  Mike'sdefinition of SOA is pretty much what either Microsoft or IBM areoffering as platforms (.NET or J2EE plus SOAP).  Their main sellingpoint seems to be that once everything is exposed as web services,business analysts will be able to create and manage business processesby configuring services via graphical tools rather than by writing codeor even scripts.  (This syncs up with the presentation later on by DaveChappell.)  I am skeptical, but then again the problems thesedevelopers have are not my problems.

Quick takes: Mike stated that UDDI is not used much outside thecorporate firewall (my personal prediction: It never will be in itscurrent form.)  IBM and MSoft are repurposing existing applications,such as Tivoli, to help manage corporate web service networks.  I askedabout interoperability; monitoring and development tools based on oneof the "big two" platforms will have a difficult time interoperatingwith the other, though the web services themselves should be able torun on either platform with "some data mapping."

The most interesting statements: Dave Chappell mentioned after the talkthat things like security will only have shipping implementations in2006 and reliable messaging doesn't have a final spec yet.  Also, on atotally random tangent, I overheard someone behind me saying "XSLTmakes all those lies about 'you can do anything with pointy brackets'true!".

Inductive Blacklisting?

It looks like someone is trying out some type of comment spamon AOL Journals.  Or was; it sounds like a straightforward Termsof Service violation and I'd expect it to get yanked quickly. 

Fortunately, Journals provides a way to both delete a comment and blockthe commenter's user id (screen name) from future comments to thatJournal, which is handy in these situations.  But perhaps itdoesn't go far enough.  Perhaps there should be anauto-blacklisting feature:  If enough different peoplecomment-block a user id, perhaps it should be blocked from any furthercomments anywhere for a significant period of time.  It would atleast slow down the spammers.

Comment spam and nofollow

AOL Journals hasn't been hit by comment spam yet as far as I know, butI'm sure it's just a matter of time.  We're somewhat protectedbecause we don't allow anonymous comments, but commentspammers can get around that once they put some effort into it.
So AOL Journals plans to support the initiative to make at least one form ofcomment spam ineffective -- the rel="nofollow" attribute. The idea is that this would be honored by search engines such asGoogle, and would mean that these links wouldn't count towardsincreasing the page rank of the target.  So, this form of spamwould be rendered useless immediately.  Of course, other formswould still persist, but I say it's better to light a candle than cursethe darkness.   Or at least do both in parallel.

Virtuous cycle of creativity

The combination of blogs and aggregation is so powerful not justbecause these are complementary technologies in the obvious sense, butbecause they promote a 'virtuous cycle' that promotes the creationa andtransformation of information.   Of course this cycle isnothing new -- it's been around since forever, through the media ofbooks, libraries, universities, newspapers, et cetera -- but theblog/aggregation combination vastly speeds up the process and reducesthe transaction cost to effectively nothing.  Which makes the Long Tail of the information economy accessible.

That's why the announcement of My MSN RSS aggregation with feed search is interesting; a My MSN aggregator, plus MSN Spacesmeans Microsoft can leverage both sides.  So they could make itvery easy, for example, to subscribe to the RSS feeds for Spaces ownedby people who comment on your blog.  Or do any number of otherthings which increase the value of being an MSN member.  And,obviously, these tools still interoperate with the rest of theblogosphere (note that Spaces has had RSS feeds since launch).

Spam spam spam spam...

Back in June, aparently, the FTC said that a do-not-email list (likethe do-not-call list) would not work, and would generate more spambecause spammers would use it as a source of new email addresses. Though it's a bit late now, I have to wonder about the latterpoint.  Why not simply map each address into its MD5 checksumbefore storing it?

So foo@example.com would become "a0b6e8fd2367f5999b6b4e7e1ce9e2d2"which is useless for sending email.  However, spammers could use any of many available toolsto check for "hits" on their email lists, so it's still perfectlyusable for filtering out email addresses.  Of course it would alsotell spammers that they have a 'real' email address on their list, butonly if they already had it -- so I don't think that would be givingthem much information at all.

I still think the list would be useless because spammers would simplyignore it.  But it wouldn't generate new spam, and it would driveup the cost of spamming by making the threat of legal action a bit morepossible.

The Noosphere Just Got Closer

Of course it'll take several years, but Google's just announced project to digitize major university library collections means that the print-only "dark matter" of the noosphereis about to be mapped out and made available to anyone with an Internetconnection.  Well, at least the parts that have passed into thepublic domain; the rest will be indexed.

I'm clearly a geek -- my toes are tingling.