Under the Hood of Content Management Systems Part II – The CMS Landscape

Choosing the right Content Management System (CMS) can significantly improve the way an organization manages and shares information internally and externally. This sharing of information, implemented correctly, can lead to critical improvements in sales, support, partnering, hiring, marketing, and investor relations.

The number of Content Management applications available on the market today is staggering. All of the major software vendors have their own version of a CMS as do many midsize software companies. This breadth of available CMS software offers a wide range in functionality, complexity, and price. There is now a CMS solution for every business need. Finding the ideal CMS solution that fits the specific needs of the organization’s content strategy is critical.

Before any Content Management System is demonstrated or chosen, the organization should first examine all of the business requirements for such a system. Long term goals should be defined for the CMS and factors such as IT resources, training needs, integration needs, hardware, content writers, and web developers should be considered. By not fully taking into consideration the business needs, organizations may select the wrong CMS and then be forced to spend large amounts of money to customize it to fit business requirements. It is better to fully research the intended uses of the system and purchase a CMS that already fits specific business requirements. Costs in licensing, installation, configuration, and maintenance are major factors in determining which CMS solution is right for your objectives. In the long run the CMS should be modeled around your organization’s business process rather than the other way around. A well thought out CMS strategy will also help in getting buy-in from executive management and employees.

The following is a general list of CMS solutions on the market today. These systems, which range in price from free to approximately $500,000 in licensing fees represent a representative sample of the types of CMS solutions available.

Please note: the categories and systems below are not exclusive of each other. Many products span multiple categories.

Enterprise Content Management Systems

For mid- to large-size organizations with dozens to hundreds of staff writing and managing content, an Enterprise Content Management System (ECMS) will automate tasks involved in managing large scale content deployments. These systems are powerful applications with custom workflow controls, powerful templating modules, object caching, clustering, and documented methods for integration with organizational applications. Most Enterprise Content Management Systems will also have modules for detailed reporting, user groups with specific roles/permissions, and versioning.

Lotus Workplace Web Content Management

This system, previously called Aptrix, provides a tight integration with both WebSphere and Lotus / Domino systems. LWWCM has one of the most intuitive interfaces on the market allowing for easy training and maintenance. Customizable tabbed forms enable users of most technical backgrounds to easily create and manage content across the site. This system dynamically renders static content for the live site. As a fairly new system to IBM, this CMS is currently lacking good documentation and training programs.

http://lotus.com/products/product5.nsf/wdocs/homepage

Microsoft Content Management Server

The largest software provider in the world has come out with many powerful server applications for its business customers within the last several years. The Microsoft Content Management Sever is a powerful CMS, based on NCompass purchased in 2001, for organizations that utilize the Microsoft Platform. This system provides one of the best application frameworks on the market with well documented APIs, open code, clear database integration, and industry standards in interoperability and formatting. Editing tools for the CMS integrate with Internet Explorer allowing users to edit the website from within the browser. In their typical fashion, Microsoft is coming from behind in this industry making significant improvements in this system with every iteration.

http://www.microsoft.com/cmserver/

Global Content Management Systems

Multiple web sites with content in various languages targeted at a variety of audiences around the globe can be difficult to manage. Powerful CMS solutions with strong templating components, Unicode compliance, distributed architectures, complex workflow, and multifunctional formatting tools allow managers within organizations to manage web sites that provide information to users around the globe with localized designs and content. Significant improvements have been made in this category of content management over the past two years as more and more companies strive to enable global companies to cater to worldwide customers and employee bases. These systems are designed specifically for large multinational organizations with thousands of employees, hundreds of thousands of documents, and websites with thousands of pages.

Interwoven TeamSite

For many organizations, TeamSite is the Content Management standard. With the latest release, TeamSite 6.0, Interwoven has enabled users to customize the interfaces of its powerful Content Management Solutions. With tools for versioning, user security, web content editing, document sharing, media administration, and publishing – TeamSite has become one of the most recognized names in web site management. Extractable is an Interwoven partner.

http://www.interwoven.com

Stellent

Stellent’s Content Management System is an end-to-end solution that delivers content quickly. Flexible tools for templating and workflow make it possible to maintain growing volumes of content from a wide variety of sources and make that content accessible across an entire enterprise. Stellent’s powerful versioning functions are also ideal for application deployments. One of the powerful functions that makes Stellent stand out in the CMS world is its integration with the underlying folder structure on the server. User can save documents from editors (MS Word) to a directory on the server and the CMS will automatically categorize, format, and upload the document to the system.

http://www.stellent.com

Application Content Management Systems

If a site requires dynamic functionality such as ecommerce, CRM, personalization, security features, and/or integrated applications, a Content Management System specializing in application management and integration is required. There are many Application Content Management Systems that easily integrate content tools with enterprise and e-business applications for a seamless solution. As the web becomes more and more functional, sites are requiring robust functional components with dynamic data and more and more Content Management Systems are starting to have application management components.

Vignette

Vignette V7 is an integrated platform of applications and web services to create and manage information, business processes, portals and applications. The Vignette Command Center is a configurable, role-based management console that enables business and technical users to manage virtually all of their electronic assets and delivery applications through one interface. What Vignette makes up for in developing dynamic sites, it lacks in versioning. Vignette users often need to write or integrate their own versioning system.

http://www.vignette.com

WebSphere Portal

IBM’s WebSphere is more of an Application Server than a Content Management System. But this powerful set of applications has several impressive Content Management features. With WebSphere organizations can create secure customer portals with dynamic content that are easily managed by users throughout an organization.

http://www-306.ibm.com/software/info1/websphere/index.jsp?tab=products/portal

Document Content Management

Large organizations that share content with partners, internal staff, distributors, and/or customers have content in many different formats. A powerful Document Content Management System allows enterprises to share information in virtually any format over the web, across the network, via email, and/or through powerful versioning systems. Collaboration tools integrated directly with the document creation process allow multiple people within an organization to contribute content to the same document in well-defined and easy to use workflow processes. Powerful collaboration tools enable users to not only create content but associate all available meta information with processes and content components.

Documentum

Document, now a division of EMC, has for a long time been one of the biggest players in document management. Their powerful tools allow large organizations to automate many of the functions involved in collaborative information creation and management. Tightly integrated tools allow users to create documents, or components of a document (ie. an Executive Summary), in most popular formats and selectively/securely share this information across or outside the organization. With a large focus on customer support, Document excels in offering training, documentation, and consulting services.

http://www.documentum.com

FileNet

One the first players in the content management market, FileNet is deeply ingrained in a lot of large organization information sharing structures (80 of the Fortune 100). FileNet tools are built around the needs of large diverse organizations and great for implementing standards in content structures, workflows, and storage.

http://www.filenet.com

Specialty Content Management

