I am reading "The Software Architect's Profession: An Introduction," by Marc T. Sewell and Laura M. Sewell. I am not writing a book review with this post. Instead, I would like to highlight some similarities between the two disciplines. Whether we are building with brick and mortar, wood, steel, or computer code, the roles and processes are analogous. The role of the architect is important for both, but when it comes to software, the architect often goes unfulfilled.

Compared to architecting and constructing homes, hospitals, and skyscrapers, architecting and developing software is new to many of us. In our minds, whether we understand the processes required to erect the Empire State building or not, most of us  possess an intuitive understanding of the distinct roles of the architect, scientist, engineer, builder, electrician, and plumber. We realize that buildings provide shelter, make our lives easier, and consist of rooms specific to living activities. We have living rooms, family rooms, meeting rooms, workout rooms, kitchens, ect. If we want to add on a garage, screened-in porch, or modify an existing room, the architect needs to plan for this in his/her design.

When it comes to software and the processes required to plan, design, develop, and test, many of us lack the intuitive knowledge of what is, or should be, necessary to build software. Just like a building, software makes our lives easier and consists of rooms, such as  chat rooms, document libraries, art studios, financial planning, shopping, and home buying to name a few. If we want to add on a new room or modify and existing, the architect needs to plan for this in his/her design.

It becomes easier to see how buildings and software are similar and how the roles specific to each appear to be obvious and necessary. A building needs an architect, a builder, an electrician, and so forth. Software, similarly, needs an architect, a developer, a tester, and so forth.

Ask yourself this, "how many buildings (homes, schools, hospitals, malls, ect.) can I think of that were built without an architect?" Hmmm... I probably cannot think of any, or I should hope the answer is zero.

Now ask yourself, "how many software applications were built without an architect?" This one I can answer more easily - several. I try to convince myself that so-and-so was "acting" as the architect on this or that project, but the nature of it is, too many software projects are built without a dedicated architect.

Why is it that we feel like a building requires an architect, but that software can get by without it?

Is it because over centuries and millennia, we have been exposed to the processes required to construct buildings on a daily basis? Whereas, since software is comparatively new, the processes and roles required are not fully defined, or engrained in us, or we have yet to see centuries worth of catastrophic errors from omitting these roles?

"Blaming software failure or difficulty on 'changing requirements' is merely symptomatic of the lack of true architecture." As owners and builders see what is being built, they realize what is incorrect and begin to make modifications to align their initial expectations with the reality before it is too late.

"It is equally erroneous to blame software failure on poor management. Even the best managers cannot produce a satisfying result from a bad design or a lack of design."

Without this post becoming tiresome and long-winded, this book draws some good comparisons between the nature of building structures and software and the roles necessary for each.

Do you have an architect in your organization? Is he/she only an architect, or is he/she sharing this responsibility? Why?

This is an interesting webcast on Channel9 where Eric Schmidt provides a technical tour of the NBCOlympics.com site built with Silverlight. If you are like me and become frustrated with the limited options of events the stations choose to broadcast, then we are in luck. The video that the NBCOlympics.com site is providing is excellent and covers nearly all the sports. I have heard estimates of roughly 2,200 hours of video, live commentary, live events, and with the ability to choose what we prefer to view. For those events we miss, we can search and view them at our leisure.

I have been able to watch some events I have always wanted to see but the television stations do not televise. Popularity and advertising dollars demand that stations air the usual suspects, swimming, track and field, gymnastics, ect. I have been able to explore fencing, sailing, handball, archery, and weightlifting to name a few.

If interested, check it out. If you have not seen the U.S. Men's 4x100 freestyle relay, check it out. What a race!

The marker interface is an interface that is empty. It does not implement any properties nor methods. It is used to mark the capability of a class as implementing a specific interface at run-time. In languages that do not provide support for associating metadata to a class, this approach can be useful. In C#, metadata attributes are available to apply to a class, and according to the .NET Framework 3.5 Design Guidelines for Developing Class Libraries, marker interfaces should be avoided.

When I first noticed these marker interfaces in project I immediately thought it was a code smell. It just did not seem "right." Why provide an interface that defines nothing? Why provide a marker interface that implements a non-marker interface? Obviously there must be a reason for this?

