Earlier I blogged about how to sync my Outlook and Google calendar using Plaxo.  This has worked very well for me but now Google has released their own tool to do the same thing.

One of the interesting features that this tool allows is the ability to do 1-way synchronization.  You can get more information on how to set it up here. 

For now I'm going to continue to use my Plaxo setup since it already meets my needs.  But if you're interested in a solution for Google and Outlook calendar synchronization that doesn't require opening a Plaxo account, then Google Calendar Sync will be worth downloading.

Most consulting engagements usually end with a hand-off of the project's deliverables to the client's resources during the last few days of the consultant being in contact with the client.  This is often referred to as the "knowledge transfer" and can involve walking the client through the finished code artifacts and any documentation around it.

Most consultants dread this part of the process as it often requires mounds of documentation and tons of meetings with seemingly little accomplished.  Even after the process is completed, many consultants will still get a follow up call from the client six months later when the developer who was supposed to take over their project has left for greener pastures.

There are many reasons why consultant-developed software often follows this pattern.  Firstly, most clients are plagued with the inability to identify a suitable maintenance resource in a timely manner.  Often this important task is put off until the last minute thus reducing the quality of resources that can be found to take over the project.  Also if the client's resource is tasked with learning the code base in a very short time, they often don't get enough information and are overwhelmed when they are expected to deliver a round of enhancements soon after the consultant leaves.

To increase the chances of a successful hand off, the client resource should be identified soon after the project enters its testing phase to ensure that they have sufficient time to get up to speed.  Also it can help to let the hand-off resource take a crack at some of the lower priority bugs that inevitably creep up so that they get familiar with the code.  Having them get their hands dirty when the consultant is still around to support them can be extremely valuable to the client.

Consultants should also make every effort to develop a maintainable solution that can easily be transitioned.  A complex custom application framework, a cutting edge technology, or an unfamiliar platform can all reduce the client's chances of successfully maintaining their shiny new application.  While it can be appealing to try a new technology or build a new skill set, such decisions often create unnecessary risks for the client and their resources.

So does this mean that consultants should simplify their architectures to Typed DataSets and drag-and-drop GridViews?  Not necessarily. 

Even with the most non-technical clients, a consultant should take the time to explain the important architectural decisions in ways where the risks and rewards are absolutely clear to the client. If a technical decision is made that reduces development time but requires a specialized resource, then the risks and reward of such a decision should be clearly communicated to the client before it's too late to turn back.  Projects often fail because of technical decisions that were made up front later on became extremely costly to support and were ultimately irreversible without re-writing large parts of the application.

Finally, consultants should beware of clients that expect to just pay an invoice and get some working software with very little personal involvement in the project.  No matter how much they may profess that they "just want something that works" they will have always opinions on how it should work. So a consultant is better off setting their expectations of the client's involvement as early as possible. This will ensure both a healthy development cycle for the project and help transition it to a capable maintenance resource that can support any future needs.

I recently had a chance to attend Headspring System's Agile/Extreme Programming boot camp for Advanced .NET developers led by Jeffrey Palermo in Austin, TX.  I had wanted to learn the proper techniques to approach agile development on the .NET platform from an expert and when I found out about this course, I eagerly signed up.

The three day course covered best practices in regards to Agile design and process while incorporating multiple deep dives into Jeffrey's tools of choice when doing development.  The exercises followed a format of first explaining how a normal development process becomes more agile and then having the hands on experience of implementing that process with different tools and concepts.  Jeffrey explained how simple things like source control can become more agile through regular branching and merging and he demonstrated how to do this with TortoiseSVN.

While a lot of software development training is often presented very academically, Headspring's was very hands-on and really pushed everyone to pick up the processes and tools very quickly, just as you would in the real world.

On day one, upon entering the classroom we were told to check out a Subversion repository hosted on Google Code that would house the code for the application that we would be extending over the next few days.  This application was a Work Order management system designed using Domain-Driven Design and built using a Model-View-Presenter implementation with NHibernate serving as the ORM between our entities and the database.  The application also had a suite of both automated Unit Tests and Integration Tests which were regularly run as part of it's NAnt-based automated build script.  If you're curious to see the system, download the Visual Studio 2008 solution here.