Some CMS solutions are built with specific content in mind. Unique pieces of content such as Property Leases, Digital Movies/Music, and Electronic Design Automation content have distinct rules, workflows, and management requirements. For organizations with content that requires management components different from traditional CMS solutions, specialty systems may be the answer.

InterWoven MediaBin

MediaBin is a Digital Asset Management (DAM) solution used by marketing organizations to manage large amounts of digital assets (Images, Movies, Music, Collateral Templates, etc) and marketing content used to promote products and brands. With MediaBin, extended marketing teams easily catalog, manage, transform, and distribute digital assets, including photographs and logos, audio and video, datasheets and ads, presentations and documents.

http://www.interwoven.com/products/dam/

SumTotal Learning Content Management system (LCMS)

Formed from the merger of Click2Learn and Docent, the SumTotal Enterprise Suite helps organizations manage the content used to educate audiences such as employees, partners, and customers. This robust system provides friendly tools for managing learning content such as movies, manuals, and presentations. This system not only focuses on sharing information, but also improving productivity.

http://www.sumtotalsystems.com/

Custom Content Management Systems

All Content Management Systems require developers to perform configuration and integration before they can be used by an organization. In many cases unique requirements or budgetary constraints make out of the box Content Management Solutions inappropriate for achieving the organization’s business goals. Custom CMS solutions enable organizations to satisfy specific critical requirements and maintain a high level of future flexibility. There are development tools such as Rich Text Editors (WYSIWYG), workflow components, and versioning libraries that make custom CMS development the right solution for many organizations. OpenSource CMS solutions, such as OpenCMS and the Apache Cocoon Project allow developers to customize pre-built CMS functions to fit specific needs. Examples of Custom CMS solutions and components include:

• http://cocoon.apache.org/


• http://webword.biz/


• http://www.opencms.org
  

Entry Level Content Management Systems

Smaller organizations with simple objectives require low priced CMS solutions that fit the basic requirements for managing websites without related IT costs. Systems in this category require a high level of easy-to-use interfaces that do not necessitate classes and technical support for implementation. Most CMS solutions in this category will lack complex workflows, detailed reporting, clustering, and/or personalization. Instead these systems will focus on the core functions such as editing and publishing. Entry level systems have come along way in the past two years and are a great fit for a wide variety of organizational needs.

Macromedia DreamWeaver/Contribute

This excellent package provides friendly editors with simplified tools for deploying data to public websites. DreamWeaver has a well-deserved reputation for being one of the best WYSIWYG (What You See Is What You Get) editors on the market. Advanced configurations allow developers to create security around template components to ensure specific users and editing only the content that pertains to them. Contribute brings workflow and publishing components to the DreamWeaver editor to enable users with varying levels of technical backgrounds to manage web content.

http://www.macromedia.com/software/contribute/?promoid=home_prod_contribute_082403

Ektron

Ektron was one of the first companies to bring Rich Text Editing to the web and has since created several components to perform common content management functions. Ektron has such a demonstrated lead in the WYSIWYG market that many of the higher end CMS tools mentioned above have integration options for Ektron components. The company's entry-level software costs below $500 for five users, but this version comes without publication user/group permissioning and deployment scheduling.

http://www.ektron.com/cms300.aspx

If you have any questions about CMS options or need assistance in researching your company’s CMS requirements, please contact us at mtsai@extractable.com.

- Ming Tsai

Additional Resources - CMS Vendors

• Atomz


• BroadVision


• Documentum


• Ektron


• FatWire


• FileNet


• IBM WebSphere


• Ingeniux


• Interwoven


• Lotus Workplace Web Content Management


• Macromedia


• Microsoft


• Midgard


• Objectify


• OpenCMS


• Oracle


• PaperThin


• Percussion


• Red Bridge Interactive


• SimplyCMS


• SiteWorks Pro


• Stellent


• SumTotal Systems


• Vignette


• WebWord


• Zope

Other useful sites:

1. http://www.Cms-forum.org


2. http://www.cmswatch.com

 

Under the Hood of Content Management Systems - Part I – What is a CMS?

Content Management Systems - these three words can create feelings of elation or frustration in internet professionals depending on their past experiences. Loosely defined, content management systems (CMS for short) are applications designed to make content publishing online easier and/or more structured. In the past several years, the term has been applied to a wide variety of software and database packages offering a wide spectrum of services and functionality.

Our two-part series of articles is designed to shed some light on CMS - its purposes, functions, broad categories, and current market players. This article begins with the basics, describing the functional components of content management systems. Part one is intended as a primer for people who want to understand how content management systems can help their business.

In part two, we will cover the broad categories of CMS. We will discuss the differences between enterprise platforms and their smaller competitors. We will also look at low-priced and open-source options. Finally, we will discuss some specific software packages that stand apart in a crowded marketplace.

What is Content Management?

As any web manager can attest, keeping web site content fresh is a tricky business. In many organizations, the individuals that seek to add new content are different than those that create content, who in turn are different than those that put it on the web site. The back-and-forth between owners, contributors, approvers, producers, and web owners can mean real delays in posting timely content, frustration that small changes take forever, and a significant investment of man-hours when multiple people are involved. Compound this with the integration of third parties, such as an interactive agency responsible for content production, and the end result may be a web site that stagnates with a lack of fresh content.

Content management systems are designed to increase efficiency in content publishing. Some systems are very tactical, making it easier for non-technical users to publish directly to the site (thereby obviating the role of "producer"). Others offer more comprehensive content workflow, making it easier for approvers and owners to be involved. The largest systems provide a comprehensive framework that integrates across the enterprise to deliver content to multiple sources, including a web site.

The Functions

In order to understand what content management systems do, we will describe their functionality starting with the most basic components. We will build on these to demonstrate how more and more robust systems supplement CMS functionality with complex management processes.

Content publishing - The heart of any CM system is the ability to publish content to a web site or intranet. At its most basic level, this provides users with the tools necessary to input content, view it for quality assurance, and push it live to the site. Typically, this means that a specific type of content is put in a specific place on the site in a specific format. A good example of this is a press release.

Press releases must be posted very rapidly depending on their nature. The originators of press release content (say, the investor relations group) may not be affiliated with the web group and may not be technically savvy. A simple form-based content publishing tool allows the content originator to use an online form (typically intranet-based with password protection) to input specific content into pre-defined areas. For a press release, these areas might include "title", "byline", and "body content". When users fill out the form and click the submit button, they are presented with a preview of the page. The content is automatically placed in specific areas of the page, formatted with the appropriate fonts, "wrapped" in the correct site design, and located in the correct part of the site architecture. By clicking "approve", the content is pushed live and the process is complete.