Two sources encourage me to avoid using marker interfaces and to use attributes in C#. Interface Design and .NET Type Design Guidelines - Interface Design.

There advice is to avoid this...

              public
              interface IFooAssignable
{}

              public
              class FooAssignableAttribute
: IFooAssignable

{

              //
...
            

}

And to embrace this approach...

[FooAssignable]

              public
              class Foo

{

              //
...
            

}

              public
              class FooAssignableAttribute
: Attribute

{

              //
...
            

}

There appears to be more work involved in writing "good" code.

If I am using "marker" interfaces, I can do this...

              if(foo is IFooAssignable)

{

              //
...
            

}

If I am using attributes, I can do something like this...

              object[]
attributes = foo.GetType().GetCustomAttributes(false);

              foreach (string attribute in attributes)

{

              if(attribute
== "FooAssignable")

    {

              //
...
            

    }

}

Or, thanks to Jarod Ferguson's suggestions on using extension methods and LINQ, I could have this...

              public
              static
              class AttributeExtensions

{

              public
              static
              bool IsAttributedAs<T>(thisobject obj)

    {

              if(obj.GetType().GetCustomAttributes(false).Where(x
=> x is T).ToList().Count == 1)

              return
              true;

              return
              false;

    }

}

              //
Then wherever I want to check for the attribute marker...
            

              if (foo.IsAttributedAs<FooAssignableAttribute>())

{

              //
...
            

}

At this point, while "marker" interfaces are a code smell to me, I am still on the fence when it comes to using them versus custom attributes. I will more than likely tend to favor the attribute approach, unless I can prove that the cost of reflection is too expensive for my situation. I admit, I will do what I can to omit marker interfaces, perhaps by using some other interface where possible.

What are you doing in situations like this? Can you offer me a more elegant solution?

For software engineers, the job interview process typically starts with a technical, phone screen where a candidate's skills are verified against their resume. The end goal is to determine, "are they who they say they are on their resume?" and "can they meet or exceed our expectations for this position?" The phone screen is far from perfect. Good candidates can be overlooked and bad candidates can proceed further. The nature of the screen is prone to error. If we devise a plan and execute it, we improve our chances of finding the right candidates and saving ourselves time and money.

After the technical screen, a coding assignment may initiate the next stage of the interview process, followed by an in-person interview. If all goes well, contract negotiations complete the process. Organizations can budget a decent amount of money for each candidate, so it is important to approach each stage of the interview process with a plan. A bug becomes more expensive to fix the further into the product lifecycle it survives. Like a bug discovered after the product ships, a candidate discovered to be dud during the full day interview becomes a financial loss. The phone screen now becomes a more integral part of the interview process. We have a short amount of time to uncover a potential fit with a candidate we have yet to meet. 

Internally, interviewing is about finding the best candidate who currently meets, exceeds, or potentially can meet the desired skill set, shows passion and motivation, and fits with the organization's culture. Externally, interviewing is about public relations and perception. At each stage in the interview process we want our candidates to be challenged and think positively about both the interview process and the organization.

The impression the candidate takes out into the market is important if we care about our image. Our goal is to conduct a professional interview such that, regardless of the outcome (hire/no hire), the candidate's impression of the company is high. Word travels fast and negative rapport hurts recruiting. We tend to remember the negative experiences more vividly then the positive, so treat the candidates professionally and respectfully, and by all means, conduct the interviews with staff trained to interview and mature enough to represent the company. On several occasions I have witnessed interviewers conducting themselves as if they are being interviewed by their peers and managers in the room.

The goal of the phone screen is to assess the candidate's skills to determine if he/she would be technical enough to be successful during a full day interview. We want the candidate to walk away from the interview feeling rewarded and good about themselves and the company. We want to determine fit as soon as possible to save us time and money and have the candidate save face.

The Plan

The phone interview should be "in and out," just like a robbery. Have a plan of attack. Whether it is interviewing or playing a football game, those who are successful execute a plan. In college we followed a plan for every game. "Convert third downs. Don't give up the big play. No turnovers. No penalties. Execute the kicking game. Execute special teams. Don't flinch." I am sorry I cannot recall all of them. When we followed the plan we found success. When we were not successful, we could easily identify which part of the plan we did not execute. Interviewing can use the same approach.