Over the next two days, we extended and refactored this Work Order system to support new features and workflows by first writing NUnit tests and then designing interfaces around the problem domain. By focusing our whiteboarding sessions on separating the concerns into smaller pieces that each group could begin implementing, the whole class of fifteen students was able to work as a team to successfully build and test the new features in a just a few hours.  Along the way we touched on many concepts like Inversion of Control by using StructureMap and reliable, targeted Refactoring by using Resharper.

Finally, we ended the class with a review of all of the concepts and tools that were used during the exercises and we identified some of the design patterns that were implemented by the final solution.

I really appreciated that Jeffrey tailored the exercises as per the class's feedback.  Many of the attendees wanted to see more detail on NHibernate so Jeffrey dedicated a lot of time to going over some best practices around NHibernate mappings and he demonstrated ways to optimize the queries produced by it.

There was a obviously a lot more to this course than I could possibly cover in a single blog post. If all of this content sounds interesting to you, I would highly suggest signing up for one of Headspring's upcoming sessions if you are looking for some practical guidance to help you hit the ground running with Agile development.

One final note: If you are considering taking this course, I would recommend familiarizing yourself somewhat with the following tools beforehand: TortoiseSVN, NUnit, and Resharper.  Also, I would recommend having at least a basic understanding of Test Driven Development, Model-View-Presenter, and Inversion of Control. The course moves very quickly and you will have an easier time keeping up if you at least have some working knowledge of these tools and concepts prior to attending the course.

Thanks again to both Jeffrey Palermo and Jimmy Bogard for a great training experience and chance to inundate them with questions as I am known to do!

I've been an avid user of Google Calendar since its inception.  It's been a great tool for personal organization and helps my wife and I to keep track of social engagements, personal events, vacations, and errands. We both have access to each other's calendars and can assign events to each other with ease.

Before I got my AT&T Tilt, I had a phone with no Internet data plan. Luckily, I was able to configure Google Calendar to send me an SMS message as a reminder for any events in my calendar.  This has worked out great.

Now fast forward to 6 months ago when I started working for Telligent.  Like many other companies, Telligent uses Exchange Server/Outlook for resource and employee scheduling.  All of my work-related meeting requests, appointments, and tasks go through Outlook.  Accessing this information outside the office requires an Internet connection so having an connected mobile phone is helpful to keep up on the road.

My Tilt allowed me to access my Outlook calendar wherever I was, but this created an issue of trying to keep my Outlook calendar at work and my personal calendar on Google synchronized.  If I ever had a personal errand or appointment during a weekday saved in Google calendar it would not show up as blocked off in my Outlook calendar and a coworker could unknowingly invite me to a meeting in that slot not knowing that I was busy.  So I did a lot of searching and initially found some very complex solutions to this problem.  None of them worked consistently and often required me to install third party utilities from somewhat untrustworthy sources.  Or they required me to spend money to get automatic calendar synchronization.

Being the stingy person that I am, I looked for a better, free solution and found it in Plaxo.  Plaxo has been around for a while as a contacts synchronization service and has recently dabbled in the Social Networking space. But one of the key features that Plaxo offers is calendar synchronization between Google, Outlook and a number of other sources.  In order to keep outlook/exchange synched up, you have to download a small plug-in for Outlook that you can get via the Sync Wizard on the Plaxo site. 

Once you have everything installed and configured properly, all that is required is to leave Outlook running (as I typically do on my work machine) and it will periodically sync with Plaxo to keep things up to date.

I've been using Plaxo sync for the past few days and it works great.  If you've been looking for a solid method for keeping Google Calendar and Outlook synchronized, this is definitely the way to go.

This post is definitely a departure from my usual style, but since many of us software geeks also happen to be fantasy geeks I thought I would share the recent news that Tor books has announced a new author for the Wheel of Time series of fantasy books.

