One of my favorite blogs on software development is Jeff Atwood’s Coding Horrors. Jeff is a programmer turned blogger that has a unique (and real) perspective on the psyche of developers. His blog posts are based on a topic that he’s researching for work or fun, which is something that I also do regularly.

In a recent search, I came across a blog posts from 2006 on “modern software development” (source) where Jeff he explains that development really hasn’t changed much in the past ten years. Based on my experience of working with developers both on client and agency side, I think that he’s spot on. Looking at his list, I came up with only a single addition (which appears in red/bold) for traits of modern developers:

• Store code in a source control repository. The beauty of using source control solutions, such as SVN/subversion, Git, or Visual Source Safe (VSS), is that a team of developers can develop code without overwriting each the changes made by each other.
• Deploy code using scripts. With a script, developers can automate the launch of a website, this ensuring that nothing is missed in the process.
• Develop using TDD or Test-driven development. Instead of writing code first, developers focus on writing tests for their code. This provides a solution to limit the number of bugs as a unit test can also serve as a low-level regression test as new code is introduced.
• Reuses code when possible. Modern developers know that they don’t need to re-invent the wheel. Instead of rewriting code, they tend to reuse code that’s already working. This translates to saving development time, plus it allows developers to focus their energy on learning something new.
• Apply the Model–View–Controller (MVC) architectural pattern. Since code is logically separated into 3 tiers (data layer, presentation layer, and business layer which connects the other two), developers can more easily maintain their code.

The good news is that the barrier to become a modern developer is low. Old school developers only need to adopt the MVC pattern to be new again.

NOTE: Stonehenge photo was provided by Danny Sullivan.

I just finished up the book Ignore Everybody: and 39 Other Keys to Creativity by Hugh MacLeod. The book is actually a collection of entries from Hugh’s blog where he talks about his hobby of drawing cartoons on the back of business cards. It was a short read — but it was packed with great life lessons, especially if you’re a product manager. Like a product manager, Hugh had to produce and promote his product (art on business cards) while facing plenty of criticism. This book reminds us that there are no such things as shortcut — the road to success is a long one. The three big lessons that struck a chord with me included:

Stay Focused. Once you find a direction, you have to stick with it. People may try to sway you with their opinion but you can’t let that get in your way of success.

Work Hard. You have to keep plugging away at your dream even if there’s no immediate reward. Theodore Roosevelt actually said the same thing: “Nothing in the world is worth having or worth doing unless it means effort, pain, difficulty… I have never in my life envied a human being who led an easy life. I have envied a great many people who led diffcult lives and led them well.”

Keep Practicing. If you want to get better at your craft, you have to do it again and again. There are no shortcuts. (NOTE: Jeff Atwood seems to repeat this message in his blog on development; see here).

Hope that you get to enjoy this book as much as I did.

The Iron Triangle allows for only two factors in determining the success of a web project. But the impact of the client’s perspective on the triangle seems to reduce the two factors into a single option.

Early on in my development career, I leaned how the Iron Triangle impacts projects. The iron triangle (aka the Project Triangle) is a software development concept that says that the quality of a project is determined by three factors:

• Timeline. How long you have to complete a project?
• Budget. How much is the client is willing to pay for the work?
• Features. What functionality can be built?

The point of the Iron Triangle is that you can pick or constrain only two of these three factors. So if the project timeline and features are constrained, then the budget must grow. If all three factors have to be met, then the quality of the web project will be sacrificed. While this concept seems to give developers some breathing room, the Iron Triangle seems to be further constrained when the client’s perspective is taken into account. Let me explain.

A client typically approaches web projects with two constraining factors. When a client requests a solution, they normally constrain the project by asking that the solution be delivered by a certain deadline. The deadline is normally set because the client needs to meet a pre-determined objective, such as seasonal promotion, customer acquisition campaign, etc. Additionally, when a client requests a solution, they further constrain the project with their budget. Since money doesn’t grow on trees, the client will dictate how much they can spend for development on a project to be completed.

So when the client’s constraints on a project are taken into account, the Iron Triangle is actually reduced to a single option: project features. This means that developers have to look at how many features they can implement for the time and money that they are given. The good news is that the feature list can be functionaly robust or weak. That means that there’s some play in what the client will or will not get for the time and money that they’re dedicating to the project.

Understanding the purpose of a legacy microsite can help you determine whether you should fold it into your newly designed website or dump it. These tips will help guide you in the decision making process.

In my tenure as a web manager, I’ve worked on countless projects where the client wanted to redesign their website. The first step in a site redesign process is to complete a site mapping exercise, where various pages and content are identified. As part of the process, we frequently uncovered microsites, which is somewhat like finding a skeleton in the closest. The newly found microsites raise the question of whether they should be collapsed into the site or permanently removed.