Even simple content publishing tools can have relatively complex technology on the back-end. The system must incorporate functionality to effectively link the site from the site navigation or an index page. In the above example, the "title" field will be used as a link from the press releases page of the site and incorporated dynamically. Many content publishing tools use databases to manage the content. Others will dynamically create "flat files", essentially simple text documents, which are read by the site.

A key limitation of this type of system is that it applies to specific types of pages that need to be updated frequently, such as press releases, events, and announcement sections of a site, rather than publishing to any page on a site. Full-site publishing (below) addresses this need.

WYSIWYG editing

Many types of software packages exist allowing WYSIWYG (What You See Is What You Get) web page development. Built as fully functional software applications, these tools allow users to build web pages without any real knowledge of HTML. Pages are built using a Microsoft Word- or PowerPoint-style editor, allowing users to format content and imagery on the page.

Some content management systems offer formatting controls allowing users to modify how content looks on the page. This can be as simple as allowing font choices, color choices, bold/italic/underline, etc. It can be as complex as full WYSIWYG editing allowing robust control for image placement, tables, and forms. Some WYSIWYG suites have incorporated many of the other functional components we describe in this article, turning them into functional CMS applications.

Full-site publishing

More robust systems take this concept of content publishing and extend it to all pages of the site. Essentially, the methodology for this type of system is similar to content publishing (above) with the addition of tools to allow users to access multiple pages across the site. Users typically access a directory tree to find the site area or specific page to modify. All of the modifiable pages are template-based, meaning that they share design templates that dictate content location, image location, etc. Multiple templates can be used for different areas of the site.

Integration of site

Wide CMS tools is serious business. This is best done as the site is being built out for the first time - retrofitting a site to integrate CMS can often mean rethinking how content, imagery, and navigation are used.

Workflow

Once a system is put in place allowing users to add content to a site, a key corporate requirement quickly presents itself: oversight. Workflow processes provide the communication framework allowing system-based approval processes that are critical for effective site management. In many corporations, approval requirements are varied. Even in a simple corporate structure, once a contributor creates new content, it may need to be approved by the content owner, legal, and site administrator. If any one of these approvers asks for revisions, the process must repeat itself. Workflow systems help to make this process efficient and easy. When a contributor submits content, an email is automatically sent to a predetermined approver or group of approvers. The approver reviews the content in the system and can either approve or reject it. If rejected, it is automatically sent back to the contributor with comments. If approved, it moves to the next person in the approval chain, and so on.

Because these systems are email-based, reviews and approvals can be completed very quickly, reducing the time that manual approvals can take. These systems also provide a documentation trail that many corporations now require for corporate accountability.

Version control

Version control provides a fail-safe mechanism for rolling back versions of content. If content is pushed live that is incorrect, site administrators can use version control systems to immediately go back to a previous version. These systems will often archive content indefinitely, allowing a content trail that can be used for corporate accountability. The biggest benefit of version control is speed. Fixing an error on a page can be as easy as pushing a button.

User Management

In a complex site development environment, system users must have a variety of permissions. These are typically assigned both vertically and horizontally. Vertical permissions define the role that users have as they access the system. A simple role hierarchy might be:

¨ Author - An Author is permitted to create and modify content. All content modifications by an Author must be approved.

¨ Editor - An Editor has same permissions as an Author. In addition, an Editor is permitted to approve/deny content modifications from Authors. Editors may be able to promote content to the live environment.

¨ Administrator - An Administrator has all of the permissions as the above two roles. In addition, Administrators may create/delete/modify users as well as modify template-based content such as navigation.

Horizontal permissions typically permit users to access different sections of the site. Corporate Communications users, for example, may only be permitted to modify content within the Investor Relations and About Us sections of a site. Corporate Communications users will be a mix of Authors and Editors. Administrators typically have all-site access.

User management not only defines the permissions that users have, but usually provides the security infrastructure governing site access. This includes password protection and integration with corporate access protocols.

Multiple Combinations

The CMS components described above represent the range of functionality that different systems offer. How individual CMS packages differ is dependant on how these components are combined as well as the scale at which they are offered. Some packages offer all of these functions, but are only capable of working with small sites. Others offer one or two functions targeted at large enterprises.

In our next edition of Extracts, we will discuss the various categories of CMS platforms as well as highlighting some of the most well-known software packages. If you have any immediate questions about content management, please feel free to contact me at mtsai@extractable.com.

Book Review: The Object Primer

MUST HAVE!

The Object Primer
by Scott W. Ambler

Even though object-oriented programming (OOP) has been around for many years and is taught in the computer science programs at colleges and universities, there are still many developers who do not know it. What this means is that those who are now performing the migration to OOP are primarily old dogs that need to learn the latest tricks. This book is perfect for that task, Ambler writes very clearly and covers all of the major aspects of OOP.
There are two outstanding features of the book. The first is the clear writing style and the second is the completeness of coverage. Not only are the fundamentals of OOP covered, but the Unified Modeling Language (UML) is also introduced. Since the U in UML could now be considered a representative for Universal, most developers need to be able to understand it. Ambler also covers some of the basic features of design patterns, components, use cases, object-oriented analysis, object-oriented design and object-oriented testing. These are generally considered to be advanced topics, but as presented here are well within the level of an introductory book.
The only negative point is the significant amount of duplication that is done. For example, on page 410 there is a boxed region for the definition:

Subject Matter Expert (SME) - A person who is responsible for providing pertinent information about the problem and/or technical domain either from personal knowledge or from research.

An excellent definition, but the problem is that it was already defined on page 35 and was used many times in the pages between 35 and 410, especially in the chapter on gathering requirements. There are many similar situations throughout the book, so many that I often considered segments redundant.

This book could also be used as a textbook in a course on the principles of object-oriented programming without using a specific language. Some Java code is used, but it is very skeletal and is used to demonstrate the initial steps in constructing your application from the design principles.

Book Review: Effective Java Programming Language Guide

Effective Java Programming Language Guide
by Joshua Bloch

I got this book after programming Java for about 3 years....I can tell you that I've already learned more about Java by reading this book than any other book (or actual programming).

This book will make you think about your code in new ways. There are concepts in this book that make you think, why didn't anyone tell me that (or explain it to me that way)?

THIS IS ANOTHER BLACK BOOK YOU MUST HAVE!

What is Extreme Programming?

Check out this xp textbook classic from Ron Jeffies, our kongfu man got it in action...

Extreme Programming is a discipline of software development based on values of simplicity, communication, feedback, and courage. It works by bringing the whole team together in the presence of simple practices, with enough feedback to enable the team to see where they are and to tune the practices to their unique situation.

In Extreme Programming, every contributor to the project is an integral part of the "Whole Team". The team forms around a business representative called "the Customer", who sits with the team and works with them daily.

Core Practices: Whole Team

Extreme Programming teams use a simple form of planning and tracking to decide what should be done next and to predict when the project will be done. Focused on business value, the team produces the software in a series of small fully-integrated releases that pass all the tests the Customer has defined.