Ever since Robert Jordan's passing last September, the fantasy world has been mourning the loss of one of its greatest authors.  I myself felt the loss pretty hard since I have been reading RJ's books for over 10 years and it was the first major fantasy series that I started reading.  I've always been an avid reader of fiction but WoT really introduced me to a different type of genre.  I even converted two college roommates into RJ fans back in my third year of college.  These were guys who had never read a book over 300 pages unless they were required to.  To see them voluntarily put down multiple 1,000 page fantasy books definitely speaks volumes of Jordan's amazing storytelling ability. 

The greatest tragedy for Robert Jordan was never completing his epic series.  While working on his 10th and final book, he passed away due to complications with amyloidosis.

The new author, Brandon Sanderson, is a younger author and longtime fan of Robert Jordan.  He's also an avid blogger and he posted a great personal eulogy to Robert Jordan recently.  Sanderson also recently gave an interview to the DragonMount fan website upon receiving the news that he was chosen to be the successor to Robert Jordan.  Here are a couple of my favorite parts of this interview.

In what ways do you think you'll have to shift your writing style to match Robert Jordan's? Will you be trying to write in his "voice", or will you approach the novel with your own?

To attempt an exact copy of his style would, I think, be the wrong move. If I did it poorly, it would feel like an awkward parody. Yet, at the same time, there are some very important reasons people love these books. Depth of setting, detailed descriptions, and complex and lengthy characterizations are all hallmarks of Mr. Jordan's style.

So, I think it will need to be a balance. I intend to be more detailed in my descriptions and linger a little bit longer on side characters than I do in my own work. However, I am not Robert Jordan, and the fans know that. Every author is different, and I think that my style will indeed influence how the text and ideas are presented.

Are there any particular aspects of the book that you think will be especially challenging for you?

The first is the depth of the setting. Though I've read these books several times, there is just SO MUCH to wrap your head around...I'm certainly glad for the Internet and the resources fans have created. I suspect you'll find me on Dragonmount occasionally asking for someone to look up an obscure fact or name for me!

The other item of particular challenge is the worry that I'll disappoint the fans. I am confident in my writing, but. . .wow. This is like being the final man at bat in the last inning of the World Series--I'm the guy who has to step up and either strike out get a hit to win. All of my training, practice, and studies are coming to a head.

I don't want to be the guy who ruined The Wheel of Time. I'll work very hard to make sure that doesn't happen.

Read the rest of the interview here. 

I'm very excited at this news and I'm eagerly awaiting the final book, entitled A Memory of Light, which will be hitting store shelves in Fall 2009.

Themes in Graffiti are very easy to write or convert from existing themes or templates.  The theme on this site is derived from based on the WuCoco theme for Wordpress.  I chose this theme because I liked the look of it and it was also very well organized into sections for the layout of the blog.  These sections were very easy to convert into Graffiti views.

Here is a list of the .php files included in the 2-column version of the WuCoco theme.

Once this theme was converted for Graffiti, it had the following listing of Graffiti view files.  The difference in number of files is based on the number of required views in Graffiti to accomplish the look of the theme in addition to some customizations.  You could use more or less views to convert more of the original theme if you like.

Graffiti uses .view files to denote sections or views of the markup for the site.  In addition to some standard views that Graffiti recognizes, one can define custom views and then open them from other views using this chalk method.

$macros.LoadThemeView(filename)

The benefit of this method of theme layout becomes clear as you begin the process of building the theme.  It becomes obvious where your markup is coming from and you have immediate and seamless control over your each page's HTML output.

So lets begin.  First we'll start by examining the Wucoco theme's index.php file to see how we can separate it into Graffiti views.

Here are the first few lines of the header.php file.

Now we're getting somewhere.  The index.php file calls the header.php which eventually returns the initial HTML markup needed to build the page.  Sounds easy enough.  So let's try converting that code over to Graffiti Chalk.

I've decided that I don't like hiding the important tags for defining an XHTML document in an obscure header file and I would rather expose them up front in my initial view.  Here's how I would define the first few lines of my Graffiti theme's layout.view.

