Agile: A requirements change is a competitive advantage

At what point in the lifecycle should requirements be locked down?

1. Before development begins
2. Never
3. Somewhere in between

Most developers will immediately choose "Before development begins" for simplicity. However, if you work in an agile environment that responds well to change then there are many advantages to "Never".

Advantages of Changing Requirements

• Changing requirements will improve the product and should give you a competitive advantage.
• Changing requirements will evaluate the efficiencies of your development, QA, and deployment processes. Highly effective or agile teams will deliver the new requirement relatively pain-free.
• Changing requirements encourage automation throughout the lifecycle. The important factor here is that it encourages automation across all departments (development, QA, deployment). The following attributes must exist within each department for this strategy to be successful:
  
  
  • Development:
  • Automated JUnit tests - frequent changes must be tested efficiently.
  • Continuous Integration - frequent changes require stable environments.
  • Code reviews - This knowledge transfer session will give your team the flexibility of having anyone work any task more efficiently.
  
  
  • QA:
  • Automated regression tests - frequent changes must be tested efficiently.
  
  
  • Deployment:
  • Automated deployment scripts - simplify and more accurately deploy the changed release modules.


• Software must be delivered faster so the customer's can identify the change points sooner in the lifecycle. The goal is to deliver testable software quicker. How many of you deliver testable code after iteration one? How many of you have customer demos of working software after iteration one? The goal is to identify changes sooner in the lifecycle and this will help minimize the risk of failing to meet your production delivery date.

Disadvantages of Changing Requirements

• Changing requirements may delay the project. This is where the debate typically begins. However, if you initially plan for some percentage of change you should be fine. Identifying change early in the lifecycle will also help remedy the impact.

The Hybrid Example

Which auto makers were most successful with their hybrid initiatives? It was the automakers that adopted lean/agile practices many years ago. The automakers that did not change soon enough are now scrambling to recover. Changing requirements can have a huge competitive advantage if your environment responds well to change. A key attribute of being agile is adapting to change.

JavaScript: The Good Parts

What's the most popular functional language? JavaScript is. And if you are interested in learning the finer points of the language I recommend Douglas Crockford's latest book titled JavaScript: The Good Parts. It is a very quick read at only 145 pages! The most valuable lesson I learned from the book was the correct way to create JavaScript objects with the Module Pattern. The following examples illustrate the Module pattern. This creational pattern leverages closure to achieve encapsulation, information hiding, and global safety. No other JavaScript creational pattern provides these capabilities. This should be your preferred creational pattern in JavaScript.

Module Pattern Examples:

/**
 * A search module that provides the ability to search by name.
 */
var search = function (criteria) {
    /* private variables */
    var name = criteria.name;
 
    /* private methods */
    var renderResponse = function() {
        alert('rendering response for: ' + name);
    };
 
    /* return our public API methods */
    return {
        execute: function() {
            alert('searching for: ' + name);  // Perform an AJAX search
            renderResponse();                    // Perform renderResponse as part of the AJAX callback.
        }
    };
};

Instantiate a new search object:

search({'name':'Johnny'}).execute();

Run search example

Alternatively, if you prefer to return your public API methods via assignment you may find this example to be simpler:

var search = function (criteria) {
    /* private variables */
    var that = {};
    var name = criteria.name;
 
    /* private methods */
    var renderResponse = function() {
        alert('rendering response for: ' + name);
    };
 
    /* Assign public API methods to that. */
    that.execute = function () {
        alert('searching for: ' + name); // Perform an AJAX search
        renderResponse();                   // Perform renderResponse as part of the AJAX callback.
    }
 
    return that;  // return by assignment example.
};

Module Pattern Advantages

• Improved encapsulation. For example, if the renderResponse functionality is only pertinent to search, we can encapsulate that behavior within the search object.
• Better information hiding. No consumers of the search module will be able to call renderResponse directly because it is private.
• The objects are global-safe. You will not see any references to the this keyword anywhere. This will eliminate any possibility of altering global variables.
• Requires less effort than other creational patterns (pseudoclassical pattern, Object.create pattern).