Have a plan or a script in front of you during the interview. Settle on some questions you feel will help determine technical skills and stick to them. Have some backup questions. If the candidate answers this way, delve into his response with this. If he fails to answer, ask him this, or move on, ect. Assuming your plan works and you continually hone it, execute the same plan for each candidate. Make your interviewers understand the plan. Have them execute it. Have them believe in it.

My Typical Plan

• Schedule 30 minutes with the candidate over the telephone in a quiet room away from distractions
• Send the candidate a live meeting request
• Be prompt, be prepared
• Determine fit as soon as possible
• Drive the discussion
• Small introduction
• Warm up questions
• Get them writing code
• Assess how they have done at this point
• Good - continue further questioning and begin selling us more
• Bad - conclude. Remember, the longer we stay on, the more attached we become.
• Conclude
• Follow up with the recruiter

For me, the two most important concepts to take away from the phone screen are drive the discussion and get them to write code. Driving the discussion keeps the interviewer in charge of the interview and enables proper execution of the plan. The longer we stay on the phone, the more susceptible we are to making decisions based on emotion rather than fact. Drive the discussion and stay in command.

Get the candidate to write code. Do not assume because they can talk about a technology that they are comfortable working in it. Use live meeting and a have them write a function, refactor a class, provide a working example of polymorphism. Better to find out now if they cannot write code than further into the interview process.

The technical screen is more important than we tend to believe. Devise a plan and execute it. Lead the interview and determine as soon as possible if this candidate possess enough skills and experience to be successful within your organization. Be professional and respectful. We want the candidate to think positively about the company regardless of the outcome.

I have spent the past couple weeks holed up in a cave building a web site using the latest ASP.NET MVC framework. I am behind on blogging, responding to emails, and keeping up with my RSS feeds. I am making good progress with ASP.NET's MVC framework and enjoying the development experience, despite the occasional beta blip.

I started developing a site using the MVC Preview 2 source. Two weeks in, I pulled the latest MvcContrib project, and a few days ago I upgraded again to the MVC Preview 3 source. Like anyone using beta software, I have spent some time swearing at my screen, but overall, I am pleased with the MVC framework. After returning from vacation, I now find that I am one more release behind on my MvcContrib binaries.

As I began developing with the MVC framework, the similarities I was seeing with Castle's MonoRail MVC were numerous and reassuring. I felt like I could hit the ground running with previous MVC knowledge. The sample MVC application right out of the box is functional and a helpful place to start familiarizing and education oneself with the new framework. For those tools and features that are not built into the framework at this point, I found the MvcContrib project to be helpful in my development.

It seemed like with each day of development I would discover something new, cool, or exciting, and I wanted to share it on this blog. As I started down the path of writing a blog entry, I procrastinated each time thinking, "let me just get through this one issue first and then I will blog." That approach snowballed tremendously. With each hurdle I had to surpass, there was another release I had to install. Of course, I did not have to install any of these updates, but I did thinking they would be trivial. In some cases they were, and in some they were not. My point - there is a great deal of change and development constantly occurring on the MVC framework and other tools supporting it. Expect this rate of change while the framework is maturing. Sometimes it is frustrating, but there is great support on the ASP.NET/MVC forums as well as MvcContrib.

Why do I like it?

MVC promotes a cleaner separation of concerns. Since I am used to developing in ASP.NET and trying to adhere to a loosely defined MVP pattern, this MVC framework mitigates some of the frustrations of having to enforce the pattern as well as SoC.

Testability is build into the framework. When creating a new project, there is an option to create a test project to accompany it.

I can create a web site quickly and cleanly. As I add a new page (view), I have a distinct controller and view for it. Unlike MVP implemented in ASP.NET, I do not have to enforce my controller-view separation, it is done for me.

I am able to use use more than one view engine easily. I am tired of using the ASP.NET view engine. While one can roll their own view engine flavor, MvcContrib provides support for a few out of the box. I can free myself of having to use ASPX pages, ASCX user controls, and their code-behind files.