Core Practices: Planning Game, Small Releases, Customer Tests

Extreme Programmers work together in pairs and as a group, with simple design and obsessively tested code, improving the design continually to keep it always just right for the current needs.

Core Practices: Simple Design, Pair Programming, Test-Driven Development, Design Improvement

The Extreme Programming team keeps the system integrated and running all the time. The programmers write all production code in pairs, and all work together all the time. They code in a consistent style so that everyone can understand and improve all the code as needed.

Core Practices: Continuous Integration, Collective Code Ownership, Coding Standard

The Extreme Programming team shares a common and simple picture of what the system looks like. Everyone works at a pace that can be sustained indefinitely.

Core Practices: Metaphor, Sustainable Pace

Core Practices

Whole Team

All the contributors to an XP project sit together, members of one team. This team must include a business representative -- the "Customer" -- who provides the requirements, sets the priorities, and steers the project. It is the best if the Customer or one of her aides is a real end user who knows the domain and what is needed. The team will of course have programmers. The team may include testers, who help the Customer define the customer acceptance tests. Analysts may serve as helpers to the Customer, helping to define the requirements. There is commonly a coach, who helps the team keep on track, and facilitates the process. There may be a manager, providing resources, handling external communication, coordinating activities. None of these roles is necessarily the exclusive property of just one individual: Everyone on an XP team contributes in any way that they can. The best teams have no specialists, only general contributors with special skills.

Planning Game

XP planning addresses two key questions in software development: predicting what will be accomplished by the due date, and determining what to do next. The emphasis is on steering the project -- which is quite straightforward -- rather than on exact prediction of what will be needed and how long it will take -- which is quite difficult. There are two key planning steps in XP, addressing these two questions:

1. Release Planning is a practice where the Customer presents the desired features to the programmers, and the programmers estimate their difficulty. With the costs estimates in hand, and with knowledge of the importance of the features, the Customer lays out a plan for the project. Initial release plans are necessarily imprecise: neither the priorities nor the estimates are truly solid, and until the team begins to work, we won't know just how fast they will go. Even the first release plan is accurate enough for decision making, however, and XP teams revise the release plan regularly.
   
2. Iteration Planning is the practice whereby the team is given direction every couple of weeks. XP teams build software in two-week "iterations", delivering running useful software at the end of each iteration. During Iteration Planning, the Customer presents the features desired for the next two weeks. The programmers break them down into tasks, and estimate their cost (at a finer level of detail than in Release Planning). Based on the amount of work accomplished in the previous iteration, the team signs up for what will be undertaken in the current iteration.
   

These planning steps are very simple, yet they provide very good information and excellent steering control in the hands of the Customer. Every couple of weeks, the amount of progress is entirely visible. There is no "ninety percent done" in XP: a feature story was completed, or it was not. This focus on visibility results in a nice little paradox: on the one hand, with so much visibility, the Customer is in a position to cancel the project if progress is not sufficient. On the other hand, progress is so visible, and the ability to decide what will be done next is so complete, that XP projects tend to deliver more of what is needed, with less pressure and stress.

Customer Tests

As part of presenting each desired feature, the XP Customer defines one or more automated acceptance tests to show that the feature is working. The team builds these tests and uses them to prove to themselves, and to the customer, that the feature is implemented correctly. Automation is important because in the press of time, manual tests are skipped. That's like turning off your lights when the night gets darkest.

The best XP teams treat their customer tests the same way they do programmer tests: once the test runs, the team keeps it running correctly thereafter. This means that the system only improves, always notching forward, never backsliding.

Small Releases

XP teams practice small releases in two important ways:

1. First, the team releases running, tested software, delivering business value chosen by the Customer, every iteration. The Customer can use this software for any purpose, whether evaluation or even release to end users (highly recommended). The most important aspect is that the software is visible, and given to the customer, at the end of every iteration. This keeps everything open and tangible.


2. Second, XP teams release to their end users frequently as well. XP Web projects release as often as daily, in house projects monthly or more frequently. Even shrink-wrapped products are shipped as often as quarterly.

It may seem impossible to create good versions this often, but XP teams all over are doing it all the time. See Continuous Integration for more on this, and note that these frequent releases are kept reliable by XP's obsession with testing, as described here in Customer Tests and Test-Driven Development.


Simple Design

XP teams build software to a simple design. They start simple, and through programmer testing and design improvement, they keep it that way. An XP team keeps the design exactly suited for the current functionality of the system. There is no wasted motion, and the software is always ready for what's next.Design in XP is not a one-time thing, or an up-front thing, it is an all-the-time thing. There are design steps in release planning and iteration planning, plus teams engage in quick design sessions and design revisions through refactoring, through the course of the entire project. In an incremental, iterative process like Extreme Programming, good design is essential. That's why there is so much focus on design throughout the course of the entire development.

Pair Programming

All production software in XP is built by two programmers, sitting side by side, at the same machine. This practice ensures that all production code is reviewed by at least one other programmer, and results in better design, better testing, and better code.It may seem inefficient to have two programmers doing "one programmer's job", but the reverse is true. Research into pair programming shows that pairing produces better code in about the same time as programmers working singly. That's right: two heads really are better than one!

Some programmers object to pair programming without ever trying it. It does take some practice to do well, and you need to do it well for a few weeks to see the results. Ninety percent of programmers who learn pair programming prefer it, so we highly recommend it to all teams.

Pairing, in addition to providing better code and tests, also serves to communicate knowledge throughout the team. As pairs switch, everyone gets the benefits of everyone's specialized knowledge. Programmers learn, their skills improve, and they become more valuable to the team and to the company. Pairing, even on its own outside of XP, is a big win for everyone.


Test-Driven Development

Extreme Programming is obsessed with feedback, and in software development, good feedback requires good testing. Top XP teams practice "test-driven development", working in very short cycles of adding a test, then making it work. Almost effortlessly, teams produce code with nearly 100 percent test coverage, which is a great step forward in most shops. (If your programmers are already doing even more sophisticated testing, more power to you. Keep it up, it can only help!)It isn't enough to write tests: you have to run them. Here, too, Extreme Programming is extreme. These "programmer tests", or "unit tests" are all collected together, and every time any programmer releases any code to the repository (and pairs typically release twice a day or more), every single one of the programmer tests must run correctly. One hundred percent, all the time! This means that programmers get immediate feedback on how they're doing. Additionally, these tests provide invaluable support as the software design is improved.

Design Improvement

Extreme Programming focuses on delivering business value in every iteration. To accomplish this over the course of the whole project, the software must be well-designed. The alternative would be to slow down and ultimately get stuck. So XP uses a process of continuous design improvement called Refactoring, from the title of Martin Fowler's book, "Refactoring: Improving the Design of Existing Code".

