Agile 2009 is coming up fast, August 24th-28th in Chicago. If you are at all interested in agile development or improving your skills as a developer then this is a conference you should give serious thought to attending. If you are a developer then you can get some more details on what’s in the conference for developers.

One of my goals this year was do at least one presentation at a major conference. Towards that goal, I have proposed two sessions for the conference, a 3 hour coding clinic on BDD in .NET for the Developer Jam stage and a 90 minute tutorial for the New to Agile stage on how defining “Done” as a means of getting to working software.

In preparing the session proposals I tried to draw on what I had learnt in the teaching practicum class for my degree program in terms of outcome-driven learning, taking different learning styles into account, and thinking carefully about ways to engage the participants so that they can return to their work situation and apply immediately what they have learnt. Hopefully I achieved a certain measure of success with that. So far the reviews have been very positive. It will be a while before I find out if the sessions were accepted for the program.

Either way, I plan to offer the BDD clinic in Denver a couple of times over the Summer, so stay tuned for news on that.

Here are the proposals:

"Done" - Are We There Yet?

One of the core values expressed in the agile manifesto is “working software over comprehensive documentation” because working software is what delivers value to our customers. Agile development requires a sofware development team have working software ready to deploy at the end of each iteration. But accomplishing this can be harder than it seems, especially when first starting with agile. In this highly interactive session you will understand how a team definition of “Done” is necessary to making agile delivery possible, and what you can do to make it happen while avoiding the pitfalls.

Process/Mechanics

Introduction (10 mins)

I will introduce the basic concepts and give some examples of what happens when a team does not have a definition of “Done”. We will also take some time for collecting a backlog of questions and concerns the participants might have in regards to applying the session content in their situations.

Crafting a Definition of “Done”(70 mins)

This will be a very interactive session with a combination of teaching, discussion, Q&A, and group exercises. Participants should be prepared for lots of group work, movement, sticky notes, whiteboard sketches, handouts, and roleplaying.

Participants will be provided with sample definitions of “Done” from real development teams to use as a basis for discussion.

At a minimum, the following important questions will be covered:

• How would you define “Done” for your current team situation?
• What would your team need to change in the definition to have working software that can be released at the end of each iteration?
• What challenges would changing this definition present to the team?
• Where are the differences in “Done” criteria at the product backlog item, iteration and release levels?
• Who should be involved in defining the criteria for “Done”?
• How does testing fit into “Done” and how does it impact quality?
• What challenges might arise when deployment is included?
• How does “Done” relate to story size and velocity?
• What is the relationship between “Done” and user story acceptance criteria?
• How does being mindful of the criteria for “Done” factor into iteration planning, demonstrations, daily standup meetings, impediment backlog etc?
• What if we release a story that is “Done,” but then find a bug or the customer requests a change?

As groups we will roleplay and brainstorm definitions of “Done” for participants to demonstrate how this can be done in a real project team situation.

Final Review (10 mins)

This is where we do a retrospective of the overall learning experience and ensure that participants leave ready to apply what they have learnt in their own situations.

• Review learning outcomes and ensure that they were met.
• Ensure that all concerns and questions were addressed in the session.

Learning outcomes

• The participant will understand what a definition of “Done” is at the product backlog item, iteration and release levels
• The participant will understand what can happen when no definition of “Done” is in place
• The participant will be able to relate the definition of “Done” to planning, demonstrations, daily standup meetings, story size, acceptance criteria, velocity, product delivery, production releases, daily coding practices and other aspects of agile development.
• The participant will be able to work with their team to develop a meaningful, effective definition of “Done”

Introduction to Behaviour-Driven Development in .NET

Behavior Driven Development (BDD) is an agile software development technique that encourages collaboration between developers and customers to focus on the delivery of business value. Have fun learning how BDD can be implemented in .NET by combining testing frameworks such as NUnit, MSpec, and SpecUnit.NET with an isolation framework such as Rhino Mocks, with SOLID design principles, and with other agile practices such as continuous integration to increase the value of your code to your customers while also improving its design, readability and maintainability.

Process/Mechanics

Introduction (15 mins)

I will introduce BDD, its history, and how it relates to other practices such as Test-Driven Development and Domain-Driven Design. This will include my story of how I got started with BDD and some of the challenges (successes and failures) in applying it in my project work. We will also take some time for collecting a backlog of questions and concerns the participants might have in regards to applying BDD in their situations.

Problem Presentation (10 mins)

All the coding will be done in the context of extending and refactoring a simple Winforms application to meet a specific business situation. I will act as the Product Owner and domain expert, and explain the business context, application scenario, and product backlog for the application.

Coding Exercises (140 mins)

There will be three ~40 minute focused coding exercises, each of which will be treated like a mini-iteration.

• Students will implement one or more items on the Product Backlog using BDD for each coding exercise, which will include conversations with me as the domain expert on what is needed to implement the item correctly.
• I will explain the underlying principles, problem being solved and demonstrate the practice as part of introducing each coding exercise. Students will receive labs written in Hands on Lab format taking them through each of the coding exercises.
• I will actively engage the students and facilitate the coding exercises and learning throughout the clinic. Students will be encouraged to pair and learn together, sharing their results with other attendees as progress is made.
• Each coding exercise will end with students demonstrating the code they developed, a short class discussion of the challenges encountered, and a review of what was learnt and how it can be applied to student situations.
• Students will be provided with a starting solution, a final solution, and an exercise manual for each exercise, along with copies of the solutions, frameworks and tools needed for the exercises.

Students will need to bring their own laptops with Visual Studio 2008 development environments.

Final Review/Q&A (15 mins)

This is where we do a retrospective of the overall learning experience and ensure that students leave ready to apply what they have learnt in their own situations.

• Review learning outcomes and ensure that they were met.
• Ensure that all concerns and questions were addressed in the clinic.

Learning outcomes

• The student will know and understand the basics of Behaviour-Driven Development (BDD), including its major benefits and challenges, and how it relates to other practices such as TDD and DDD.
• The student will know what .NET tools and frameworks support BDD, and understand how they compare in features, utility and approach.
• The student will know what resources are available for supporting a developer’s future growth in adopting BDD as a coding discipline.
• The student will be able to begin applying BDD to effectively design classes, class behaviour and class collaborations for cleaner code.
• The student will be able to integrate and apply various .NET tools and frameworks to BDD as a coding discipline.
• The student will be able to engage their customers and domain experts more effectively in order to deliver value through their coding.

