Cool Verification

Here's a quickie to get the week started.  I stumbled across an interesting paper entitled Big Ball of Mud, by Brian Foote and Joseph Yoder (via Scott Rosenberg).  The paper discusses the most commonly deployed software architecture - the "big ball of mud".  Both of the above links are interesting reads.  Also, please check out my lastest post over on the Verilab blog discussing how to cast strings as enums. 

As an FYI... Joel Spolsky was in Austin this past Thursday.  I had the opportunity to meet him and sit in on his demo of the latest version of Fogbugz.  I've got some thoughts (and a picture or two) and hope to have that up soon (though I wasn't able to get the post written after 3-4 hours of work today so I'm not sure exactly when it will be done!). 

Finally, a couple of miscellaneous comments - first, starting around October 3 there were over 200 weekday subscribers to Cool Verification.  Second, this past July 24 was the 2nd anniversary of my first post on Cool Verification.  I'd like to thank everyone for sticking around, especially those of you who've been reading since the beginning.

Followers of the Scrum method of project management will typically start their day with a "stand-up meeting".  In short, this is a quick daily meeting (15 minutes or less) where the participants share the answers to the following questions with each other[1]:

• Was I able to fulfill what I committed to?
• What am I comfortable committing to today?
• What is obstructing me in meeting my commitments?

Jason Yip from Thoughtworks has written an excellent article entitled It's Not Just Standing Up: Patterns of Daily Stand-up Meetings on how to hold an effective daily stand-up meeting.   In it, he helps answer questions such as:

• "What is the purpose of the daily stand-up meeting?"
• "Who attends the daily stand-up?"
• "What do we talk about during the daily stand-up?"
• "When and where are the daily stand-ups held?"
• "How do we keep up the energy level of the daily stand-up?"
• "How do we encourage self-managing daily stand-ups?"

And,

• "Smells are about when things are going wrong"

Check it out!

[1] It's Not Just Standing Up: Patterns of Daily Stand-up Meetings,  Jason Yip, ThoughtWorks, Inc.

Just in case you've been living in a hole recently and hadn't heard about it, here's a link to the Google Testing Blog - where you can regularly download your very own updated installment of "Testing on the Toilet".  ToT is distributed to over 500 Google restrooms worldwide.  Hey, if it's good enough for Google, it must be good enough for the rest of us, right? :-).

Back in October, I received a mail from Mike Mintz asking if I'd like to take a look at a book he just wrote with Robert Ekendahl - "Hardware Verification with C++, A Practitioner's Handbook".  It sounded interesting enough, and I knew Mike had been working on a C++ verification library from a brief correspondence we had about a year ago, so I agreed to give it a read.  Around the same time, I read a post by Joel Spolsky (Book Review: Beyond Java) where he reviews a recent book by Bruce Tate (Beyond Java).  As luck would have it, at the same time all of this was going on I also had just upgraded to an unlimited subscription for O'Reilly's Safari Books Online, which meant I could immediately start reading "Beyond Java" (which I did).  Reading these three items got me thinking about the state of the art programming-wise in hardware verification versus state of the art in the software industry as a whole.

As chip design organizations grow and mature, they inevitably start to look at creating a global set of standard tools and methodologies.  There are several benefits to this approach, but there are some major drawbacks that need to be taken into account when developing a corporate strategy for design and verification.

These days it seems Python is all the rage.  I've been looking into ways to build dynamic web content using Plone - a Python-based Content Management System (CMS).  Since Plone is written in Python I've been attempting to familiarize myself with the language. I've also been trying to understand what the point was of knowing yet another way to write "Hello World".

Recently Joel Spolsky published an article entitled The Development Abstraction Layer where he describes the need for management to create an abstraction layer between developers and the infrastructure required to develop.  I also recently heard an interesting anecdote about how difficult it can be to get work done when you're held back by Byzantine organizational rules (ex. yes, we agree you need that XYZ to get your job done and it doesn't cost us anything to do it, but we can't do it because the proper procedure is to wait until...).  That got me thinking that in order to make Spolsky's abstraction layer concept work management and IT (to name two) need to behave as customer driven organizations instead of operations driven organizations.  In other words, help me do my job instead of telling the rule that prevents me from doing my job. 

I've been a big CVS fan for the last several years.  While I was at Intel (and later at ServerEngines) I used CVS to manage the source code for four reasonably sized cross-site development efforts.  Since I've been a consultant with Verilab I've been exposed to other systems including Clearcase and custom developed tools.  I've even come across some folks still using RCS!  Each system has it's pros and cons. 

A few weeks back I wrote about the Bugzilla appliance available for use with the VMware player. I've also recently written about potential uses for virtual machines in debugging hardware simulations.  In the first article I mentioned that one issue I had with the Bugzilla appliance was the inability to upgrade due to the fact that make and gcc are missing.  The folks over at VMware were keen to mention on their blog (search for the article entitled "Remaindered Links") that the smaller the virtual machine, the better.  In general I agree, but the reason I was so interested in the appliance in the first place was that I wanted to play around with Bugzilla and didn't want to spend the time configuring a server that could support the latest version.  I was more than willing to wait for the larger download to save myself the time of building up a VM from scratch.  Though now that they mention it, building up a machine from scratch really isn't a bad idea. 

The odds of me getting a Mac are increasing day by day.  Apple just announced the public Beta of Boot Camp - software to allow users to boot Microsoft Windows on a new Intel-based Mac.  I'll leave it to eWeek to fill in the rest of the details.  For me, it means the chance to get to have a shiny new Mac that works well with my iPod and provides a robust GUI layer on top of UNIX, and at the same time be able to sync my Microsoft Windows Mobile 2003-based smartphone with Outlook on Windows XP.  Nice.