JavaScript Resources:

• JavaScript: The Good Parts presentation from the Google Code Blog.
• In particular, I found the following sections within JavaScript: The Good Parts to be most valuable for me. These mere ten pages of content were worth the cost of the book!:
  • Chapter 4 (Functions):
    • Closure
    • Module
  • Chapter 5 (Inheritance):
    • Functional
• JSLint: an excellent tool for code quality analysis.
• Doug Crockford has at least eight JavaScript presentations available at YUI theatre

Kanban: The Good Parts

Kanban Estimates

Struggling with those developer estimates? If you are, you may want to give Kanban's estimation practice a try. The Kanban methodology almost entirely eliminates the estimation process. Instead of using formal planning and estimation all features have approximately the same size. Hours that were previously burnt estimating are actually spent delivering software. When compared to the Scrum estimation model, this style of estimation is very lean.

Advantages:

• Hours previously spent estimating are spent delivering software.
• The focus is on delivering software more rapidly vs focusing on when the software will be delivered.
• Does not invest heavily in a metric that is not scientific or always accurate.

Disadvantages:

• High level estimates are still necessary for resource planning.

Kanban Stand ups

Unlike Scrum stand ups where each individual answers the three magical questions of: what did I do yesterday, what am I doing today, and what issues do I have. Kanban focuses exclusively on issues. For example, the global question now becomes: Does anyone have any issues?

Advantages:

• Quicker stand ups.
• The stand up scales better for larger teams.
• Issues are the main focus.

Disadvantages:

• May lose visibility of what each member is working on.

Resources

• Kanban as Alternative Agile Implementation
• A Kanban System for Software Engineering

Secure Computing: Preventing Cross Site Scripting (XSS)

XSS prevention cheat sheet

The best strategies for preventing Cross Site Scripting can be found in OWASP's XSS prevention cheat sheet. Several important notes include:

• You MUST use the escape syntax for the part of the HTML document you're putting untrusted data into. There is no single escape function that can be applied for all output contexts (HTML, CSS, JavaScript). ESAPI has an API that provides encoding rules for a particular output context. Refer to the OWASP's prevention rules for more details.
• It is impossible to secure a JavaScript context with escaping. This is an important note because there is no defense to this scenario except to eliminate the output of dynamic content within your JavaScript context entirely.

XSS and JSTL

JSTL used appropriately will protect you from an XSS attack within your HTML context. For example, this a valid JSTL solution:

<%-- XSS safe --%>
<c:out value="${untrusted_data}" escapeXml="true" />

By default, the excapeXml attribute is "true" within the out tag so you don't have to explicitly declare it.

The JSTL expression language alone will NOT protect you from an XSS attack. For example this is not safe and MUST be avoided for all untrusted data:

<%-- Not XSS safe --%>
${untrusted_data}

XSS input validation

Validating input characters for malicious data should not be your only method of prevention. It is recommended to always escape untrusted data on the output side because you account for all data regardless of where the data originated from. Maybe the data was maliciously altered in the database or perhaps your third-party vendor sent harmful data outside HTTP. Input validation does not account for those scenarios and should not be used as your only defense. Output escaping with ESAPI or JSTL covers all bases regardless of where the data originated from. If you prefer to validate user input for XSS you may use regular expressions. A whitelist strategy of allowing positive characters is preferred. For example, the regular expression code below is a whitelist pattern that only allows certain characters as valid input:

public final class ValidationUtils {

     /* Whitelist validation example.  Only allow alphanumerics and special characters: -@&., */
    public final static Pattern VALID_TEXT_FIELD_PATTERN = Pattern.compile("[A-Za-z0-9-@&\\.,\\s]*");
 
    public static final boolean isValid(Pattern pattern, final String value) {
        return pattern.matcher(value).matches();
    }
 
}

XSS and JSON

If you are using JSON on the client-side make sure you also validate your JSON content for malicious data. Douglas Crockford, in his recent book JavaScript: The Good Parts recommends using JSON.parse() for all untrusted content. JSON.parse() will throw an exception if the text contains anything dangerous.