The refactoring process focuses on removal of duplication (a sure sign of poor design), and on increasing the "cohesion" of the code, while lowering the "coupling". High cohesion and low coupling have been recognized as the hallmarks of well-designed code for at least thirty years. The result is that XP teams start with a good, simple design, and always have a good, simple design for the software. This lets them sustain their development speed, and in fact generally increase speed as the project goes forward.

Refactoring is, of course, strongly supported by comprehensive testing to be sure that as the design evolves, nothing is broken. Thus the customer tests and programmer tests are a critical enabling factor. The XP practices support each other: they are stronger together than separately.

Continuous Integration

Extreme Programming teams keep the system fully integrated at all times. We say that daily builds are for wimps: XP teams build multiple times per day. (One XP team of forty people builds at least eight or ten times per day!)

The benefit of this practice can be seen by thinking back on projects you may have heard about (or even been a part of) where the build process was weekly or less frequently, and usually led to "integration hell", where everything broke and no one knew why.

Infrequent integration leads to serious problems on a software project. First of all, although integration is critical to shipping good working code, the team is not practiced at it, and often it is delegated to people who are not familiar with the whole system. Second, infrequently integrated code is often -- I would say usually -- buggy code. Problems creep in at integration time that is not detected by any of the testing that takes place on an un-integrated system. Third, weak integration process leads to long code freezes. Code freezes mean that you have long time periods when the programmers could be working on important shippable features, but that those features must be held back. This weakens your position in the market, or with your end users.

Collective Code Ownership

On an Extreme Programming project, any pair of programmers can improve any code at any time. This means that all code gets the benefit of many people's attention, which increases code quality and reduces defects. There is another important benefit as well: when code is owned by individuals, required features are often put in the wrong place, as one programmer discovers that he needs a feature somewhere in code that he does not own. The owner is too busy to do it, so the programmer puts the feature in his own code, where it does not belong. This leads to ugly, hard-to-maintain code, full of duplication and with low (bad) cohesion.

Collective ownership could be a problem if people worked blindly on code they did not understand. XP avoids these problems through two key techniques: the programmer tests catch mistakes, and pair programming means that the best way to work on unfamiliar code is to pair with the expert. In addition to ensuring good modifications when needed, this practice spreads knowledge throughout the team.

Coding Standard

XP teams follow a common coding standard, so that all the code in the system looks as if it was written by a single -- very competent -- individual. The specifics of the standard are not important: what is important is that all the code looks familiar, in support of collective ownership.

Metaphor

Extreme Programming teams develop a common vision of how the program works, which we call the "metaphor". At its best, the metaphor is a simple evocative description of how the program works, such as "this program works like a hive of bees, going out for pollen and bringing it back to the hive" as a description for an agent-based information retrieval system.

Sometimes a sufficiently poetic metaphor does not arise. In any case, with or without vivid imagery, XP teams use a common system of names to be sure that everyone understands how the system works and where to look to find the functionality you're looking for, or to find the right place to put the functionality you're about to add.


Sustainable Pace

Extreme Programming teams are in it for the long term. They work hard, and at a pace that can be sustained indefinitely. This means that they work overtime when it is effective, and that they normally work in such a way as to maximize productivity week in and week out. It's pretty well understood these days that death march projects are neither productive nor produce quality software. XP teams are in it to win, not to die.

Conclusion

Extreme Programming is a discipline of software development based on values of simplicity, communication, feedback, and courage. It works by bringing the whole team together in the presence of simple practices, with enough feedback to enable the team to see where they are and to tune the practices to their unique situation.

Dig around to find ActiveX control? Try this - ActiveX Manager

ActiveX Manager is a utility software for ActiveX control registered on your local computer. I found it helpful when I dig around to find Sharepoint's upload control.

Below is a sample report generated for my box, which runs Windows XP Pro SP2, all up-to-date MS updates, Office 2003, VS.NET 2003 and 2005, SQL2003 and 2005, et al.

--------------------------------------------------------------------------------
Computer Name: xxxx
Generated On: Monday, January 30, 2006
Control Count: 159
--------------------------------------------------------------------------------
Control Name: Ref Edit Control
Version: 1.0
Status: Registered
ProgID: RefEdit.Ctrl
CLSID: {00024512-0000-0000-C000-000000000046}
TypeLib: {00024517-0000-0000-C000-000000000046}
File Location: C:\Program Files\Microsoft Office\OFFICE11\REFEDIT.DLL
File Size: 77824 Bytes
Created: 05/08/03 21:54:00
Modified: 05/08/03
Accessed: 01/27/06

--------------------------------------------------------------------------------

Control Name: Microsoft Data Bound Grid Control 5.0 (SP3)
Version: 1.0
Status: Registered
ProgID: MSDBGrid.DBGrid
CLSID: {00028C00-0000-0000-0000-000000000046}
TypeLib: {00028C01-0000-0000-0000-000000000046}
File Location: C:\WINDOWS\SYSTEM32\DBGRID32.OCX
File Size: 525352 Bytes
Created: 06/24/98 00:00:00
Modified: 06/24/98
Accessed: 01/30/06

--------------------------------------------------------------------------------

Control Name: Microsoft Office XP Web Components
Version: 1.0
Status: Registered
ProgID: OWC10.Spreadsheet.10
CLSID: {0002E551-0000-0000-C000-000000000046}
TypeLib: {0002E550-0000-0000-C000-000000000046}
File Location: C:\PROGRA~1\COMMON~1\MICROS~1\WEBCOM~1\10\OWC10.DLL
File Size: 7330360 Bytes
Created: 08/04/03 13:19:34
Modified: 08/04/03
Accessed: 01/27/06

--------------------------------------------------------------------------------

Control Name: Microsoft Office Web Components 11.0
Version: 1.0
Status: Registered
ProgID: OWC11.Spreadsheet.11
CLSID: {0002E559-0000-0000-C000-000000000046}
TypeLib: {0002E558-0000-0000-C000-000000000046}
File Location: C:\PROGRA~1\COMMON~1\MICROS~1\WEBCOM~1\11\OWC11.DLL
File Size: 8086072 Bytes
Created: 08/01/03 15:09:04
Modified: 08/01/03
Accessed: 01/27/06

and on...

Introduction of Aglie Development

Introduction
I want to provide thorough information for the everyday coder - without the "I want to sell you something so I have to look extra smart" obfuscation layer. These are my personal views, acquired by analyzing my own development "challenges", browsing the web, discussing it at CP and elsewhere, and trying it myself. It won't be a "brief introduction", so here's an overview in case you want to skip something:

• Where do we come from - two scenarios you might find yourself in
  
• Agile Programming - introduction to "new old" principles
  
• Refactoring Techniques - simple techniques, and an advanced real-life example
  