I took my first online C# test yesterday. HR are apparently recommending that we use it as part of our developer hiring process.

I got 76%. The world average is apparently 74%, and I assume that most people taking this test are coding in C# for most of every working day. For the past year I have not coded more than an hour a day on average, yet I scored above average without any prior preparation or study. I know that if I had taken an hour or two to brush up on Datasets, XML serialization, custom controls and File IO I would easily have got well above the 90th percentile.

And that’s the key point, there is nothing that I did not know on that test that I could not find out in less than a minute using Visual Studio or Google.

So I don't have a lot of respect for these kinds of tests. They fail to test real programming or design ability. I would not recommend that any company spend money on this type of testing approach. These test at the lowest level of Bloom's taxonomy and thus have only limited value. It is regurgitation of memorized syntactical facts, and little more than that.

I view this as akin to evaluating a carpenter based on whether he can identify various species of trees.

There was very little on that test that Visual Studio won't give you with Intellisense, so I don't see the value in what is being tested. I guess it does set a minimum bar; anyone that fails this test should not be hired since they have no significant knowledge of C# at all. Case in point, there is at least one recent case of a 8 year old child passing one of these types of exams for the MCP certification. A remarkable child for sure, but I would not recommend hiring her as a developer for your team because she has the MCP certification. In fact, that certification says nothing about her ability to write code.

As many others have already noted, programming exercises (such as Jeff’s now infamous FizzBuzz or a coding and refactoring exercise that I have used in hiring) are a far more cost-effective and accurate means of determining programming skill. They tend to test at higher levels of Bloom's taxonomy and provide a clearer window into the mind of the developer being evaluated.

I wanted to find a more flexible implementation of the VS 2008 class designer. Out of the box the designer does not support basic operations like easy pan/zoom, HTML export, grouping and some other niceties that would make it actually worth using.

I stumbled across the PowerToys for the Class Designer and Distributed System Designer. After downloading it and looking through it there are the basic features that I wanted. I don’t want to use it for class design. Instead, I am really after a tool that would enable me to quickly produce a UML class diagram of part of our domain so I could print it out and stick it up for the team’s reference. We have this for the data schema from SS2005 and it is tremendously helpful.

From the Project Description at CodePlex

This set of add-ins augments existing functionality in the Visual Studio Class Designer and the Distributed Systems Designers. It now supports Visual Studio 2005, Visual Studio 2008. The Design Tools Enhancements add-in provides a common set of features that can be used by both the Class Designer and the Distributed System Designers, such as pan/zoom window and rich formatting commands.

The Class Designer Enhancements add-in provides additional functionality for the Visual Studio Class Designer, such as HTML export and nested type creation commands. This download includes all necessary source code and a Visual Studio project template for creating your own add-ins for the Visual Studio designers.

The Class Designer is a developer productivity tool available in Visual Studio Standard Edition and above, which allows developers to easily visualize, design, refactor, and document their code.

The Distributed System Designers enable software architects, operations managers, and developers to visually design service-oriented solutions and validate them at design time against their operational environments. The Distributed System Designers are a core component of Visual Studio Team Edition for Software Architects and the Visual Studio Team System.

After clicking on Download Now I get ModelingPowerToysForVS2008.zip which extracts to an MSI and the source code for the Add-In.

Running the MSI gives me a new menu next time I run VS2008:

Here is the Class Designer being used on its own source code:

Zoom feature works well:

Class details:

Adding a comment:

Brian points out that you can show the associations between classes inside the Class Designer. To do this, simply right-click on a class attribute or a property, then click on Show as Association or Show as Collection Association, depending on the type. Here are the results of doing Show as Association on the TransactionName property of AddDerivedClass:

I really like the nice navigation window on the bottom right of the screen. Reminds me of one of my favorite Photoshop features:

Showing class details:

So, in order to get to a diagram of the domain classes, one thing I really would like to be able to do in such a tool is grouping and color coding by modules/namespaces. Since we have a data schema diagram from Sql Server that has various logical groups of tables color coded and grouped together it would be ideal to do the same with the classes. I’m just not sure how to do that, if it is even possible with this tool. I think I need to experiment some more to see. And I’m really not sure yet what the Distributed System Designer part of this Add-In is.

From Ars Technica: Open source Mono framework brings C# to iPhone and Wii

How Mono makes it possible to develop applications for the iPhone using .NET:

Mono, an open source implementation of .NET runtime, is bringing Microsoft's development technologies to some unexpected places, including the iPhone, Android, and the Wii.

According to Novell's lead Mono developer, Miguel de Icaza, several applications in Apple's App Store are powered by Mono. This might come as a bit of a surprise to those familiar with Apple's highly restrictive application inclusion policies, because the company strictly prohibits developers from using interpreted languages and third-party runtime environments—a constraint that largely rules out technologies like .NET and Java.

Here is the list of around 40 Apps Miguel found that people said were available from the AppStore that are powered by Mono (based on the comment thread here). He also mentions My Animal Center, a German game for the Wii that is heavily coded in C# using Unity and Mono.  If only I had a Wii so I could try it out (hint…hint…).

Games:

• FlashBang Studios's RaptorCopter
• Downhill Bowling (5 stars), (screenshots and video).
• Billiards.
• SpacePig.
• Age of Curling.
• Dusktreaders.
• X-Razer.
• Tapball (video).
• InvinciBall (video).
• SlidePop.
• FuguMaze.
• Monkey Diving (video).
• Ball-X (with the dash in the middle, or you wont find it).
• FuguTilt.
• Pizza Dash (you deliver pizzas in a car).
• Debris (you do controlled demolitions).
• Trash it!
• Rotunda.
• Asteroid Strike.
• Crazy Snowboard (and 2.0).
• Bubble Bang (video).
• iStronaut Willy.
• Bounce Pop.
• Labyrinth 3D.
• FuguBall.
• SpaceRace (video).
• iDrone.
• Mars Explorer.

Word games:

• Christmas spell.
• Alpha Blocks: Brain Freeze.