So far I've got my initial HTML tags defined with a few Chalk methods to build the inside of the <head> tag. 
The first macro call to Head() is used to render some of the custom fields that you can set in Graffiti for any custom Javascript, RSD, RSSAutodiscovery, GraffitiJavaScript, and MetaTags.  This is absolutely necessary to ensure that your page will get all the necessary Graffiti markup and script in addition to some of custom fields you can set in Graffiti's control panel.

The second macro call to LoadThemeView() actually loads my custom header view that I defined in another file, header.view.  Here are the first few lines of that file.

The above code allows me to pull in the CSS stylesheets defined by the original theme as well as the site's title and tagline.  The theme also requires some custom javascript that can below this code in a <script> tag.  For the purposes of this tutorial, I have omitted that code.

At this point, we have defined enough views to load the markup for the <head> tag portion of our Graffiti theme. 

So let's move on to defining the views necessary for the <body> portion of the theme. Let's go back to Wucoco's index.php file. 

We took care of the header, but its not clear where the <body> tag is defined yet.  So let's look a little further down the header.php file.

Now it is clear that the opening tag of <body> actually exists in the header view.  Why do this?  Well this theme utilizes a "header" div at the top of the site for an image, navigation links, and search. In order to ensure that all this markup is rendered first, the theme author decided to put inside his header view. 

I chose to re-organize things a bit for better readability, so I went ahead and moved the <body> tag into my layout.view and the rest of the markup into a separate view for Graffiti which I called page_header.view.

As you can see, I adjusted my markup a little bit to play nicer with Graffiti.  I started by converting the static link list into an Unordered List that works with the NavBar() macro. I then added some markup to put in my site's tagline in addition to its title into the top header div.

Finally, I customized the searchform to work with Graffiti.  There was an opportunity to convert this form into it's own view, as the Wucoco theme did, but since I'm only keeping search in the page's header I deemed another view unnecessary.

Now let's go back to my Graffiti layout.view file to see how things look.

Clean and simple.  Now we've got the <head> and the <body> tags as well as the beginning markup for the page.  Converting the rest of the theme is pretty straight forward from this point on by following the same steps as above for the sidebar and footer elements of the theme.

My completed altair theme is available here.  It is licensed under the GPL (as was the Wucoco theme) and you are free to modify it as you will as long as your reference both themes in the comments.  This theme is for development and personal usage only.  I can't officially provide support for it, but if you have any issues that you can't figure out feel free to leave a comment.

For further reading and information on how to write themes for Graffiti, go to http://docs.graffiticms.com.

As Rob announced, Telligent's Graffiti product is now in public beta!  Download the necessary bits here.

I've been running Graffiti both internally and externally for a while now and I can attest to it's excellent usability as it really makes it very simple to get content out there.   Graffiti supports both Microsoft Access and SQL Server so you have some flexibility in terms of how you want to run it.  We are still investigating other databases as well, with a focus on databases that support an easy XCOPY deployment model.

This site is running on SQL Server 2005 and I used an in-development migration tool written by Jayme Davis to migrate my posts over from Community Server 2007.  Jayme has actually released this tool in an unsupported fashion.  Check the comments on his post for the download link. 

One of the great things about Graffiti is that it is really easy to create custom themes for it.  Anyone familiar with theming PHP-based blog packages like Wordpress will feel right at home with Graffiti's theming structure.  No existing .NET experience is necessary.

Look for an upcoming post with my release of this site's theme shortly with some explanations of the how I leveraged Graffiti's theme engine to do the layout.

This post has been a long time coming, but I've joined the latest Telligenti Club and relaunched my blog on Telligent's new Graffiti platform.  Graffiti is our new site application for Content Made Simple.  It is a very lightweight, easy to design and develop site application built from the ground up to address a different market segment than our flagship application, Community Server.

You can read more about Graffiti here.  If you are interested in participating in our private beta, fill out this form and you will receive a link to download the install.

Thanks to Jayme Davis, Rich Mercer, and Scott Watermasysk for helping me get everything up and running.  I'm really excited to use Graffiti and it's definitely brought a lot of fun back to blogging that I haven't felt since my Wordpress days.