• Selling to your Boss - how to convince your company
  
• Limits of the Agile process - Where Agile Techniques are not applicable
  
• Appendix

Where do we come from

We all know this: Your project has a neat design you're really proud of. You did care for all eventualities that came up in the early design studies, the schedule is approved, there's even an extra week "padding for the unexpected" - and you are happy you can finally start coding. Two weeks into it, the first change requests arrive. Nothing special, just the usual "can we do this, too?" - "Yes, no big problem, we just need to plug an Carbunkulator into the Arglebargle".

Halfway through it, things look less shiny. A few more functionality tweaks, a few bugs, your best coder one week in the hospital - the schedule lags behind big time. Your boss returns from a talk with a client, after they played around with the first beta. It turns out they never really needed an arglebarge, it is just in the spec because their old system had a big one that was very expensive. What they really need is a big gonkulator, and it must be fast - much faster than now. Oh, and the one feature that gave you headaches while designing - you can scrap that: the only one guy who insisted on this feature (although no one understood why) moved on to greener pastures.

Whatever the reasons - the application ends up different from what it was envisioned. Chances are, it's a mess of crooks and shortcuts across a baroque, utterly inefficient infrastructure. You might even get afraid of touching it - 'cause a little change here breaks something there. Every time you try to fix some nasty behavior, you have to wad through tons of interdependent code, and every function, every class you see screams "rewrite me". Far from what you wanted.

Interestingly, you can arrive at the same place by leaving out the formal design process altogether: You have an idea, a rough plan how you can make it, and start coding. It starts well, but after some time, it gets tricky: an important library refrains doing what you expect, some things didn't work out as you thought, you're forced to hold much more distributed state information than you can juggle in your head.

The whole thing turns out a bit fragile, and although it mostly does what you want it to, it's a pain to use. As much as it's brittle to the user, the code feels brittle to you, probably no one will be able or willing to continue working on it, you're reluctant to change anything yourself, because, once you start to weed out the crooks, you wish you had the strength to start over again.

What went wrong? In the first scenario, the design (likely perfect for the initial requirements) did not live up to the changes that are inevitable in the course of a project. In the second, a reasonable design failed to evolve.

The solutions I discuss here are aimed at the course of the project, to help you avoid situations like this. Once you are stuck with a huge unmaintainable code base, it's much harder to stay on the success track (or get back on it again). At least, even when you feel you're stuck, many of the techniques here can help you not to give up on the way - neither economically nor stress-wise.

What is Agile Programming

AP is a collection of principles and techniques that try to overcome the inflexibility of the strictly-design-based development cycle. Three things make AP very powerful:

You are not required to model the entire development process after AP (of course you can). You can change project management slowly and incrementally, and you need to adopt only what really helps you.

The Agile process does not require extreme excellence at design or development - rather, it's aimed at the average team with some experience.

The techniques are simple, so simple that most old-timers consider them "common knowledge" - if only they were!

Here is what I understand as the core rules:

• Simple Design: use the simplest design that solves your immediate needs
  
• Design as you go: Always scrub and exercise the code you work on while the project develops, to make sure it remains well structured, designed and written. (Techniques for this are called Refactoring)
  
• Incremental steps: When changing or adding code, take the smallest step you can, then compile and test again.
  
• Independent steps: Don't mix up the things you do - when you fix a bug, fix the bug, when you add a feature, add the feature.
  
• Know and use your tools with purpose: Especially for tasks beyond writing code - like design and documentation, know the available tools, use those that help you (not just a single one), and always understand why you do what you do.
  

The Meta Rule: Use only the principles and techniques that actually work for you.

Simple Design and Design as you go

I considers this the very heart of the AP approach - and the one with the biggest potential to change the development process.

Instead of planning ahead for all nooks and crannies, make sure "Version 0.1" works out well. Concentrate on your next task, and pick the most simple design that makes it possible. This does not mean forget about design! Design remains an important part of the entire process, and classic good/bad rules still apply. The additional rule is: make your next step happen, not the 10th. Don't go far out of your way for something you think you need later. When you really need it, new possibilities will have opened, and priorities sure will have changed.

To keep the design evolving with the project, you always need to pay attention to the code base. With only some primitive techniques and trust in your instincts, you can get along very well for most of the time - so you're less burdened when you have to face te real challenges. Exercising the part you're working on means: over time the "hot spots" of your application get most attention automatically.

Although individual things, like renaming variables, might appear silly as itself, the cumulative effect is impressive. It's wonderful when the feeling of understanding your code base kicks in - don't miss it!

The initial design will have a great impact on your project as well (although you typically end up more flexible than with a strict design based approach). But don't worry too much: Different designs can support the same product, a simple one will give you something to work with, and refactoring will make sure your design grows with the application.

If the analogy is allowed: Agile Modeling is replacing the intention of a "perfect creation" with an evolutionary process: Although 7 neck vertebras can't be the perfect design for both the mouse and the giraffe, it does it's job very well in both cases.

Advantages

• You can react much more flexible to requirement changes and additions
  
• The overall design remain simple almost "by itself" - baroque arabesques are usually rooted out very early, before they grow big
  
• By scrubbing the code you're working on, the most important parts get most attention, and you don't invest extra time into changing what doesn't need to be changed.
  
• When cleaning up your code is technically part of the development process, you have much better chances to end up with a well commented and documented orthogonal readable code base
  
