While a freshman in college, I took an introductory physics class where one of the professors, though a really nice person, insisted on using the adjective "obvious" to describe most concepts. Every now and then, something was "more or less clear" or "relatively straightforward". A few of my friends and I would ask each other if anyone understood any of the material presented, much less found it obvious. We were lost and relied on the explanations of our teaching assistant to help. (I must digress for a moment. David Bear, the teaching assistant in this story, is one of the most intelligent people and competent teachers I have ever met. He is amazing.)

We were so lost that we resorted to keeping tallies during lecture. One section of the audience would track the word "obvious", others would track the "more or less clears", etc. We finally asked David, the teaching assistant, if he thought any of it was obvious. He then told us this. "When you are dealing with Nobel Prize winners and the like, you learn something. If they say something is 'obvious', you think about it for a few minutes, might see the connection and then it is obvious. If they say something is 'more or less clear', you go home, maybe ask me; basically expend some real effort, see the connection and are okay. If they say 'relatively straightforward', then if, before you die, you have the vaguest notion as to what they were talking about, it was 'relatively clear'.?

Realizing that we were doomed, we started taking bets on the daily tallies for the expression counts. Then, during one lecture, a student raised his hand and asked the unthinkable. "Professor, can you explain the connection, as I can't see why it is obvious?" A hush literally fell over the crowd. The professor looks at the board, then back to the student, then back to the board then to the floor. Board, student, board, student. After a rather long pause, he looks up and says, "Is David here? Ah, David, perhaps you can help me. Can you explain to this student the connection, as I can't think of a way to explain it simply?"

David's response was, "Honestly professor, I haven't been able to follow anything you have been talking about and I definitely don't think it?s obvious."

The class stood up, turned around and gave David a standing ovation. After it subsided, the professor turned back to the board and said (quite simply and relaxed), "Well I suppose I should be more careful with my use of the term 'obvious'."

The lesson is pretty obvious. We should be careful about our assumptions. But I am amazed with myself, having been a victim of this experience, that I frequently make all kinds of assumptions and use the term "obvious". I may describe an idea without careful clarification. I observe many other people do the same.

It has been my experience, that the best "Aha..." moments, for an individual or team, occurs when the actual explanation for an idea, previously taken for granted, comes to light. Everyone learns something, perhaps about the assumptions being made, deeper insight or both.

For example, I was recently at Agile Fusion, an event where testers and XP developers explored the integration of testers into an XP project. A key "Aha" moment (so I thought) was when automated testing was described as "automated change detection". This seemed to more precisely convey one way developers use automated tests. It seemed to provide comfort to many of the testers, as they realized developers didn't intend for test suites to detect bugs. Some testers had thought (rightfully so), how could automated tests do the job of a skillful tester? This realization made it easier for us to work together.

I have started using the term "change detection" when describing automated testing. It has allowed me to "convert" a few developers to embrace (or at least really try) the technique. It has also been a good way to explain the value of it to management.

I have tried to erase the term "obvious" (and its related cohorts) from my vocabulary. I am not too successful, but my awareness has been raised. Its a good first step.

Iteration 0 was really short, so there isn't too much to say. I had set an 8 hr time box which I cut to 3, since I was able to make a few decisions quickly and my research didn't take too long.