A lot has happened in the .NET space since my last blog post  and I have been getting more involved in the .NET community as of late. I will be posting a lot more often from here on out so expect to see a lot of new content in the next few weeks.  Stay tuned!

Fred George, noted Agile Developer and thought leader, had a great post where he described his ideal ratios of developer skill levels when building an Agile development team.

One of the foundations of his theory is that the number of Apprentice or Junior level developers should remain small on any given team.

...bring on apprentices only at the rate they can be productive to the team; otherwise, be courageous and defer the staffing, ignoring what your spreadsheets are telling you.

I can certainly identify with Fred's warnings here as I've had the unfortunate experience of working in a shop which built upside down teams with one skilled senior developer managing 5-7 fresh college graduates underneath them.  The net effect was a very buggy system, poor productivity, and continuous death marches between releases.

As many others have said before, programming is a skilled craft, and thus must be treated as one.  While it's true that almost anyone can learn to hack together some working code, true mastery of the craft requires learning under existing masters.  And for a master, training even one apprentice requires a significant time investment that can often come at the cost of productivity.

In my current role at Telligent, I've had the good fortune of working with a very talented Junior Developer and I've enjoyed helping him go from being a good programmer to being a great developer.  However, it's been quite clear to me that having more Juniors on my team would quickly overwhelm me and begin to adversely affect my team's productivity. I would probably be spending more time on mentoring them and less time on knocking things out of my own task list.

Even the brightest Juniors will not be aware of all the tools, resources, and practices that are at their disposal as compared to a more experienced developer.  In summary, Fred George said it best:

...start your projects with few, if any, Apprentices, and stage them into the project at the rate you can productively absorb them.

I highly advise that you read the rest of Fred George's posts in his series on Masters, Journeymen, and Apprentices.

I spoke with a friend the other day who came to the startling realization that they had become overpaid.  Most people would define being overpaid as receiving a salary above the current market standard for your responsibilities and skill set.  Taking a moniker from a company which shares an office in my building, I have decided to call such an individual an Overpaid Payable.

An Overpaid Payable is a resource whose cost to an organization exceeds the value that the resource provides back to the organization.  In the current market for software developers, the danger of becoming an Overpaid Payable has become greater than ever.

There are many signs that you are being overpaid.  Here are some:

• You have been in the same company with no increased responsibility for 3 years or more despite receiving regular salary increases.
• Your job very often requires long, inefficient and wasteful hours but you are paid handsomely to compensate for the poor planning that keeps you at work late nights and weekends.
• You see high turnover in your company and often see across-the-board increases handed out soon after a few indispensable resources decide to leave the company.

So what's wrong with being an Overpaid Payable?  Being overpaid leaves you vulnerable.  It can give you a false sense of security as you build up your lifestyle around your current salary.  If you can't guarantee this same salary in another, very similar job, then you will have difficulty planning for the future.  Nothing is certain, and if your company is bought out or goes through cost cutting layoffs, it is the overpaid employees who are usually the first to go.  Additionally if you ever really dislike your job, your choices are more limited.

If you're reading this and thinking that you are overpaid and are now stuck, all is not lost.  There are many ways to fix this situation.  The most obvious one is to just leave your current job to take whatever you can get on the open market.  However, this may not be realistic depending on your financial responsibilities, so I would advise finding a way to increase your value while staying in your current organization.  Here are a few ways that I have seen work.

Learn more about the industry you support to gain new responsibilities.  If you write financial software, take the existing financial knowledge you've acquired and improve upon it.  You may find yourself managing a team of new hires with lots of technical knowledge but no industry knowledge.

Build and market your expertise around a product or technology through peer groups.  Being recognized as an expert in your field bestows many benefits, including competitive and repeatable salaries.

Use your existing knowledge to add value to other functions of your business including sales, services, and support.  Your existing knowledge can provide a lot to these other areas in many surprising ways.