• You might be able to start coding earlier (although you won't necessarily be faster overall)
  
• You won't end up in the dead ends
  
• A good designer/developer can achieve the same with a "less agile" approach. But chances are, a wizard will get very close to the agile approach himself, if you let him do as he pleases. And for us non-wizards, we're all fallible to the stress and strains of development, and forget to follow idolized "good practice" in those dreaded one-nighters.
  

  Incremental, independent Changes
  

Incremental changes are the key to happiness, and the core idea of refactoring. However, I want to separate the principle from the techniques, that's why it gets it's own paragraph. To repeat the two rules:

Take the smallest step possible into the direction you want to go. Then compile and do a basic test that it's still working. And always do only one step - don't try sneak in a feature while you refactor - tempting as it may be.

For me, these rules still require some discipline, and a conscious effort. Sometimes it just seems easiest to scrap a class, and write it anew. Yet, when I get interrupted, it's much easier to say "five minutes" - and finish the search&replace at hand; or jot down a quick note what I was doing. When I return to my desk, I can continue without looking back and forth where I left of, without the fear I forget something.

Advantage: You always have working code you can deliver. Don't take this literally and skip QA - but in case of emergency (e.g. a bug at a customer site) you're much more ready to leave your current task in a working condition. In-house testing can get a new version anytime. You are quicker to react to new requirements: No more "I need to finish the Gonkulator rewrite before I can add this graphic feature that everybody suddenly seems to need urgently."

Also, your code passes much more often through the compiler, and a basic "does it work?" test - especially so if you do Automated Unit Testing. This gives a bit more confidence in complex code, and can be a real live saver.

There's one human reason behind this rule: Only a limited amount of state information is present in your mind (the often-mentioned "seven things"). Conscious splitting into steps with the least state information tries to saves you from a "short term memory overflow", which makes you forget things you wanted to do, and feel overwhelmed by the complexity of the code. And there is a Murphy reason: Every step you take will be a little bit more complex, have a few more dependencies and side effects than you expected. E.g. when rewriting two classes into one, a problem with header inclusion order can sidetrack you so far that you just forget to initialize an important variable again.

Know your Tools, and know your reasons

Besides writing code, many things belong to the development process: Design, Documentation, QA...

The first question should be: Why do I do that? The importance of these artifacts is as well known as a rich number of techniques and methods for them, that all to often claim or at least suggest to be exclusive. But, to take an example: why do you actually document your code? Do you still want to understand your code in 6 month? Should a 3rd party be able to write plugins based on your API? Is it to inform co-workers of changes in the interface or implementation specifics? Is it because you plan to retire to the Bahamas, so the code base needs to be passed on to a still-to-be-hired guy? These are quite different goals, and for each of them, different techniques are appropriate.

In the example, documentation comes in many flavors. UML charts, formal code comments that can be extracted by a parser, inline comments, a separate Word file describing your intentions, Source Control change logs, etc. You are much better off when you understand and use more than one tool. Look out for new tools, and don't forget about unused features of the tools you have.

Advantage: The time spent on non-coding tasks is used more effective, and doesn't feel wasted. Again: It's just to make you happy!

Refactoring Techniques

Refactoring is nothing magic, refactoring is a fancy word for cleaning up the code. A more formal definition would be:

Refactoring means continuously improving the design and appearance of your code base in small steps confined to surveyable areas.

All techniques are allowed that:

• improve code quality, readability, design
  
• are simple, or even "dumb" (such as automatic search-and-replace of a variable name)
  
• are small, and independent steps
  

Refactoring has two major uses: first, to keep an application well designed, to enable the "design as you go" principle. Second, instead of rewriting a larger module or class, you can refactor it into something much better. This requires much more discipline (controlling one's enthusiasm to make it better) than a rewrite, but is often the less risky yet more rewarding route.

I split the discussion in two parts - a formal list of basic techniques, and a real life example that contains suggestions for less automatable ones.

Basic Refactoring Techniques

Rename a variable / type / class / function

Every developer or team has it's coding standards - usually both formally defined and informal. Apply them to your code! If you have a function ReadData, and a complementary function DataWrite - rename one, so they are consistent. if you have a member that misses the m_ - prefix everyone else uses, spend the one or two minutes to change that. When you plan to change multiple identifiers, change only one at each step then compile and run. Use unique names - so when you forget to rename one place, the compiler catches it. (Oh, if the function is in an interface declaration shared by all modules of your 10-developer-project, ask your co-workers before you do!)

Reformat a function to conform to your coding standards

We want readable code - make it so! All-nighters tend to produce interesting, almost-working code that's horrible to understand. We don't want to throw it away, so first apply some formal beatification to it, then look deeper.

turn a code sequence into a function

If the complexity of a method increases beyond what makes you feel well, or if you notice that similar functionality is used at different places, make it a function.

move functionality shared by multiple classes to a common base class (or helper class)

This can break down the complexity of a single class back to a reasonable level.

Separate independent functionality into different classes / functions

The inverse of the above.

Notice a theme in c-e: We introduce a base class only when it seems necessary. Early design decisions are often intentionally immutable: because the design guru said it so, because it was the result of heated discussions, etc. In this course, the technical reason for a decision often gets lost, and with it: simplicity.

All these steps will take around 5 - 10 minutes - usually including "compile and test". You can take them anytime: when you're bored, while you're waiting for another project to compile, when you don't want to leave shortly before your boss. Whatever. Even taking one step will make your code base a little bit better, and you will have working code. They are easily undone (assuming you know to use your tools: editor, and source control)

While the decision what to do requires that you understand the structure of the code you're working on, executing it does not: they are simple search-and-replace or copy-and-paste tasks, and under VS.NET there are nifty tools available that can automate them safely.

Also, AP does not tell you how to design, only when. You still need to know what makes a good design, and find it yourself.

Other Refactoring techniques - A real life example

When I plan to refactor a complex class or module, I start with the things mentioned above. This has two purposes: First, the code gets easier to read, more compact, and unnecessary arabesques are removed in these steps, so I have a much easier time later on. Second, I get fairly accustomed to the class again, refreshing my memory. I find out which members are hot spots, discover old comments telling me what I wanted to do, etc.

Only when I'm through with the basics, I begin the actual changes. Again, I try to take the smallest step that takes me closer to my goal and keeps the code working. Here you need to be more creative - the techniques are not that straightforward anymore, and you need to plan ahead. That's why I'll take a real example, to illustrate some possibilities.

Recently, I refactored a class implementation that simulated a map<int, struct> by two arrays: a data array holding the values, and a key array, holding the key for each value at the same index as the data array. To speed things up, I tried to store the values at their "native" position: e.g. the value for key 17 I would first try to insert into index 17. To look up a value, I checked the "native position", then I had to search the key array for the index where the key was stored, then retrieve the value from the same index in the data array. The whole thing looked like this:

if (keyArray.size() > key && keyArray[key] == key)

// look up "native" position

return dataArray[key];

else {

int index = FindKeyInKeyArray(key); // linear search! (ugh)

if (index >= 0)

return dataArray[index];

}

(This atrocity to common sense grew from a quick side hack into a generic datakeeper class. I'm really ashamed of this - well, no more)

The first step were to rename the arrays (originally named data and map) to the ones above, so I wouldn't get a name clash later on - neither in the code, nor in my mind.

Ultimately, I would have to remove the keyArray index lookups completely, and replace the dataArray lookups. So I did a "Find in Files" for "keyArray[" and "dataArray[", just to see how often they were used. I was shocked - over 20 times each. I needed to break this down a bit further, before I "injected" the map<>.

So I moved some rarely used extra functionality that affected most functions to a derived class - due to the prior usage this wouldn't break any client code. While this moved no "hot spots" out of the class, the complexity of the hot spots itself was greatly reduced. Compile and run - still working. (Later I found I introduced a bug in this step, that even escaped my quickly written unit test. But due to the new cleaner code structure, it was found quickly).

The remaining lookup complexity, especially when inserting/changing values, was dominated by the "native position" handling - it probably didn't help much, and made everything ugly. I decided to remove this altogether. While the code would still work, performance might take a hit - this was a small risk I had to take. The worst thing that could happen would be rolling back to before this step (so I made a check-in at this point).

After removing the extra lookup, most of the hot spot functions did something similar to this:

int index = MapID(key); // lookup the key

if (index >= 0) { // when found...

// do something to dataArray[index]

}

else { // when not found...

// do something else

}

I figured, to replace this with a map, it wouldn't be a simple m_map[key] - the dataArray[index] was often used multiple times but I wanted the map lookup to happen only once, and I didn't need the operator[]'s feature to insert a new element silently. So I wrote a helper function, that contained all the functionality that I intended to change:

ValueType * GetValPtr(int key) {

int index = MapID(key); // lookup the key

if (index >= 0) { // when found...

return dataArray[index];

else

return NULL;

}

And started replacing the lookups by

ValueType * pVal = GetValPtr(key);

if (pVal) { // when found...

// do something to *pVal

}

else { // when not found...

// do something else

}

Again, very simple replacements, especially since I had made sure before local variable and parameter names are consistent. I renamed dataArray and MapID() in the class declaration and the GetValPtr implementation, so the compiler caught all occurrences where I was still relying on them. I picked "pVal" as name for the new local variable, since this name was used nowhere in the class.

After this step, I had a sleek implementation of a horrible idea. Quite an improvement.

Everything worked fine, so I took the last step: introducing an std::map<int, ValueType> member into the class, commenting out the the dataArray and keyArray declaration, and replacing the GetValPtr implementation with a std::map.find call:

ValueType * GetValPtr(int key) {

std::map<int, ValueType>::iterator it = m_map.find(key);

if (it == m_map.end())

return NULL;

else

return &(it->second);

}

Of course, replacing the two arrays with a map had some other side effects, temporarily breaking the storage functions (that needed to iterate over all values), and turning the array allocation/cleanup functions into syntax errors. This was a single big step, I had no ideas how to break this down further (and maybe started to get a little bit impatient). But due to all the preparation, it took no more than 40 minutes to do the change, replace the keyArray iteration with an map iterator, and get the code compile and run again. The thing is working fine now, I felt very happy, and I sleep much better.

While scrubbing the code, I marked commented-out sequences with a special comment tag, so I could search for these places. Thus, removing all the dead code (that I left in initially for reference and rollback), was a matter of a minute or two.

Of course, a few things still could be done. There's still a naming inconsistency in the "insert new item" implementation, and the GetValPtr function could be removed altogether, replacing the ValueType * with anmap::iterator. But the task at hand was done, and a new task was waiting for the next day, so I left it at that.

Refactoring techniques used in the example

A short overview of the things I used:

• Move "hot spot" functionality to be changed to a helper function, that has a the same calling syntax for the old and the desired new implementation - so you separate syntactic changes at many places (that are semi-automatic and can be caught by the compiler) from functional changes (that need to be tested if they still do the same)
  
• Move functionality to be replaced "inline" to a temporary helper function that you can remove later
  
• Use "Find in files" to find occurrences of a certain construct in your project - so you find hot spots, and know if you can replace it in one step.
  
• Pick names that make the compiler catch mistakes, or places you forgot to change
  
• Use simple refactoring techniques, like generalizing variable names, until you feel you can handle the complexity of the trickier steps
  

  Selling to your boss
  

OK, since you didn't fall asleep yet, you'll probably pondering one question: How do you convince your boss that renaming variables is worth your pay?

1. The best selling point is success.
   Just try some of the techniques and ideas presented here on a small scale. In an ideal situation, they help you solve a tricky problem efficiently - maybe one that has been bugging your team for a time. Your boss might ask you "Nice! How did you do that?" Just mention that you "tried some new techniques you read about recently"...
   
2. Refactoring is a fancy word for cleaning up code.
   There is a reason to use a fancy word: it sounds new, it sounds smart, and it makes you think about "usual things" from a different perspective. "Agile Programming" and Refactoring are buzzwords, chances are, your boss might already have heard something of this and wonder if he misses something.
   
3. Unless you have a very strict development process, Agile techniques can sneak in step-by-step. A key point of all Agile techniques is: only do what works for you. You don't have to revolutionize the entire development process. Start with "Incremental changes" for tasks assigned to you. If your tasks is to rewrite something, consider refactoring it instead. Try new tools, and unused features of existing tools, first for minor design and documentation tasks.
   
4. Remember the prime strength and original intent of Agile Programming: Additional flexibility towards requirement changes. Requirements do change over time. Clients can change their priorities at a large scale after trying the first beta. New features need to be added. 3rd party components (libraries, or OS components) change over time.
   

   Limits of the Agile Process
   

AP is not the holy grail either. There are some requirements that must be met to make it work:

• You need an open, friendly team
  If you have to stand mind games among the coders, if communication is bad, or if your co-workers take changes to "their" code as personal insults, it won't work.
  
• You need some experience in the team
  While you may not need a design ueberguru, you need a decent amount of real-live experience in your team. AP can stand a certain percentage of newbies, but if your 10-headed team consists of 9 freshmen and one experienced developer to guide them, you're probably better off with a more formal approach
  
• AP alone is not sufficient
  You will need other techniques. Focusing solely on AP techniques, you can quickly loose the "big picture" of your application. bad thing - you still need to know what you do, how things interact etc. AP is one tool, to make some of these tasks easier.
  
• Refactoring won't change the construction plans
  The basic structure of your code base can rarely be changed through refactoring. Usually, you can work towards something that might even look completely different, but uses the same basic mechanisms as the old code. If the implementation is good but the structure is wrong, a rewrite might be faster. Relying on AP alone might stall the large-scale changes that are necessary from time to time.
  
• AP doesn't tell you how to design
  Although certain techniques became popular together with AP (designing around user stories, design patterns, etc.), there is no formal mechanism. As I said, old design principles still hold true, but some designs work better with AP than others.
  

1. Appendix
   

Links

1. Here on CP, Marc Cliftons Organic Programming Environment and Automation Application Layer are well worth reading if you're looking for design concepts. According to Marc, they go along very well with agile techniques. (Sorry to the CPians with valuable related articles - I'm just not aware of them. If you know a related article, why not leave a comment?)
   
2. The WIKI - An interesting "open database" mainly concerned with modern design and development techniques - a good starting point is WhatIsRefactoring
   
3. Agile Modeling - A very good web site, with much more information than I can (or want to) present here, well written and not too heady.
   

   Why is Refactoring called Refactoring?
   

Although there are different explanations, the one that feels most natural to me is this one: Refactoring stems from the mathematicians "desire" to reorganize a term like

F = xyz + 2xy -7xz + 3yz - 14x + 6y - 21z - 42

into it's factors:

F = (x+3)*(y-7)*(z+2)

While both are absolutely identical, the second one exposes it's inner structure and important information on one look. Also, there are parallels between the processes.