Guild Blogs

Darrell pointed me to this site on International Addresses and the complexities therein.

Darrell is using this from a testing point of view, but I have been fascinated for years about how to design an effective solution for US based systems that need to deal with foreign addresses. This will be a great resource.

Borland has released a version of Together Developer that integrates into VS.NET. Check out the screen casts. I'm thinking that Together combined with ReSharper from JetBrains could be one killer combination.

Scott Came turned me on to a UI concept called "Perspectives" that is well implemented in Eclipse. The project has some documentation and an overview that is an interesting read.

From the overview:

In the Eclipse Platform a Perspective determines the visible actions and views within a window. Perspectives also go well beyond this by providing mechanisms for task oriented interaction with resources in the Eclipse Platform, multi-tasking and information filtering. In this article the concepts behind perspectives are examined. The process for perspective definition, extension and instantiation will also be covered in detail with coding examples and sample scenarios.

A perspective is a visual container for a set of views and editors (parts). These parts exist wholly within the perspective and are not shared. A perspective is also like a page within a book. It exists within a window along with any number of other perspectives and, like a page within a book, only one perspective is visible at any time.

When I first looked at this it seemed very attractive and I thought it had the potential to solve some of my then client's issues surrounding "beginner" screens and "expert" screens.

My second thought was that this might provide a way to iterate the UI. The concept of iteratively developing a user interface has been the subject of much discussion on the XP list and has it's own mailing list.

One of the biggest issues of concern is UI churn if you have a fairly rapid release cycle. It seems that perspectives could alleviate this churn by adding new perspectives that support the new features of the release and only change or remove the pre-existing perspectives when absolutely necessary. Of course this introduces some other problems such as informing existing users about the new perspectives and how to start using them, but it seems manageable.

From the technical side my biggest concern is since perspectives are not aked into any UI framework that I'm aware of (besides Eclipse) my team would have to build the plumbing. Iterating into a perspectives framework could be challenging and selling the value to the product owner might take some doing.

Anyone out there doing something like this?

Jim Shore wrote about why he doesn't like Cruise Control. I agree to some extent with his points that the reason teams use it is to catch build errors and deal with "slow" builds. Having implemented both Draco.NET and CruiseControl.NET and toyed with FinalBuilder I am not overly impressed with any of them. My impression is that I spend way to much time fiddling the build server for the value added. I will say that I would still implement a build server for any team for the single reason that "people are fallible". People forget to commit related changes, or add files to CVS, run tests, etc. The build server never does.

Brian Marick has another great post. This time he talks about how to transition a team working on legacy code to a more agile approach.

March 2005 MEETING ANNOUNCEMENT

TOPIC: Agile Government...is it possible?

The next Portland XP Users Group meeting (http://xpdx.org ) will be on Tuesday, 8th March 2005. It will be held at the OGI School of Science & Engineering at OHSU, 20000 NW Walker Road, Beaverton, in room WCC 403 (upstairs above the cafe@OGI).

Mark Clerget & Jake Lawlor of the Consultants Guild will be leading a discussion on the topic of "Agile Government...is it possible?":

Have you heard someone say "Oh we tried Agile on a project and it didn't work" only to hear someone else say "Agile is the only process that I use and it works great"? So who is right? If you would like to learn the keys to ensuring successful adoption/implementation of Agile in the most challenging of environments, be sure to attend the March XPDX meeting. Join Mark Clerget as he shares his successful experience implementing Agile in the most unfamiliar of surroundings....Government!

Pizza and refreshments will be provided for the March meeting, but you will need to help bear the cost if you partake.

Please sign up at (url not available yet)!

DATE AND SCHEDULE

Tuesday, 8 March 2005 (second Tuesday of the month).
6:30 - 7:00 pm : Pizza + Socializing.
7:00 - 9:00 pm : Presentations and discussion. (Cold pizza?)
9:00 - whenever: Socializing at the Oak Hills Brewpub

LOCATION

Directions to the OGI campus can be found at http://www.ogi.edu/maps/. WCC 403 is in the building numbered 3 on that map. The socializing will continue after 9pm at the Oak Hills Brewpub.

Some of you may be rolling your eyes at this suggestion, but it's been bugging me for months and I finally figured out how to fix it.

For many moons I've been editing T-SQL stored procedures using VS.NET, but been annoyed because every time I when to the graphical query designer it didn't know anything about T-SQL variables (i.e. @MyVar). I could get around this by right-clicking the SQL pane and changing the property page. Very conveniently the designer deleted all your SQL when you do this so I always had to remember to copy my SQL change the property page and paste the SQL back in.

Turns out there is a setting in Tools: Options: Database Tools: Query/View Designer that will take care of it.

Scott Came will be participating in the proceedings of the Court Filing Technical Committee, focused on finalizing requirements for the upcoming version of the OASIS court filing standard.

Patrick Logan writesabout the debate regarding whether software development is a craft or engineering. He has an interesting spin in that what makes software seem "craft-like" is the informalities.

I think the "informality" of software makes it feel craft-like. If only we had more formalisms. Could be, but we'll always have "informalities". Every engineering effort, and every creative effort in general, involves many informal conversations.

The difference is perhaps software depends more on informal conversations than do many of the traditional engineering disciplines. The requirements in those disciplines are more formal. Most of software development is really requirements development. The interpretation of formal requirements is most easily expressed in software as tests and code that (correctly one hopes) runs those tests.

Ultimately Patrick says that communications is the key and that failed is a result of failed communication not lack of formalism.

Which still begs the question for me - what is it that we, the software development discipline, are envious of from the "other" engineering disciplines?

A teaser from Clarke's book. If you want to know what the secret ingredient is take a look at his Sticky Minds article.

Craig interrupted my thoughts, "It doesn't surprise me that you are in the mess you are in. My education and experience are in Quality and Lean thinking and it is obvious to me that when your industry embraced quality it embraced the wrong quality guru and it neglected the one vital secret ingredient that makes doing quality easy."

I sat up straight in my chair. "Secret ingredient?"

[via Clark Ching]