The common mentality with respect to creative and technology process integration involves a relatively solid line that separates the two disciplines and work streams.  Creatives do their concepting, draw up wireframes, create visual assets, and then toss them over the line.  Technologists pick these up, create the front-end HTML, create the back-end code, and wire them up to create the system.  That is an extremely over-simplified description of both sides of the line - but it represents the general perception of many clients and peers in our industry. 

The agile movement has made great strides toward integrating project teams.  But the focus here has been on bringing business and end-user representatives into the process and advancing the project through small, iterative cycles.  (Again, a dramatic over-simplification.  I'm a huge Agile proponent.)  The iterative cycle keeps all disciplines (plus business stakeholders and users!) engaged throughout the project.  Great progress!  But, within an iteration, the line often remains.  Both the creative and technical teams are tightly engaged with the business and user representatives.  But they're only loosely engaged with each other. 

There are many reasons for this.  On a given project the creative and technical teams are often from separate internal organizations - at best.  At worst, they're from separate companies altogether.  Beyond that, they often think, talk, and act very differently - making it hard to relate.  Right brain, left brain stuff.  There is hope, however. 

One of the most satisfying things about working with Avenue A | Razorfish is experiencing the blurring of the tech/creative line.  As a company with strong marketing, creative, and technology capabilities that are integrated on many projects, we've learned through experience how to work and communicate with each other.  That is one of our strongest value propositions to customers.  We've proven that the line can be blurred and there is significant value in doing so.  However, it is within the last year that I've seen the most substantial fading of the line.

This can be attributed to the popularity and demand for rich Internet applications.  RIAs require a much greater level of cross-discipline understanding and cooperation.  Windows Presentation Foundation and XAML have done the same thing for desktop applications (and the web, with Silverlight).  There is a great whitepaper on the WPF designer/developer workflow entitled The New Iteration.  Definitely worth a read.  It specifically addresses WPF, XAML, and the Expression tools, but many of the points apply more generally to RIAs, as well.  The value proposition is well stated:

"Ultimately, the new collaboration means that iteration of a project can now happen in a much more fluid way. There is no longer the “one-way street” where a change to a specification downstream means a radical reworking of the entire application. The result opens up new possibilities for collaboration between the designer and developer, where a kind of dialogue is possible with the potential to foster greater creativity."

It is that last point - the potential to foster greater creativity - that excites me the most.  Technologists are often in a restricting role.  We have to set boundaries that the creative team must work within so that we're able to deliver on their promises.  Rather than promote cooperation and collaboration, this can create an "us versus them" mentality.  However, with RIAs I have noticed a great change.  Technology and creative teams are pushing each other to expand the solution horizon, rather than constrain it.  Both teams are equally invested and sharing their unique perspectives, which results in far better solutions. 

It may be intuitive that a shared sense of ownership, varying perspectives, and close collaboration will have positive results on a project.  As a consultant "back in the day", when the Internet and HTML were new, I saw the same level of enthusiasm and collaboration between technical and creative teams.  But as technology and creative techniques matured, the tech/creative line solidified.  As a result, the solutions became somewhat cookie-cutter.  That's not to say companies weren't launching sites with great creative and technical work.  But truly remarkable solutions are conceived when both the technical and creative limits are stretched and combined to produce something truly unique.  I'm thrilled to be back in this sweet spot.  The industry as a whole seems to be following suit.  But unless a deliberate effort is made to avoid falling into comfortable patterns, truly remarkable solutions may once again join the endangered species. 

The Patterns & Practices group has published a beta version of their Team Development with TFS best practices guide.  According to J.D. Meier:

It's our Microsoft playbook for TFS.  This is our guide to help show you how to make the most of Team Foundation Server.  It's a distillation of many lessons learned.  It's a collaborative effort among product team members, field, industry experts, MVPs, and customers.

The contents (360 pages) include:

Parts
Part I, Fundamentals
Part II, Source Control
Part III, Builds
Part IV, Large Project Considerations
Part V, Project Management
Part VI, Process Guidance
Part VII, Reporting
Part VIII, Setting Up and Maintaining the Team Environment

 

Chapters
Introduction
Ch 01 - Introducing the Team Environment
Ch 02 - Team Foundation Server Architecture
Ch 03 - Structuring Projects and Solutions
Ch 04 - Structuring Projects and Solutions in Team Foundation Server
Ch 05 - Defining Your Branching and Merging Strategy
Ch 06 - Managing Source Control Dependencies in Visual Studio Team System
Ch 07 - Team Build Explained
Ch 08 - Setting Up Continuous Integration with Team Build
Ch 09 - Setting Up Scheduled Builds with Team Build
Ch 10 - Large Project Considerations
Ch 11 - Project Management Explained
Ch 12 - Work Items Explained
Ch 13 – MSF Agile Projects
Ch 14 - Process Templates Explained
Ch 15 - Reporting Explained
Ch 16 - Team Foundation Server Deployment
Ch 17 - Providing Internet Access to Team Foundation Server

Microsoft recently published guidance for branching and merging with Team Foundation Source Control.  Branching/merging can be a major headache if not thoughtfully planned and managed.  However, it is a valuable and necessary tool for parallel development activities.  Examples from Microsoft:

Example 1:
A team of 40 developers is building an application. There are four feature teams, each led by a development lead. The feature teams vary in size from two developers to fifteen developers. The milestones for each feature area also vary. There needs to be a mechanism to provide isolation to each of the feature teams while allowing for changes to the common areas of the application in a reliable and controlled fashion. Branching is a very good solution here; this is referred to in this document as Branching for Feature Team Isolation.

Example 2:
A development team has just gone live with the first release of a Web site. The development team has started working on the next version of the site, but a critical bug is found by an important customer on the live site. A strategy needs to be introduced to allow the core development team to continue evolving the next version of the site while bug fixes can be made for maintenance of the released site. There needs to be a mechanism to isolate these two work streams. This is referred to in this document as Branching for Maintenance.

You can read the guidance online, or download a PDF version.

In my last post, I tried to emphasize the business aspect of the technical lead role in enterprise software development.  You may be a technical genius, but if you have no interest in business you should redirect any ambitions you have for technical leadership and perhaps pursue a specialist role of some sort.  You can't divorce business objectives from any decisions you make as a technical leader. 

I originally intended to get into technical design and development best practices with this post.  But before I talk about what they are, I want discuss why they are important.  In discussing best practices, I doubt seriously that I will enlighten anyone with something they haven't already heard at least once before.  However, it would seem their importance is not appreciated by many who choose to ignore them.

There are actually at least two business domains that you must concern yourself with as a technical lead.  The first and most obvious is the business (or line of business/division) you are serving - your client.  The second is the IT organization.  IT can quickly degrade from a positive investment to a negative expense if the IT organization is not run as a business of its own.  Running IT as a business is a current mandate of any CIOs worth their salt.  Unfortunately, the business objectives of the IT organization are often discounted or disregarded by project teams.  The majority of the team will be narrowly focused on the current project, or even more narrowly, on the current feature/deadline/milestone/etc.  However, a good technical lead will keep IT business objectives in the forefront and balanced against the client's business objectives.

It is the pursuit of IT business objectives that has cultivated the current array of software development best practices.  Like any business, at the most basic level, IT organizations aim to maximize their production while minimizing costs.  The majority of best practices for software development process and technique were developed in pursuit of these goals.  The current industry focus on agile methodologies, design patterns, test-driven development, and continuous integration (among other development techniques) has emerged through the pursuit of these objectives by hundreds of industry experts.  It is the consensus of the most qualified and experienced people in our industry that following these practices provides the best chance of executing projects predictably and efficiently while minimizing the long-term costs of operating, maintaining, and enhancing the systems we develop. 

Re-read the second half of the sentence above, starting with "while…".  It is not just about meeting deadlines.  The initial development cost for most enterprise systems is dwarfed by the long-term costs.  Yet many technical leaders will easily and regularly make decisions in the interest of short-term goals and priorities without consideration of the long-term impact.  For some, now is always more important than later.  But that is often the wrong choice.

Let's use an example.  Assume you're buying a custom-built car.  You are given the choice to drive off with it today and get 10 miles per gallon or wait a couple weeks and get 40 miles per gallon.  All else being equal, what would you choose?  What if having it today meant you would have to leave it in the shop for a few weeks each time you need an oil change?  Or a few months each time you need new tires?  What if you had to pay $200 an hour for each technician that worked on your car during those weeks?  Seems like a pretty easy business decision - to me, anyway.

Of course, the real world isn't quite so simple.  Missing a deadline can have significant business costs and implications, as well.  But the point is all business factors must be considered - long term and short term - for both the client and the IT organization.  Even business and IT managers can loose sight of this.  A good technical lead will aggressively defend doing the right thing for the business - even when the business occasionally doesn't see it.  In the end, you will gain respect and credibility whether they followed your guidance or not. 

Okay, I'm hung up on this business stuff and still haven't discussed anything truly technical yet.  That's because in my experience mentoring technical leads, this is by far their biggest obstacle.  They have already proven their technical aptitude and ability to meet deadlines, or they wouldn't have been promoted to a lead role.  (Yes, I know... that's not always the case.)  But for many of them, being a technical lead just means more authority.  For the most part, they'll continue doing what they were doing before, but they'll get to make decisions on their own and tell a few others what to do.  Many will think industry best practices are just hype and won't take the time to learn them.  They will continue to keep their business blinders on and will make decisions based on personal interest, the path of least resistance, or serving the crisis of the moment.  With that mindset; they will inevitably fail.  Or, worse yet, the business will fail. 

If done right, the technical lead role comes with a huge amount of additional responsibility and a small amount of additional authority.  You may be one of the few that knows better than the majority of experts in our industry.  I'm certainly not.  And if you aren't, you will be best served by learning and embracing the current industry best practices.  In my next post, I'll discuss some of those practices. 

I'm presently working with a client to help mentor and transition one of their senior developers into a technical lead role.  I figured I'd share my thoughts with the community at large.  So this is the first of what I expect to be several posts about the role and responsibilites of a technical lead.  (I don't make a distinction between architects and tech leads.  In my opinion, they are just variations on a theme.)

The traditional definition of a technical lead in IT goes something like "an individual with responsibility for the technical architecture and design of a system or sub-system and for leading a development team to implement it within the time allotted."   However, that definition does not adequately represent the business aspect of the role.  In enterprise software development, a technical lead is one who has responsibility for pairing business objectives with technical solutions.  You serve as a bridge between technologists and business people.  You must help the business make educated decisions based on technical options and constraints - and must help the development team make educated decisions based on business objectives and constraints.  (Note the use of 'objectives', rather than 'requirements'.)

To be affective, you must work hard to stay intimately familiar with both the business and technical domains.  Many people fail in this role because they consider themselves, at best, loosely associated with the business.  That loose association is represented solely by the requirements they are given to implement.  However, there is a significant distinction between business requirements and business objectives. 

When interviewing technical lead candidates, one of my standard questions is: "Which is more important - delivering a solution that meets client expectations or one that precisely delivers on all the requirements?"  I suppose this is a spoiler for any future candidates that read my blog, but the answer is meeting expectations.   Unfortunately, most candidates make the wrong choice.

Requirements represent a means to achieve one or more business objectives - not the objectives themselves.  And, more often than not, requirements are incomplete and open to interpretation.  If you don't understand the business objectives, you will likely miss-interpret the requirements.  The expectations of business representatives will be aligned with business objectives, not software requirements.  If you deliver a system that addresses all the requirements but is not aligned with business objectives, you will have failed from the client's perspective.  Sure, you can defend yourself by holding the requirements up as a "contract" for development.  That will likely stand up in court, so to speak.  But that adversarial attitude completely misses the point and fosters bad will between business and technology organizations. If you're a consultant, that will likely result in forgone future business.  If you're an IT employee, it will make your next project more difficult.  Regardless of your employment arrangement, you are partnering with a business organization to solve business problems.  A good technical lead will invest time in understanding the business domain and objectives and will help interpret, define and revise the requirements to make sure the end result is aligned with the business objectives.

If you are in the enterprise software business - whether you are a direct employee, contractor, or consultant - all of your decisions should be guided by business objectives.  Fortunately, that does not conflict with making good technical decisions.  In my next post, I'll extend the discussion beyond requirements to technical design.

Well, I finally got my template updated.  This was my third experience starting a site from a design template from templatemonster.com.  I have to say, it truly is a great deal and good experience. 

I have worked with many clients to conceive and create new sites.  The initial stages of defining and agreeing on a general look and feel are often very difficult and frustrating.  Describing such "soft" requirements can be difficult, especially when clients may not even know what they want.  But once they find something they like, they become very engaged and active editors.

To avoid "analysis paralysis" and ensure forward progress, it is common practice in this industry to present clients with a limited set of initial "comps", from which they must choose one, and then allow a limited number of edit rounds.  By taking advantage of commoditized design templates, clients have a much broader set of comps to choose from and can save a great deal of time and money on the initial art production.

The common concern regarding use of these templates is uniqueness, or lack thereof.  However, unless branding is a major priority (beyond the obligatory logo), this really shouldn't be an issue.  Most sites are created with an emphasis on content and/or functionality with very little investment in design aesthetics.  However, for that same minimal investment in templates, you can have a very impressive design.

Given the size of the Internet, the chances of someone encountering multiple sites that leveraged the same template are minimal.  When browsing the templates, it indicates how many times a given template has been downloaded.  When you purchase, you have the option to buy semi-exclusive rights to the template, which removes it from the catalog but doesn't affect anyone that bought it before you. 

And finally, a template is just that - a starting point.  As your site is customized and evolves it will become unique and resemblance to the original template will fade.

I started from the Studio7 template, pictured below.  I really like the style and feel of this template.  However, as mine is primarily a blog site, I didn't really want such a heavy header and menu bar.  I wanted to keep the feel but make it a bit simpler and put more emphasis on content.

So with a little Photoshop, Flash, and HTML work, I came up with this.

With my customizations, I think this site stands on its own and I'm not concerned about someone encountering another site that used the same template.  In the remote chance that does happen, they may recognize the plasma screen, but I don't think I'll be any worse off for it. 

(Oh, and I have no relation whatsoever to templatemonster.com or any other such site.  I'm just a happy customer.)