In summary, the best way to avoid becoming an Overpaid Payable is to constantly grow your responsibilities and skills to match your salary.  Always monitor your yearly salary increases to see if they come with increased responsibilities and skills.  Undoubtedly, you will have slower years and faster years, but if monitor your career diligently, you'll never need to worry about becoming overpaid.

One of the cornerstones of the Agile Manifesto is Responding to change over following a plan. 

Most of the time, we see this parable being applied to teams of software developers, but not always to the software itself.  After a certain point, the software's architecture becomes rigid and inflexible, and only allows for minute changes to its supported feature set.

This becomes especially true later in the software's lifecycle as its code base matures.  As time passes, most software packages need to be substantially rewritten to support new technology changes.  Such changes can include:

• Newly supported database platforms (e.g. SQL Server to Oracle and MySQL)
• Changing the presentation layer to support a different platform or go native (e.g. Web to WPF and Silverlight)
• Changing the application service layer platform (e.g. J2EE to .NET and RoR)

When designing your product architecture, it is easy to remain platform agnostic in some areas, while exceedingly difficult to do so in other areas.  Additionally, most organizations are limited by time, money, and the expertise of the developers writing the software and thus make quick decisions with limited resources.

Database support is usually the most flexible part of most application architectures as it is considered a best practice to support the big three database platforms.  While this may result in losing some performance benefits specific to a database, most developers are willing to sacrifice these benefits to avoid the excruciating pain later on when support for more databases is injected after the software has been released.

Presentation layers, on the other hand, can be notoriously inflexible as most platform evangelists tend to emphasize Rapid Application Development through the use of platform specific tools.  While these tools can help build a demonstrable application quickly, they sacrifice a great deal of flexibility to do so.  By emphasizing the use of less visible code, these tools tend to hide the inner workings of large sections in the application's architecture.  Thus it is difficult for any developer to successfully emulate the patterns implemented by these tools when the time comes to change platforms.

Service layers are generally the most difficult to flexibly design as this layer is generally composed entirely of platform specific code.   The good news is that of all the pieces of technology that compose your architecture, the Service Layer is the one which tends to have the longest shelf life.  The degree of difficulty involved in changing Service Layers leads most organizations to only change this layer once per decade.  I believe that a degree of inflexibility in this layer is probably unavoidable in most situations.

Expecting to develop a code base that is flexible to every one of these changes is an ideal situation that is nearly impossible for most organizations. 

In turn, most developers are likely to be more successful if they can limit their scope to one platform and leverage the platform specific capabilities to build more efficient, solid code.  Introducing an unfamiliar platform to inexperienced developers can result in enormous costs and heavily impact productivity.

However, there are significant advantages to making your architecture agile as it can make you better prepared for unforeseen changes down the road.  These changes may include:

• Requests for new platform choices from customers
• Emergence of a competitor with greater platform support and thus a wider audience
• Staff changes resulting in gained or lost technical expertise

Building a more Agile architecture is indeed a daunting task, but I firmly believe that the benefits outweigh the risks.  If it may not be possible to make your first product architecture an Agile one, the lessons learned from building it should certainly be utilized when building a second, more Agile architecture.

Further reading:

Jeff Palermo's blog post - Focus on the Core

Refactoring Databases: Evolutionary Database Design

Rob Walling had an amazing post where he described his experiences and frustrations during his career when moving  from senior software development roles into management roles.

Much of Rob's frustrations stemmed from losing the creative satisfaction one gets from writing code despite gaining the money, power, and respect generally associated with higher level management roles.

This post struck a chord with me because I had many of the same thoughts while I was a management consultant.  I saw many colleagues that were great developers become terrible managers.  Many of these former developers were so accustomed to the fine degree of control one wields with code that they had forgotten that people are not as easily manipulated.  Out of frustration with this loss of control, many of these former developers resorted to becoming Taskmasters and were very disrespectful to their subordinates.  Much of the reason I left big consulting was because of not wanting to go down the same path.