While answer may seem elusive, I’ve found that the decision can be driven through thinking about the common characteristics of a microsite. These characteristics include:

• Temporary
• Unique branding
• Special content
• Custom navigation/URL
• Nonstandard content management

To clarify, a microsite is typically launched to support a new marketing initiative or promotion. The site may break the branding guidelines or rely on new print collateral so that the marketers can fully test their initiative. A microsite frequently has new content that doesn’t follow the normal content structure of the website. Additionally, the microsite may play a part in an SEO campaign or and SEM campaign so it may not link to the corporate site or require custom navigation so that visitors don’t have to think. Lastly, the content on the microsite may require more involvement than the corporate IT department can dedicate to this initiative.

So how do these characteristics help determine whether to migrate the microsite?

To answer this question, one must simply evaluate whether the characteristics of the site when it was built have stood the test of time. Some questions to ask yourself include:

• Has the marketing initiative or promotion become a permanent part of your marketing offerings?
• Can the design shift back to the corporate branding guidelines?
• Can the content fit within the corporate website through the use of an existing content template?
• Will the microsite continue to meet its goals if the navigation matches the corporate site?
• Can the content on the microsite be managed through a Content Management System or CMS?

By answering more of the questions above with a yes, the clearer the direction is to fold the microsite in with your website.

In my previous post on online forms and project requirements, I discussed what can happen to data once a form is submitted. And while it is critical to understand what happens to the data, web developers developers also need to better understand the form data.

As defined in the previous post, an online form is an interactive interface where a user can submit one or more fields. The fields allow a user to submit data, where it can be their name, email address or even password.

There are two general types of fields:

• Free-flowing fields. Often referred to as an input field of type TEXT, these allow a user to enter virtually any kind of data, including alpha numeric text, dates, or numbers.
• Constrained fields. Often referred to as a SELECT field or an input field of type RADIO or CHECKBOX, these allow a user to enter pre-determined data.

Once a user enters information into a field, the field can be validated to ensure that the data is of the expected type (IOW, an email field gets an email address and not a first name). This is often referred to as a required field or a field that must be filled in order for the online form to be submitted/data to be accepted. There are two types of form data validation:

• Client-based data validation is the ability to use the web browser to validate the data before it is submitted to the server. This validation often relies on a client-side scripting language called Javascript. Custom Javascript validation can be coded by hand or can be done using a Javascript library, such as jQuery, MooTools, Prototype/Scriptaculous, etc.
• Server-based data validation is the ability to use the web server to validate the data once it is submitted to the server. This validation often relies on a server-side scripting language, including ASP, ASP.NET, ColdFusion, JSP, PHP, etc.

So based on the above, project management should collect the following requirements regarding form data:

• How many fields will appear on the form and what type of data will be submitted through each field?
• Will the form require any validation and will it require client-based or server-based validation?
• If validation is required (regardless of type), which fields will be validated and what is the expected data per field?
• If client-based validation is required, will the Javascript be coded by hand or will it rely on a library? If it relies on a library, what type of library will be required?
• If server-based validation is required, what kind of scripting language will be used to perform the validation?

These questions should help you round out the online form requirements gathering.

Online forms are an integral part of a website. They are frequently used to allow users to log in to an application or to submit their information. As a project manager, you should expect to have at least one website project that will have an online form. So it is important for one to understand what kind of requirements you should collect for a developer to build a form.

By definition, an online form is an interactive interface where a user can submit one or more fields. Once a form is submitted, there are three potential outcomes (see image below):

Outcome #1: The data that’s submitted is displayed back on the screen.

Outcome #2: The data that’s submitted is sent. The data can be sent as an email to a contact or a list of contacts or to a web service (I’ll define a web service at a later time).

Outcome #3: The data that’s submitted is saved in a data source.  Data sources range from the ultra-simple file (which is often referred to as a text file or a flat file) or a database (eg: MySQL, MS SQL, Oracle, etc.)

So based on the three outcomes above, the base requirement to collect/understand would be to determine what should happen once the form is submitted, or action is necessary on the online form. Additional questions around this would include:

If the data is displayed:

• Where is it displayed and what kind of styling is required?

If the data is sent:

• Is it sent as email or a web service?
  • If it is an email, who gets it and how should the information appear in the email (any special formatting)?
  • If it is a web service, where is the web service, does the web service expect anything in particular (is anything required) and will the web service return a success/error message once it receives the information?

If the data is stored:

• Where is stored?
  • If it is a database, what kind of database is it (MySQL, MS SQL, etc.), what is the version number,what is the database name, what is the database table(s), and what is the column name(s)?

Hope that this helps make the requirements collection process easier on your next project!