Not really games, but cool hacks:

• Moobox 3D, cute!
• Widget Monkey.
• Butterflies.
• Dice 3D.
• Night Divine.
• Rainbow Day.
• Zen of Snow and Zen of Snow 2.
• Jingle Bells.
• ArtiFISHal Life (3D Aquarium).
• Leaves.
• iFeathers.
• Bobblehead Santa.

But how is it done? The trick is to move past the CIL via static compilation directly to native code.

Static compilation is the special sauce that makes it possible for Mono to run on the iPhone. Mono allows developers to use ahead-of-time (AOT) compilation, which converts .NET's common intermediate language (CIL) directly to native code at compile time. This means that the application doesn't have to use just-in-time (JIT) compilation to generate the native code at runtime. One of the apparent limitations of this approach is that generics and dynamically-generated code are currently not supported when AOT compilation is used.

There are also a few other tricks and Mono features that developers can use to reduce the size of Mono executables and assemblies for deployment in mobile environments. You can use the Mono linker to shrink the library size, you can omit the JIT and code generation engines from the executables, and you can strip out CIL instructions from the assemblies.

The key that turns the iPhone lock for .NET here is Unity, a third-party commercial programming framework developed by a Denmark-based company for 3D game development built on Mono. Unity supports several platforms, including iPhone and Wii, and comes with its own built-in Mono cross-compilation environment.

Unity has Indie licenses available for $199 USD and Pro for $1,499. In addition to these, the iPhone basic support license runs at $399. More information on the differences between Indie and Pro licenses and Unity iPhone publishing can be found here.

The iPhone isn't the only hot handset to catch Mono. A developer has experimentally ported the Mono runtime to the Android-based T-Mobile G1. Although this port is only an experimental proof of concept and won't be used to deploy applications on the platform any time soon, it has a lot of potential and performs well against Google's Dalvik runtime in some preliminary benchmarks.

Mono's robust portability and advanced support for features like static compilation are enabling developers to use it in innovative ways that wouldn't be possible with Microsoft's .NET implementation. This demonstrates the value and flexibility inherent in an open implementation.

Looks like exciting times ahead for .NET and the iPhone because of Mono. .NET developers can now venture into iPhone development with the tools they know and love.

I noticed today that software I worked on 15 years ago in Fortran and C is still around and being actively put to good use.

I did extensive work on parts of the Geotechnical module (love those search ellipsiods!) and wrote the initial Groundwater Modelling interface to Aquifem-n so that the models could be manipulated and displayed inside the 3D modelling environment. Working for Maptek was my first job after completing my graduate work at Curtin University. I started there in 1990 and stayed for five good years. They were a great company to work for and I have many fond memories from my time there. I don’t miss coding in C and Fortran (I prefer not to have to hurt my head with memory management concerns too much these days), but I am still good friends with the people I worked with at Maptek (who have all since moved on as well).

I’m sure that anyone who has worked in software for a long time would found themself in a similar situation of having software they developed still out there in the wild many years later. Hopefully you can also feel gratified and proud that something you worked on is still delivering value.

Are you designing software with the long term in view? Maybe a key question to ask yourself is “How will I feel in 15 years time about the software I am writing today?” Are you hacking together something, quick and dirty, that will still be causing developers and customers to curse your name more than a decade from now? Or are you building in quality that will last, and seeking to leave a positive legacy for the future of the software and its customers?

Studies of software maintainers that have shown that approximately 50% of their time is spent in the process of understanding the code that they are to maintain, the estimated annual software maintenance cost in USA was more than $70 billion in the early 90’s, and in 2000 there were already about 250 billion lines of source code being maintained.

Neither you nor the company that employs you can justify not baking in clean code from the very start and keeping it that way. Anything else is just shortsighted and irresponsible.

I squirm when I consider these things and cast my mind back to some of the development work I have done in the past. But I don’t think that excuses us from holding ourselves to a high standard and taking the long view with our work. Build quality in.

iPhone version 2.1 contains many bug fixes and improvements, including the following:
•  decrease in call set-up failures and call drops
•  significantly improved battery life for most users
•  dramatically reduced time to backup to iTunes
•  improved email reliability, notably fetching email from POP and Exchange accounts
•  faster installation of 3rd party applications
•  fixed bugs causing hangs and crashes if you have lots of 3rd party applications
•  improved performance in text messaging
•  faster loading and searching of contacts
•  improved accuracy of the 3G signal strength display
•  repeat alert up to two additional times for incoming text messages
•  option to wipe data after ten failed passcode attempts
•  Genius playlist creation

Harvard Business Review have an article by Ed Catmull on how Pixar consistently continues to produce both technical and artistic breakthroughs. Go grab it. Right now.

Pixar is one of the companies that I have watched and admired for many years, and now my children are able to share the joy of delighting in the wonder that is a Pixar movie. Ever since I first heard John Lasseter speak at a computer graphics conference in Melbourne in 1990, I have been amazed at how he and his company have been able to push the boundaries of what is possible both in their storytelling and technically.

As Ed says:

...we as executives have to resist our natural tendency to avoid or minimize risks, which, of course, is much easier said than done. In the movie business and plenty of others, this instinct leads executives to choose to copy successes rather than try to create something brand-new. That’s why you see so many movies that are so much alike. It also explains why a lot of films aren’t very good. If you want to be original, you have to accept the uncertainty, even when it’s uncomfortable, and have the capability to recover when your organization takes a big risk and fails. What’s the key to being able to recover? Talented people!

But beyond finding the right people, it also involves nurturing an environment where those people can collaborate to produce the type of creativity and effectiveness that is needed. I submit that this is true in software development also:

What’s equally tough, of course, is getting talented people to work effectively with one another. That takes trust and respect, which we as managers can’t mandate; they must be earned over time. What we can do is construct an environment that nurtures trusting and respectful relationships and unleashes everyone’s creativity. If we get that right, the result is a vibrant community where talented people are loyal to one another and their collective work, everyone feels that they are part of something extraordinary, and their passion and accomplishments make the community a magnet for talented people coming out of schools or working at other places.

Should be done by the time I get home tonight...then get Infragistics, Rhino Mocks 3.5, and ReSharper 4 FTW!