However, things are not all bad for those who aspire to get to management but have some anxiety about not coding.  I have recently met a few rare individuals who are very successful at both the management side of things while still feeding their creative side by doing some programming work on the side outside of their management-based day job.  The work they do on the side may be in the form of User Group Contributions, Open Source Contributions, or just general on-the-side consulting work for friends and former colleagues.

It's been my experience that these types of managers are generally even better at their day jobs because they stay connected to the technology they are managing and are often very involved in the communities revolving around the same technology.  Additionally, they often have less trouble finding and hiring good developers due to their large people networks.

As one would expect, such outside activities usually require sacrificing some personal time.  But they give an individual the creative fix of coding while providing the prestige gained by going into management.  So for those who are willing, it's a very good option if you can survive with a little less sleep :)

Dare Obasanjo started a thread listing things he learned about software while in college and Scott Hanselman extended it by adding three more things he learned in college and three things he learned outside of college. 

Both bloggers had some great points and I recommend reading both posts as well as the comments.  But I thought I would chime in to the discussion with my own list.

Things I Learned about Software in College

1. If getting things working is the primary goal, most programming assignments can be completed by one person in a reasonable amount of time.
2. Reaching the "ah ha!" moment in programming is very important.  Until you reach that moment, every programming assignment will be marginally tougher.
3. Don't work on assignments with the smartest person in the room.  Immediate learning by imitation doesn't work too well in software.   Find your own way that works first, and then improve your style by emulating others.

Things I learned about Software after College

1. Most good software is built by teams, not individuals.  If you don't understand this point, you'll always be a second-rate developer.  No matter how well you hack things together.
2. Being a software professional truly means being a lifelong learner.  Chances are the tech you cut your teeth on in college will be obsolete soon after graduation.
3. True happiness as a software developer lies in liking those who you work with, not liking those who you work for.  Some of my best work experiences were great because of the amazing colleagues I had a chance to work with, not the company or brands I worked for.

After just recently promising to bring Microsoft's Silverlight to Linux by years end, Miguel De Icaza, the project leader for Mono, has ported significant portions of Silverlight in only 21 days.  He chronicled this effort in a recent blog post.

The past 21 days have been some of the most intense hacking days that I have ever had and the same goes for my team that worked 12 to 16 hours per day every single day --including weekends-- to implement Silverlight for Linux in record time. We call this effort Moonlight.

Regardless of what you may think of the viability or futility of the effort, it is awe-inspiring to see a group of developers be so motivated to work towards a goal.  To go through this level of effort despite being disliked by both sides shows a real passion that most developers lack.  Kudos to Miguel and the Mono Team for this very significant achievement.

Silverlight has been on the tip of a few tongues at Telligent so it's great to see that our clients won't lose even a small percentage of their users if we building it into our products.

Nick Malik wrote a post entitled "Mort and the Economics of Unmaintainable Code" where he espoused the belief that re-writing code can be more economical than writing good, maintainable code in the first place.

Rather than look at "making code maintainable," what if we look at making code free.  Why do we need to maintain code?  Because code is expensive to write.  Therefore, it is currently cheaper to fix it than rewrite it.  On the other hand, what if code were cheap, or free?  What if it were cheaper to write it than maintain it?  Then we would never maintain it.  We'd write it from scratch every time.

The post, like others stems from the discussion around Microsoft promoting drag-and-drop controls for Rapid Application Development in .NET.

My concern with this line of thinking is that it assumes that the code only accomplishes one thing: making the application function.

The reality is quite different.  The code very often provides much more than pure functionality.  Often the code is the only maintained artifact that fully describes the current business process or workflow supported by the application.  These days most developers aren't creating complex UML diagrams or relying on elaborate comments.  It has been my experience that when requirements and business processes change, the code is the first and last thing to be changed.  When looking at most software, rarely do you find supporting documentation and other artifacts that are maintained as well as the code.

Code drives business value far more than most other artifacts and is thus maintained far better than documentation.  While this may not be true in every organization, it has been my experience that any organization that finds itself rewriting code will typically rewrite significant parts of their business processes as well.

Given the choice between rewriting a business process and writing maintainable code in the first place, I think it's clear which is the more economical approach.