I prefer using the NVelocity view engine. I prefer the more simple HTML view of NVelocity. My customers enjoy it as well, and they do not have to concern themselves with ASP syntax. They will have to learn a few tricks with NVelocity, but nothing that is not intuitive as it is.

Extensible source. I have been able to add custom support to provide overrides and additional functionality to the framework as I need it.

Community support. The MvcContrib project helps make development with MVC easier. Use their view engines and IoC container support. Know of some functionality that is not available, add it.

Pitfalls

IIS 6 and URL rewriting. While it is possible to get the nice URL rewriting to work with IIS 6, ISAPI filters, and extension mappings. It is a PITA. I am in the process of upgrading my customer's environment to use IIS 7. Today, their URL contains the ".mvc" string, such as, <domainName>/home.mvc, or <domainName>/account.mvc/login. I suggest having IIS 7 available.

Ajax framework. I am still waiting on a good Ajax framework to be included. The one MonoRail includes is nice. As for now, I am using jQuery and developing my own. Hmmm, maybe this functionality could be added to the MvcContrib project, and maybe instead of limiting it to jQuery, I could abstract it to enable other Ajax providers. We'll see what time permits.

Third party controls like Telerik, Infragistics, et alia. Rich datagrids, tree controls, and other controls that rely on view state and postbacks. I expect support will come around for these.

I tried the NHaml view engine, a .NET implementation of the Rails Haml view engine. My NHaml default layout (master page) was generating runtime errors because I was not use the proper spacing of two characters. Seriously? Two spaces? Who cares. I moved on to try Brail.

I have been pleased thus far. Thank you to the ASP.NET MVC team and the contributors to the MvcContrib project. Keep up the great work.

I have been doing code reviews frequently this past week and have been remarking on the naming conventions of test methods. In a effort to try and find the rules of BDD naming conventions, I came across Dan North's introduction to BDD, which is a great starting point, and a blog post by David Laribee that has made a good impression on me. You can read up on BDD to learn more, this post will not go into detail about it.

From what I gathered from David Laribee's article, I like this. I REALLY like this.

By changing namespace, class, and method names, the behavior of each spec (test) is clearly revealed. In a larger suite of tests, if there are failures, I can more easily see what is failing and what trends, if any, are resulting in my failures. Before, I would name my test method names to describe a behavior, "Some concept should do this when given that." Getting the namespace and class name involved provides a more legible test result.

While reviewing a test case for a peer, I took this approach and arrived at the following scenario. I am changing the names of the methods to hide details. The original test method was "FilterToEndPointTestReport." Making this more readable, using my previous approach, we arrived at "FilterShouldUpdateStatusOnReportWhenDefaultFilterValueIsChanged." Great, that is better, but...

Applying the approach described in David's post, I now have this.

               1:
              namespace Specs_for_Filters

               2: {

               3:
              public
              class When_default_filter_value_is_changed
: FilterTestFixture

               4: {

               5: [Test]

               6:
              public
              void Endpoint_should_be_updated_on_report
{}

               7:
            

               8: [Test]

               9:
              public
              void Endpoint_should_be_updated_on_grid
{}

               10:
            

               11: [Test]

               12:
              public
              void Endpoint_should_be_updated_on_chart
{}

               13: }

               14:
            

               15:
              public
              abstract
              class FilterTestFixture

               16: {

               17:
              //
provide common functionality that will be used 
            

               18:
              //
among behavior-driven filter test classes.
            

               19: }

               20: }

When my tests run, their resulting output is more legible. This approach helps me to think about my tests in terms of behavior rather than implementation. In my opinion, my test cases are now more abstract and more succinct.

I am undecided on Twitter. The jury is still out in my mind. On any given day, there are things I need to do and things I would like to do. Not taking into account family things, I read through my emails, both work and personal, read through my RSS feeds, news feeds, weather reports, IM with close friends and family, read a few credible news sources, and somewhere find time to work and research new and existing technologies. If I can get that far, that is a busy day, and that does not include family.

So where am I supposed to find time to update everyone on Twitter? How is Twitter fitting into your schedule?

You can follow me, but I am not really all that active, at least until I find more time.

I