First, for the small logistics, NUnit and NAnt are definitely going to be used. I am going to pass on Cruise Control.NET for now. I was researched MS Visual Studio / CVS IDE integration and found this article, which gave pretty good instructions. After overcoming the frustration of not getting it to work in the past (and as the article's author points out), I realized the Microsoft SCC (Source Control API) is not really compatible with CVS. For example, you must explicitly check out files before working on them. I find CVS tools and semantics to be better, so I will stick with WinCVS. IDE integration doesn't get me too much, though I admit I really like using it in Eclipse.

The most significant part of Iteration 0 was selecting a project. I have decided to use the construction of NBuilder itself. I realize this is a little on the metaphysical side and a little "trendy" (using a tool to build a tool, like xUnit), but I was looking for a project that would allow me to explore my requirements and was realistic. I don't want to invent some fictitious situation, as it would be harder to consider the real needs of an application. I fear I would start to meld the app's needs to satisfy the assumptions I have about how NBuilder should work. Since the usage of the application should allow requirements to emerge, I think this is a good strategy.

More later, with Iteration 1 planning game, though I will be out of the country and won't touch this for a week or two.

QUESTION: I plan (hope) to make frequent postings about NBuilder to organize the project and provide a basis for reflection. For xTeamWorks I started a separate blog in anticipation of it becoming a distraction for anyone reading my normal blog. Anticpation is bad (not to mention my arrogant presumption that people read me blog), so I am not doing this for NBuilder, at least not yet. If anyone cares about this, let me know if you would prefer a separate blog for NBuilder or for me to post NBuilder entries on my normal blog. Thanks.

I have the following stories for Iteration 0.

Determine sample project

As NBuilder is a tool for persisting data in applications, I need a sample project.

Setup environment

Setup Source Forge account, build environment, configure change management, etc.

I plan to have this iteration be short (one day). Since I rarely have a whole day to spend on personal projects, I am time-boxing the iteration for 8 hours. In a retrospective, I will monitor my velocity for actual time spent working vs. the time that transpires due to lag between work sessions.

As far as the development environment goes, there are specific tasks / considerations. I will be using MS Visual Studio 2003, NUnit and possible NAnt. I have not used Cruise Control.NET and may look into it. I need to decide about configuration management. To this point, when working on open source projects with .NET, I have used Tortoise and WinCVS to update files. I want to use something that integrates with the IDE, but have not had success setting up Igloo yet to work with SSH. I also have the complication that a lot of my work is done offline, be it on planes or in hotels. I like to use MS Visual Source Safe locally to provide version control when offline. Ideally, I would have source control IDE integration, that I can use with CVS when online and switch to Source Safe when offline. (It would be really nice to synch the incremental checkins from Source Safe to CVS. If anyone has any ideas or experience with this, please let me know. I will be very grateful.

In a previous entry, I noted that I am beginning to work on NBuilder again. As I am starting a new, I am trying to be quite disciplined in adhering to the principles of XP and TDD. (I hope to be critical and consider if I follow these principles as well as I presume to.) So, in order to provide a monitoring and reflection mechanism for myself, I will try to diligently blog my thoughts.

These are my primary goals:

support testing

I want to use ideas like ObjectMother so that I can have data driven / dependent tests run fast (under 1 minute rather than more than 20)

persist objects easily

This one is hard. There is tension between making constraints on objects, aggregation methods, and attributes and simplicity of the framework. On one hand, I want the objects (and their needs) drive the model and then deal with their persistence. On the other, I want to reuse tools rather than re-craft and I want to eliminate the tedious code that can accompany implementing persistence support.

support extensions

I'd rather have a small basis to reuse and tailor on a case by case basis than a bloated tool that doesn't fit any actual context well.

There is one significant requirement / motivator for NBuilder, that I don't want to make a core goal but is in the back of my mind. I would like the persist the objects with different mechanisms, such as XML vs. a relational database. One of the practical drivers have been the need to refactor and tune database schemas, be it for performance or space consideration.

There are a variety of other specific features in mind, but I don't want to clutter my thinking, get ambitious or do much anticipating. I want the vision to be simple.

"NBuilder is an application framework for developing enterprise and information system applications. It provides support for the development of an object-oriented persisted domain model. It includes tools for modeling the domain, generating code for the domain entities and application, and a series of base classes that allow the rapid development of a stable, scalable, high performance application that easily supports automated testing and reusability."

The above appears on the Source Forge site for NBuilder and pretty much reflects my original ambition. Basically, most of the code I write needs to be persisted in a database and .NET doesn't have the nifty tools for object-relational mapping that Java does. (I can't believe I used the word nifty!) So, I (and the teams I have worked with) have generally crafted custom code generators / metadata managers that provide persistence and related services for Microsoft .NET projects.

There are a few motivators for me. First, I hate duplication. I (and other team members) have built such a custom tool several times now. Each time we learn something new, experiment and tweak for the specific circumstances in which we were working. So frustration is the first motivator.

Impatience (and frustration again) is next, as I can't wait anymore for someone smarter than me to do this. I have come across a few tools that address similar issues (some free and some commercial), but they don't address my needs terribly well.

Finally, there is vanity. Part of me (a larger part than I really want to admit) is convinced I can achieve some level of generality for the tools application. I actually tried this a few months ago, wrote something fairly quickly that I thought was useful. (It is actually being used for production code by one of my clients.) It has a variety of flaws, which I won't go into here, except for one. The largest flaw was in the approach and ambition. I assumed to know too much (I have done this multiple times before, I can fast forward to..) which leed to anticipation and some flawed design decisions. I also started with the ambition of writing too general a tool.

So why will this time be any different? It probably won't. The rationale part of me can smell some bad signs already. But, there is the vanity thing and vanity isn't rationale. So, being a glutton for punishment, I being again the search for my white whale.

There are a few things that keep me hopeful (or delusional). I think of Kent Beck's reflections on the money example of Test Driven Development. Beck notes how he has written the example numerous times and found that with a new metaphor, he discovered the cleanest implementation yet. I am hoping the powers that be take pity on me and provide this inspiration. I also hope to be as disciplined as possible in XP and TDD principles as I can (which I did not do so well last time around). Next is a practical hope. I have a few current "issues" I need to address in a couple of different projects. Some are client related, some are not. This will limit the amount of disclosure I can provide in my blog entries, but being a pragmatist I will quickly abandon all lofty ambitions for solving the problems that pay the bills. If I do this well, this attempt will definitely make it worthwhile.

Finally, I will learn something, probably a lot of somethings. This new knowledge may prolong my vanity and delusions, but continued learning is better than being stale and complacent.

During a recent dinner conversation in my home, one of my guests asked what I do and I started talking about agile software development. There was a general response as to why doesn't everyone develop software this way, as if it was so logical it would be common sense.

The reaction startled me a bit, especially since I see so much resistance to agile software development. I think much of this resistance comes from the emotional baggage of those considering agile development.

Many people considering agile development are doing so because they?ve had bad experiences and problems with software development. This problematic history is marked by dysfunctional work environments, failed projects, missed deadlines, extreme pressure, blame assignment, and general tension.

For example, a common management opposition to pair programming is "Why would I pay two people to do the work of one?" This frequently can be interpreted as "I already pay two people to fail to do the work of two people, now you want me to pay two people to fail to do the work of one person." There is so much distrust of the developers? productivity that management may fear pair programming granting permission to produce less.

Another example of emotional resistance is from a project manager. He may wonder, "Do I still have a job in XP?" or "How will people know I am doing a good job?" Developers have similar fears. In a pair programming environment, there is less room to be the "hero" or show off programming prowess. You can't take individual credit for a successful application when there is no code ownership.

Sometimes the resistance comes from the transference of previous experience. For example, I once outlined an automated testing approach to a group and someone reacted very badly. He flatly claimed it would not work and had no value. It was revealed later, he had tried something similar and it failed. He identified the two ideas as equivalent and had a "it's happening again" reaction, which blocked his ability to assess the actual approach outlined and not just his assumption of it. Furthermore, if the approach I outlined did work (and it really was similar to his own), then he is faced with confronting a new type of failure; maybe he was the flaw and not the idea.

In all these examples, there is an emotional resistance to agile development. The irrationality of emotions requires a different approach; you can't simply present a logical framework and expect that reason alone will be sufficient to generate acceptance.

I often hear "How can I sell agile development to...?" Maybe it is better to ask, "Why aren't they buying into agile development?" The human component of a team is much more important than the process. The better one understands the human dynamics of a team the more successful the project will be.

Bill and I started to work on xTeamWorks. I am not sure what is the best method of organizing all of this and I don't know how many people will actually be interested in reading all of this. Anyway, this will be few of several cross posts between two blogs, my normal blog and the xTeamWorks' blog.

There are several sources of information:

Source Forge Site

This site will contain the actual release files, product documentation and all product release information.

xTeamWorks' Blog

This is a journal of the project, how things are going, my ramblings, reflections, etc.

xTeamWorks' Wiki

This is used to actually manage the project. We will keep track of our XP stories, iterations, velocity and tasks.

The reason for all the different sites is that there are three different views of this project: the final product site, the management of the project and my personal accounts of the experience. This project is intended to serve multiple purposes:

work with XP in a remote setting

Bill and I don't use pure XP lately and I tend to work remotely on my current project. Since I must presented a paper at ADC 2003 about remote agile development, I wanted to explore a pure XP / pure virtual project. Though this is small, I think open source projects can benefit from remote XP.

build a tool to support online XP management

I work remotely a lot so posting 3x5 cards on a wall doesn't work for me. I did look at some other products for managing XP online, but they didn't quite address my needs or I couldn't get them to install correctly. So, like any good developer, I have convinced myself I can do a better job.... ;)

work more with Java and Eclipse

Bill and I have been mostly in Microsoft / .NET land for a while. I haven't done much Java work over the last year and haven't used Eclipse. This is a chance for us both to explore.

I have neglected to post anything about food on my blog, though it is a topic I have much interest in. Anyway, I recently held a 4th of July dinner and made a promise to some of the guests that I would start posting recipes and my culinary thoughts.

A topic we discussed during this dinner is one that I am constantly exploring, which is what makes for a good meal? I have this theory about the balance among the dishes necessary to satisfy its consumers. The theory goes something like this:

There are certain basic flavors that the tongue detects. I think they are salt, sweet, sour and bitter. Furthermore, we are generally quite sensitive to spice (heat) levels, acid and fat concentration. In order for a meal to be successful, a balance among these basic flavor components must be maintained.

Have you ever had a meal and felt that you wanted something else? Maybe something sweet? Maybe a cup of coffee? In these cases, the balance wasn't achieved. Hopefully you have had the opposite experience, where you finished a meal and were just content; you had no wish for anything else to eat.

This impression is the goal of any meal, in my opinion. It not is simply a question of quality ingredients or cooking proficiency, though lack of these two components will make it very difficult to achieve this balance. I have had many a meal where individual dishes tasted quite good, but I was ultimately unsatisfied by the meal as a whole. Something was missing. The chef missed the bigger picture and failed to see how each of his dishes contributed to an overall culinary vision.

Achieving this balance is not that easy, but there some tried and true combinations that work well. These come from specific ethnic cuisines. For example, if you buy a cookbook full of recipes from southern Italy and select appetizer courses, main entrees and desserts, you will probably have a good resulting meal. Similarly, get a Hunan (Chinese) cookbook and arrange a meal based on selections from it. You probably are still okay. But don't, mix tiramesu with fried rice. Though I love the two dishes, I would never serve them together. They don't complement each other. Complimenting elements are key ingredients in achieving this balance.

I believe that the cuisines of different ethnicities have evolved with this balance in mind. I think this is why many attempts at "fusion" cuisines, though trendy, are mistakes. However, some work well and I think it is because the chef, implicitly or explicitly, had the goal of balance in mind; she selected different elements that would complement each other as a whole.

There is a lot more I could write about this balance and guidelines for achieving it, though my thoughts are half baked and not well articulated, so I think I will wait till a future posting.

I am starting work, with the help of William Rakocy, on a web based collaboration tool for managing an XP project. I work remotely quite often so it would help to have online access to story cards to other project items. I have experimented with some wikis, MS Excel files and other techniques, but I think I could I could benefit from a tool.

I experimented with XPWeb and XPlanner, but wasn't particularly satisfied with them, at least for the needs of my project.

So, xTeamWorks will support the basic elements of XP, like story maintenance, task definition and signup, velocity tracking and iteration planning.

xteamworks.sourceforge.net is the website for the project. I will probably post updates as we go here.

If anyone has thoughts or requests, let me know.

I recently presented this paper at a talk at Agile Development Conference 2003.

I'd love to get people's impressions and feedback.

Based on interest to my talk at the Agile Development Conference on remote agile development, I have started a yahoo group on the topic. I encourage you to join the group if you have any interest of experience with agile software development, remote teams or just want another group to read.

Go to http://groups.yahoo.com/group/remoteagile/

I had a discussion recently with someone about something I read in the Pragmatic Programmer, by Andy Hunt and Dave Thomas. They write of the importance of developing proficiency with keyboard commands and text editor, to increase productivity by reducing keystrokes and mouse movements. There is merit in the book's discussion of the topic and I don't wish to dwell on the argument they make.

My belief is that preemptive optimzation is bad. Martin Fowler has addressed this a variety of times with respect to code and design. The idea is that you shouldn't try to preemptively increase the run-time performance of code design, as the bottlenecks in an actual system frequently are not what they were pressumed to be. You should profile the system and then tune the code to the actual bottlenecks of the sytem.

I feel this applies to people and processes as well. The advice offered by the Pragmatic Programmer is more of a technique than a goal. It may be nice to show off lightning fast keyboard skills, but it doesn't necessarily improve individual productivity, and is less likely to improve team productivity. Given there are only so many hours in the day, I advise that a programmer (and team) should reflect on her practices and think about where she can improve. If keyboard and environment proficiency seems like a good idea, then go to it. But it may not be advisable and may be a waste of time.

Like I feel with most things, just make sure you don't take any advice as an escape from thinking and reflection.