But wait! Maybe sooner (and I won't be here to appreciate it!)...my Comcast pipe bandwidth at home is sure in flux right now...

Now that I intend to be starting to put code snippets in my postings, I wanted to find a decent syntax highlighter that works well for C#. I tried this one and it crashes WLW, so I would not recommend it. I could not get it to work.

But the Syntax Highlighter for Windows Live Writer project on CodePlex works like a treat. Install it by just copying the dll's to C:\Program Files\Windows Live\Writer\Plugins.

Here is the window I see after I select Insert->Syntax Highlighted Text:

Just click Insert and the plugin inserts the following:

        public void SetAnalyticsTicketTypeViewDisplay()
        {
            splitContainer.SplitterDistance = 400;
            dealManagerLabel.Visible = false;
            dealManagerComboBox.Visible = false;

            buyClientNameLabel.Visible = false;
            buyClientContactLabel.Visible = false;
            buyClientComboBox.Visible = false;
            buyContactComboBox.Visible = false;

            sellClientNameLabel.Text = "Client:";
            sellClientContactLabel.Text = "Contact:";
            sellClientNameLabel.Location = buyClientNameLabel.Location;
            sellClientContactLabel.Location = buyClientContactLabel.Location;
            sellClientComboBox.Location = buyClientComboBox.Location;
            sellContactComboBox.Location = buyContactComboBox.Location;

            completionDateLabel.Text = "Completion Date:";

            productTypeLabel.Visible = true;
            productTypeMonthDateEditor.Visible = true;

            wholeLoanGroupBox.Visible = false;
        }

Very nice! Now to start the VS2008 download from MSDN...

I am now registered for the Agile 2008 conference in Toronto from August 4-8.

I am really looking forward to it. The sessions look awesome, and I fully expect the hallway conversations to be a highlight.

Plus I hope to meet and personally learn from many of the people that have been so influential in my learning agile development in the last two years. People like Joshua Kerievsky, Mike Cohn, Allan Shalloway, Bill Wake, Mary Poppendieck, Rebecca Wirfs-Brock, Rachel Davies, Diana Larsen and Esther Derby, James Newkirk, Brad Wilson, Dan North, Uncle Bob Martin, Ron Jeffries, Scott Ambler, Gerard Meszaros, James Shore, Michael Feathers, Ken Judy, Jeff Sutherland, Ward Cunningham, and, last but not least, my CSM trainer Hubert Smits.

Looking through the program, I am sure that the difficult thing is going to be choosing which of the many excellent sessions to attend.

Anyone else going that would be interested in meeting up there?

Nice to see that Tim Mallalieu, the PM for the Entity Framework team is blogging. See especially his thoughtful response to the ADO.NET Entity Framework Vote of No Confidence.

For some history on the vote of no confidence, see the recap by JDN. Roger Jennings has been following the controversy for a while, he has some detailed background in an older posting on the lack of persistence ignorance in the EF and a good summary of the current state of play with the EF (including an insightful comment dialogue with Jeremy Miller and Scott Bellware).

I echo the concerns expressed in the vote of no confidence, but it seems to me that the EF team is making a concerted effort to move in a more constructive direction, as indicated by the newly formed EF DDD-luminaries advisory council, Tim's new visibility on his blog and a brand-new EF v2.0 Design blog. Here is what the design blog has to say abut things the EF team is trying to do in the version 2 release as part of their new transparency in the design process:

• Persistence Ignorance : We are looking at ways to introduce a full POCO solution for state management and interaction with the ObjectContext.
• N-Tier Support : Today we support Data Contract serialization of entities or exposing entities via Astoria, in V2 we would like to expand to a DataSet like experience where one can remote graphs and changes to the graphs across the wire using standard WCF services.
• Code-First : We want to enable a convention based, code only experience with EF wherein one may start with classes and opt-in to database generation and deployment. We expect that we would provide attributes and external mapping capabilities for people who wanted something beyond the convention based mapping.
• TDD Scenarios: With the introduction of POCO classes some of the TDD scenarios get a lot easier, and we are looking at incorporating some other asks to better fill out the scenario, such as making our ObjectQuery<T> and other generated members of our context and classes virtual.
• FK's : Today we support bi-directional relationships, and we are looking at introducing model concepts to facilitate the definition of FK like experiences in the model or in one's POCO classes.
• Lazy Loading: Today we support explicit lazy loading (calling .Load), and we are looking at various options around LoadOptions as well as outright implicit lazy loading.
• Query Tree Re-Writing: This allows framework develolpers to contextualy, vertically and horizontally filter query results.
• ...

I have been encouraged by how the ASP.NET MVC team has been so open about their design and this seems to have led to a healthy groundswell of support and constructive criticism from the .Net community. Hopefully we will see this new transparency for the ADO.NET EF team result in the same type of thing. Already there is some really healthy dialog going on in the comments of the design blog.

Please update your RSS feed for this blog to point to http://feeds.feedburner.com/virtualgenius.

This is my first step in my plan to move this blog off Live Spaces as soon as I can. Which is likely to be sometime in the next few months (as time permits). I want to move onto something I have more control over (but without the hassle of hosting it myself), especially in making it easier for people to leave comments. Suggestions? DasBlog? SubText? Something else?

Sometimes when the pressure mounts on an agile project, the project leaders (or team) may be tempted to ditch some of the elements that make the process agile in the first place. It seems that the iteration retrospective is often the first to go. After all, why spend that time meeting when work could be getting done?

To celebrate that notion, I have compiled a quick list of possible reasons why a team lead (or even the team itself) might want to kill an iteration retrospective (any others that I have missed???).

"Top 10" reasons heard for canceling a retrospective:

1. MEETING FATIGUE...We don't have time for yet ... another ... meeting.
2. BUGS...We need this time to work on bugs in the system.  We would rather have the team spend that hour finishing up bugs for the week.
3. MONEY...It costs too much to have the entire team spend an hour just navel-gazing.
4. TIME...It takes too long.
5. BORING...The retrospective meetings are boring.
6. DISTRIBUTED TEAM...We have a distributed team, and not everyone gets to participate.
7. DEVELOPER NEGLECT...It is too focused on the business, and not everyone gets to participate..
8. BUSINESS NEGLECT...It is too focused on the developers, and not everyone gets to participate..
9. TEAM TOO SMALL...Our team is so small (we only have [X] team members), we don't need it.
10. TEAM TOO BIG...Our team is so large (we have [X] team members!), we can't possibly make it work.

Here is what Ken Schwaber has to say about the benefit of doing a Sprint Retrospective...

Scrum is a process of self-improvement and process improvement – at the end of every Sprint the team gets together and talks amongst themselves about what things they liked, what things they didn’t like and they are free to change what things they didn’t like so that the next Sprint works better. The Sprint Retrospective is about looking back to see what they liked and what they didn’t like and then modifying the process to fit their own needs. [emphasis mine]

It seems that sometimes we forget that a process of self-improvement and process improvement requires time for the team to reflect on their work. Without the opportunity to reflect, things are likely to continue on as they have been going (for a light workload), or to degenerate quickly (when the pressure is on to get things done). And not just the process but - more importantly - the team dynamics, collaboration and therefore productivity.

"Process entropy" is real, and one of the best ways to counteract it is for a team to participate in the type of planned, regular, directed, constructive reflection on the process and the team that agile methodologies such as Scrum bake into the process framework.

But "process" is a secondary concern ("Individuals and interactions over processes and tools" - Agile Manifesto). The main issue is the need for a dedicated and valued regular opportunity for the team members to be able to be honest about their project and team concerns and to air them in a safe team environment. The retrospective facilitator must ensure that such an environment is a reality for the team.

Hence the importance of seriously and intelligently applying (not just reading) the retrospective prime directive as the guiding principle for the meeting as a means of enabling that to occur:

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

All of the top 10 reasons given above are issues that would be mentioned and dealt with in a well-run iteration retrospective. Except that it would happen organically in a safe team context that can bring a tremendous sense of team ownership and visibility to such issues in a way that a directive from a single manager never could. The assumption is that there is a commitment from the team to deal with any process impediments in a diligent and responsible way, which is usually something that the ScrumMaster or project manager would be responsible to help the team do (visible and - if necessary, verbal - reminders of the retrospective action items both in iteration planning and throughout the iteration). As always, action items from a meeting are worthless if no one acts on them.

The power of a self-organizing team is its ability to inspect and adapt rapidly (aka AGILITY). Take away the team's iteration retrospective, and you may be crippling their ability to do that without even knowing it.

Tonight was our 3rd IASA Denver Chapter meeting for 2008. As usual, we met at the Statera offices in the Denver Tech Center.

Dave Guevara gave a fantastic, animated, detailed and highly participatory presentation on "The Business of Architecture" and much good discussion ensued. Dave challenged us to understand, define, pursue and communicate the business value in our architectural pursuits at every level of the business from infrastructure right through to enterprise strategy.

The food - as always - was excellent and it was encouraging to see not only many first-time attendees to the event, but also a very diverse group of architects from a variety of companies.

It is exciting to see the chapter's growth since our founding at the beginning of 2008. We have doubled our membership to over 70 registered chapter members now, with new members being added every month.

Kudos to the great team at Solution Partners for their incredible support of the IASA Denver chapter this year as our first founding sponsor company. Thank you especially to Andrew and Ryan from Solution Partners for attending and participating in tonight's member event.

The next chapter member's event will be August 7th, check back to www.iasadenver.org in a week or so for more details.

I have not read the book "Test Driven: TDD and Acceptance TDD for Java Developers" by Lasse Koskela. I stumbled across the book through the recommendations feature on Amazon and started to read the reviews.

What caught my eye was the review under the heading "Very Harmful approach" by Ilya Volvovski written on January 19, 2008.

The review is succinct and well written, and it is clear that Ilya has a passion for quality software and strong experience with how to develop it. It appears to make a strong case against the practice of Test Driven Development. For that reason I wanted to work through Ilya's argument and see if I can respond to his points and hopefully bring some clarity.

When I purchased the book "Test Driven" by Lasse Koskela I hoped to see suggestions, patterns, and tools for continuous testing during the development cycle. It is not a secret for an experienced developer that postponing the testing phase until the design and implementation are complete is very dangerous.

Later in his review it is clear that Ilya has familiarity with agile development, and is a proponent of an agile approach to software development. But here he advocates having a testing phase. Testing phase?? Agile has no testing "phase" since testing is typically done continuously throughout the project as much as possible. At least, this is the case for Extreme Programming. Scrum does not really mandate when the testing happens, but it is generally understood (and certainly was taught at the CSM course I did) that testing should be within the iteration on a feature by feature (i.e. user story by user story) basis.

Every real world developer is well aware that implementation quite often reveals design shortcomings, while testing does the same for implementation, and less frequently for design deficiencies.

I would say it even stronger than that. Implementation always reveals design shortcomings, since implementation has to grapple with the realities of changing and poorly understood user requirements. Framework design is a little different here, but concrete implementations are always the best way to validate a design.

Refactoring provides the flexibility to make incremental improvements during the implementation and testing phases.

Agreed. And I think that is the key point in understanding test driven development. Refactoring does provide that flexibility. And incrementally and iteratively writing the test first as a way of specifying the contract for the software up front allows the developer the maximum scope for refactoring possible.

What I found instead is a manifest of software development madness. The book proudly presents in pictorial form (as if words weren't sufficient enough) on page 15 a reverse development cycle: test - implement - design. And naturally, since there is no design forethought, testing is followed by endless refactoring to improve the design and implementation in order to achieve better and better results. Which, in my opinion, doesn't equate to good or great; it still equates in best case to mediocre. Why?

Why assume that there is no design forethought? TDD is about doing just enough design, and doing just enough design on a continuous basis. I hear this assertion often, that TDD implies no design. This is a misunderstanding of the approach.

My experience has been the opposite; I am always designing as I code (and I draw diagrams - UML or whatever - when necessary) when I practice TDD, because I am always focused on clearly expressing the behavior of my classes (through the tests, which exercise the public properties and methods of the class), coding up the minimal implementation of that behavior, then refactoring the class design to improve it. This often involves a discovery of where I should refactor towards a design pattern to decouple the code and make it open for extension rather than modification. See Refactoring to Patterns by Joshua Kerievsky for a comprehensive description of how to do this.

The power of software design (OO especially) is the ability to establish inherent relationships and commonalities between seemingly unrelated domain entities and model systems in our mind (and modeling tools that exist in abundance) before they materialize in a final product.

Yes, part of the power of OOD is to be able to create a model. This is the basic principle behind Domain Driven Design (DDD), of which I am a strong proponent. But I think it is going too far to say that this is the power of software design. My big issue with the statement is that Ilya seems to be saying that the power is in doing this design as a separate effort, completely prior to implementing anything. The main problem with this approach is the delay in validating the design.

With TDD, and agile in general, the difference is the feedback loop. TDD shortens this feedback loop to a smaller process of design in our mind, implement an executable specification for that mental model, then implement the simplest code to prove the validity of that model. Then rinse, and repeat. And refactor mercilessly. We still do design, whether it is UML or something else. But aren't naive in thinking that a UML diagram can capture the necessary details and deal with the vagaries of reality that inevitably present themselves as we try to express it in code. See the famous article What is Software Design? by Jack Reeves.

We design frameworks in order to use them over and over again. Well designed and reusable components should have minimal yet complete interfaces to be successfully utilized in more than a single application. This doesn't come from the test and try approach; it is the result of a significant design effort.

But not just up-front design effort. TDD is the best way to arrive at a minimal yet complete interface. It is a mistake to call TDD a "test and try" approach. It can certainly degenerate into that, but that is not how it is meant to be.

I am very perplexed with a proposal to substitute use cases or user stories with test cases (page 46). In short these are different activities usually performed by different people with different sets of qualifications.

On an agile project these "different people with different sets of qualifications" typically collaborate together on defining the acceptance criteria (i.e. tests) that comprise the definition of Complete for a user story. On our project the business analysts work with the business users to arrive at the (usually high level) acceptance criteria, and the developers code up their tests to meet those criteria (but often at a much lower level).

The suggestion to "choose composition over inheritance" (page 119) is very strange. Inheritance reflects a different relationship which could and should be exploited in design and implementation. I found ridiculous the argument to use this advice to simplify testability (not even improve).

Choosing composition over inheritance is not strange. This is well argued in Joshua Bloch's Effective Java Language Guide - see chapter 4, item 14. The bottom line is that if we rely on inheritance, then our behavior can only be determined statically at compile time (through implementation/class inheritance), but with composition, we can mix and match objects at runtime (c.f. p. 93 of Head First Design Patterns) through interface (aka type) inheritance.

The argument that this simplifies testability is not ridiculous. Testing interface inheritance (i.e. with a mocking framework such as Rhino Mocks for .Net) is far easier than testing class inheritance.

Page 121 suggests avoiding Singleton patterns claiming that "object instantiation is dirt cheap with modern virtual machines" as if static and Singleton are used to make code more efficient.

Ilya missed the point here. As I said, I have not read the book that he is reviewing, but I doubt that the author is arguing that a smaller memory footprint is the reason people use static Singleton patterns. Singletons are one of the most overused design patterns today, and need to be used wisely. The Singleton patterns should be used judiciously for a number of reasons. Firstly because the pattern is akin to using a global variable and thus can make the code unclear and more difficult to maintain. Secondly, singletons are difficult to test and often can result in tightly coupled code.

I don't disagree with the desire to be agile; it keeps you grounded in reality. It is hard, or close to impossible to achieve first-class results without iterations. That is why the waterfall approach fails so miserably.

Yes. Agile does keep you grounded in reality. It is an empirical approach. It focuses on working software as the only measure of progress, rather than the creation of secondary artifacts such as design documentation, test plans, etc.

Testing - unit, functional, system, performance etc. - is critically important during all stages of development. Test plans should be created in parallel with the design and implementation efforts. As regression tests are software product "sanity checkers", unit tests keep developers confident as they make progress.

Agreed, no complaints here! But TDD makes a great many of the test plans executable. I really think that Behavior Driven Design, where the focus is on clarifying the terminology in terms of writing executable specifications, is a big improvement if for no other reason than it takes the focus off the tests and onto the behavior that the tests are supposed to validate.

Why would one think that the right approach is turning the development process on its head? I think that it is extremely harmful for young software developers, who would bypass the necessary steps (and pains) of a systematic routine of building good software.
To tell the truth, as entertaining as it was to discover more and more intricate details of TDD, I stopped somewhere on page 100 and browsed through the rest without going into details.

Once again, avoiding design is not what we are talking about. I'm sorry that Ilya didn't read the rest of the book. And it doesn't seem like he actually tried applying the approach. It wasn't until I actually began to practice TDD (and now BDD) that I really grokked it.

On a positive note, "Test Driven" has a reasonable amount of good references to existing tools and technologies. The book stresses the importance of testing, including acceptance, and gives interesting insights into various techniques. Code examples are well written. The refactoring suggestions are very sensible as well. Apparently, the author has first hand experience with the methodologies and tools he describes.

Ilya does like the book. Clearly for those who want to learn about doing TDD with Java this book would be an excellent choice. And this comment from Ilya is a testament to his fair-mindedness.

My major disagreement is with the fundamental principles in this book, not in practical terms and advice. 1 star rating reflects my very negative attitude towards approach. A lot of recommendations are very useful.

I think that the negative attitude comes from a fundamental misunderstanding of the approach. My concern is that if a 470pg book by an expert on TDD cannot clear up the confusion, then I don't give myself much hope in a short blog posting like this.

I came up with this metaphor for the book: Lasse Koskela is building a house for a young couple. They are vivid bikers. So, Lasse builds a bedroom and a bike room. Tests passed. A few years later the couple has a child and the bike room has to be remodeled to be a baby's room (not the best room for a child) or he adds a room by eliminating one of the garage spaces. Tests still pass - everybody is alive. Then a second child arrives, and Lasse has to add yet another room, in the process having to relay new electrical and plumbing lines. Tests still pass. The result is an ugly, poorly designed house that the original family leaves and nobody else wants to move into.

Why use this metaphor? Because Ilya misunderstands TDD and refactoring. This metaphor would be true, if we were building physical things, subject to the laws of physics. But we are not. We are building software, which is a whole different animal.

I started reading The Art of Agile Development by Jim Shore today. Now that I am deep into Scrum and have almost 18 months of agile practice under my belt, I want to move beyond the project management framework and dig more deeply into the rigorous software engineering practices that undergird Extreme Programming (XP).

While our project delivery team has come amazingly far since we first started our system rewrite and contractor hiring in January, I am determined to take our team cohesion and coding practices to the next level this year.

I thought I should start with the definitive work, so I just finished Extreme Programming Explained: Embrace Change by Kent Beck last week. There was so much good content in there, but I wanted to follow it up with a book that was a little more current (The Art of Agile Development was published in Oct last year) and detailed (438pgs) on XP.

So far what I have read of Jim and Shane's book has been excellent. Like Kent's book, I really gravitate towards books that are very pragmatic and just as people-focused as principle and practice focused.

I am hoping that I can hook up with some other agile developers in the Denver area and maybe work through the book together. I want to learn from other practitioners that are already experienced in all the XP practices, particularly pair-programming and TDD so that I can help raise the collaboration bar with our team.

See a great 30 min video interview with James Shore on “The Art of Agile Development” at InfoQ from Agile 2007. Jim goes into the philosophy behind the book and provides some helpful insights into how he and his coauthor Shane Warden came up with the principles detailed in the book.

Jim also talks about how he and Shane have incorporated the notion of personal success in software projects into the book and how that impacts agile development:

But in general people tend to really like having the other sorts of success, they like feeling they have accomplished something significant, they like having a life outside of work and they like getting along with their co-workers. So Agile development I think enables this type of success as well.

I am really looking forward to digging deeper. Any XP practitioners in the Denver area that would like to meet over lunch and discuss the book? I'll post this request on the Agile Denver mailing list too and see if anyone is interested.

Witty kept crashing on my Vista Ultimate laptop.

I am trying out twirl instead. It made me install Adobe Air, which I was reluctant to do because I have no idea what it is (or desire to find out for that matter), but I saw other people using it and recommending it and decided to at least kick the tyres on the thing.

So far I really like it compared to Witty. It has many more features and has not crashed yet. Plus you can recolor it, filter feeds, reply easily...It even shows "picture-in-picture" style replies (very cool!) and makes itself opaque when not being used.

Apologies for blogging about the weather, but I have to share the joy around a little. Does everyone know that Denver averages 300 days of sunshine a year (depending on how you define a "day of sunshine")?

I am on Twitter now. And if I get someone to follow me it might even be worthwhile :)

I have been using Witty  to tweet, which crashes a little too much for my taste, but I haven't had the time to find something better.

One major change I made last year was to purchase a good ergonomic keyboard, the Microsoft Natural Ergonomic Keyboard 4000. For under $50 it brings a whole lot of comfort and goodness to the typing experience. It is USB, so I use it with my laptop whenever I can. I had been typing a lot with my laptop keyboard and my fingers started hurting. I needed to get a good mid-level ergonomic keyboard to stave off a typing related injury, and the Natural 4000 seemed like a good choice.

In fact, I like it so much that I bought one for my home laptop (see earlier posting for details) and one for work (Lenovo T60P). Not only that, but when I travel for business I take it with me in (it is just small enough to fit in my 22" carry on bag). I cannot stand to use the laptop keyboard for long periods if I don't have to.

Related to this, the other part of my strategy to make myself more productive is to eliminate my dependence on the mouse. After seeing Oren at Devteach in Vancouver last year blaze through an hour's worth of extreme refactoring with R# sans mouse, I decided to follow suite. I learnt the R# shortcuts and as many of the Windows ones as I could, and barely use the mouse at all. It makes a tremendous difference to my speed and efficiency with the tools.

I encourage every developer I meet to ditch the mouse for coding. It is painful for me now to watch someone on my dev team move through code using the mouse. Every time the right hand leaves the keyboard, grabs the mouse and the pointer moves over the screen I die a little inside as I imagine how many hours of coding time are wasted doing that over the course of a month.

The other (more radical) step I took last September was to learn to type using Dvorak.  Here is the layout, does it look a little weird to you?

I ultimately blame Phil Haack for this. I guess that my blog is starting to look a little like a Dvorak propaganda machine, but for those who care here is an update on my typing progress (once again, based on the TypeQuick test):

YOUR RESULTS ARE:

Number of words typed: 177
Test duration: 3 min
Speed: 59.1 words/min. (295 keystrokes/min.)
Error penalty: 18
Accuracy: 89.9%

I have not tested myself since December 20th last year, so I was pleased to see that with no additional typing practice I have increased in speed from 37.7 wpm to 59.1 wpm. That is a 56% improvement! And with no real training using typing tutor software etc. I know that consistent training would have accelerated my improvement, but I just haven't been able to bring myself to be consistent with a typing tutor program.

Now I am less than 20 wpm lower than where I was at with Qwerty on Sept 16th when I first made the switch. But the main benefit for me is that now I am very comfortable with Dvorak and - unlike when I typed with Qwerty - I never look at the keyboard. This means that I am more focused now on what I want to type than where the keys are. Also, my fingers are more relaxed and not having to work so hard to type. Dvorak is just more comfortable.

It looks like I am averaging an improvement of roughly 10 wpm every month with no loss of accuracy. This increase in speed is with almost no typing practice, rather just day-to-day usage. I am using Dvorak exclusively now and, while I will still need a few months to get back to how fast I could type with Qwerty, I think my speed is fine as a baseline for everything I do. The best thing is that now I don't ever look at the keyboard, which was certainly not the case prior to switching.

YOUR RESULTS ARE:

Number of words typed: 113
Test duration: 3 min
Speed: 37.7 words/min. (188 keystrokes/min.)
Error penalty: 6
Accuracy: 94.7%

After a week of hanging out with all the Alt.Net guys in Vancouver at DevTeach, I finally hang my hat on Alt.Net as something that I want to be a part of. Here is a nice map showing where to find us all (thanks to Chad Myers for the idea). I tried embedding this on the page but Live Spaces won't let me (sigh)

This book has been very helpful to me so far. Not so much because it is deeper than what is in MSDN/BOL, but because it is broader. What I mean is that every topic discussed has one or more associated examples explicating good techniques, and it is all laid out in a nicely progressive manner. Simple to complex, basic to advanced...culminating in a full case study example (which I have yet to work through in detail, but I have at least read through it and understood it). I usually learn best by seeing how others have done it and then imitating their techniques, so I have found it quite helpful. I wish it had been available back when I started using SSIS. My very first package used the Script Component and regex's, so I certainly dived in head-first. 

Not only that, but there are some good tips I found along the way. For example, when I first started with SSIS I tried creating an Excel source and SQL Server destination, and kept getting errors related to not using Unicode columns in my destination tables. This book explains why this is the case, and has some good advice on how to work around it.

I'm not sure that this book would teach the advanced SSIS practitioner anything. But I suggest that if you are interested that you browse through it at the local technical bookstore and see if it provides you any value. There is some redundant material in the book (seems to be symptomatic of the Wrox multi-author approach), but it is better than most. And the redundancy does allow you to pick up any chapter and know what is going on without having to refer back to previous chapters.

So, to sum up, I have found the BOL articles to be comprehensive and detailed, but the Wrox book is definately helpful in (i) fleshing out how the various parts of SSIS integrate, and (ii) giving good examples on how to accomplish this.

Enhanced Auditing

SQL Server 2008 improves compliance and security by allowing you to audit activity on your data. Auditing can include information about when data has been read, in addition to any data modifications. SQL Server 2008 has features such as enhanced configuration and management of audits in the server, which enable organizations to meet varied compliance needs. SQL Server 2008 can also define audit specifications in each database, so audit configuration can be ported with databases. Filtering of audits to specific objects allows better performance in audit generation and flexibility in configuration.

Compare with some forum postings on CDC:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1729734&SiteID=1

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1730222&SiteID=1

and where auditing in SS2008 really seems to be:

Description

In SQL Server 2008 we are providing three different change tracking / auditing solutions, yet none of them completely address the kind of information I would like to track and review. The simplest case is I want to figure out who ran an update, from what workstation, against the Employees table, and the before and after values. With Change Data Capture, I cannot determine who ran the statement, or from where, because this information is not in the log. With Change Tracking, I can only dump information into the context column, ad this may require application changes to support. And with auditing, I need to parse the original statem

ents to figure out the bad guy, and this still leaves me with only the "after update" value.

Comments

Thanks for the feedback - definitely a good set of suggestions that we will look into. For SQL Server 2008 we will attempt to ensure there is a way to correlate audit log records with CDC changes. Having enhanced configuration for CDC and/or auditing that allows both tracking features to be configured in one go is not likely to happen for SQL Server 2008 I'm afraid.

Posted by Microsoft on 10/5/2007 at 1:20

Asus A8JS-4S024C 14" WXGA+ T7200/GeForce 7700 2 GB DDR2 667/100GB 7200RPM/Bluetooth/DVDR/Windows Vista Ultimate

Since May I have been doing all my home development on an Asus A8JS laptop. This awesome little machine has been a joy to use. My only complaint is the short battery life (~2hrs on full load), but this has never been an issue for me since I mainly got it to replace my Dell Dimension for development work and I usually am able to find somewhere I can get power.

Processor & Cache Memory

Intel Core 2 DUO Processor T7200

2.0GHz, FSB: 667MHz, 4MB L2 Cache

Virtualization Technology Supported

Operating System

Microsoft Windows Vista Ultimate 32Bit

Chipset

Intel 945PM

Main Memory

2048MB DDR2 667

Support for 2 x SODIMM sockets (up to 2048MB)

Display

14” WXGA+ (1440 x 900) TFT-LCD

Color Shine Glossy Panel & Splendid

Video Graphics & Memory

nVidia Go 7700 512MB

Hard Drive

Seagate Momentus 7200.2 100GB 7200rpm S-ATA

Optical Drive

8x DVD-RW Dual Layer Drive

Connectivity

 - Bluetooth Built-in
- Azalia compliant and V.92 / K56 flex support

- Intel PRO 3945 Wireless 802.11A/B/G

- Integrated MDC Fax/Modem

- On board 10/100/1000 MBPS RealTek Fast Ethernet Controller

- Full and half duplex mode support for 10/100mbps

- 1X Gigabit lan

- Modem supported V.90 and universal PPT

Card Reader

8-in-1: SD/MMC/MS/MS Pro (adapters)/XD

Express Card Slot support

Camera

- Built in VGA WebCam + microphone

LED Status Indicator

- Power-on/Suspend

- Battery Charging/full/low

- Storage device access

- Caps lock

- Wireless enabling

- Number lock

- Storage Access

Interface

- 5X USB2.0 Ports

- 1X DVI

- 1X Gigabit lan

- 1X Audio out/SPDIF

- 1X Microphone-built-in

- 1X VGA port/mini D-sub 15-pin for external monitor

- 1X RJ11 Modem jack for phone line

- 1X RJ45 LAN Jack for LAN insert

- 1X TV-out (S-Video)

- 1X IEEE1394b port

- 1X infrared ports to support IrDA

Keyboard

- 19mm full size 88/89 key with MS Windows function key

Audio

- Built in 2 speakers and mono microphone

Hot Keys

Instant Launch Keys

- 4 Active buttons: Power4 Gear+, Wireless, Touchpad lock, Internet Explorer

Function keys

- Fn+F1 Suspend to RAM/Disk

- Fn+F2 Wireless Switch

- Fn+ F3 Email

- Fn+ F4 Internet browser

- Fn+ F5 Brightness down

- Fn+ F6 Brightness up

- Fn+ F7 LCD On/Off

- Fn+F8 LCD/CRT control

- Fn+F9 Touchpad on/off

- Fn+ F10 Volume on/off

- Fn+ F11 Volume down

- Fn+ F12 Volume up

- Fn + C Splendid

Battery Pack & Life

6-cell 4800mAh battery pack

Battery Charging time, 4hrs (System On/Off) to 100%

Battery low warning message

AC Adapter

Output: 19 V DC, 3.42 A, 90W
Input: 100—240V AC, 50/60Hz universal

Dimensions & Weight

13.18” x 9.64” x 1.37”~1.46 inches (WXDXH)
- 5.25 lbs

Warranty & Support

2 year GLOBAL warranty