The growth of agile development practices has turned the software development life cycle on its ear.

As the special report in this issue spells out, the way requirements are gathered has changed. In agile shops, no longer do business analysts spend months working with the customer to develop a huge requirements document that can only be changed at great cost. Agile processes demand that practitioners accept, even embrace, changing requirements throughout the project’s life.

The way testing is done has changed. No longer do QA teams wait for a completed project to run their tests, when finding defects is most costly. Programmers working in agile environments are using tests to drive development, performing unit tests and functional tests as they go.

The way code is built has changed. No longer are overnight batches run so that development teams must spend half their morning deciphering build reports. Continuous integration has become the coin of the agile realm.

Even the way code is written has changed. Developers are working more collaboratively than ever—even those separated by great geographic distances—to produce working code under shorter iterations.

So, too, the tools development managers and their teams use to create software have changed. Many ALM tool suites now include critical project management elements for tracking work and assets. The development environments programmers use are now including more social elements such as wikis, worker profiles, message boards and the like. Testing and build tools are evolving to meet the changing needs of developers producing pieces of projects that must work with other elements, and be changed as needed without “breaking” the software.

For years, we’ve been chronicling the disconnect between developers and tool makers. Developers say they just need help porting an application to a different platform, for example, while tool makers try to foist a methodology upon them that just so happens to be the foundation for their products. This time, it seems, the tool makers are getting it right. They seem to be listening to users rather than leading them down a path they might not want to travel.

The response by software tool providers to this changing development landscape will push the adoption of better development practices even further, and that’s a win for all concerned.

+1 for binary XML format
We’re pleased to see that Efficient XML Interchange has reached an important milestone. As XMI becomes a W3C Candidate Recommendation, let’s pause and look back at the evolution of the Extensible Markup Language.

XML’s roots go back to SGML, the Standard Generalized Markup Language. HTML is one derivative or subset of SGML; XML is another. In its early days, it was important for XML documents to be human-readable. Encoded with easy-to-understand tags, XML documents could be proofread and understood both by people and parsers.

But then XML documents began to grow. And grow. As they became more complex, those super-verbose documents became incomprehensible to humans and more difficult to parse. XML files also became big enough as to require significant bandwidth for transmission—a trivial matter on local-area networks, a minor concern for broadband wide-area networks and the Internet, and a major problem for mobile devices.

Binary file formats were the obvious solution to this growing problem. Binary files are smaller and require less bandwidth and storage space. If correctly constructed, they could be easier to parse than standard XML as well. A binary file’s inability to be directly interpreted by humans wasn’t a significant issue, but the possibility for the imposition of proprietary extensions or encodings could be catastrophic by subverting the openness of XML.

SD Times has always been opposed to binary XML formats presented by vendors or vendor consortia. To be acceptable, binary XML had to be based on legitimate open standards. While XMI is derived from a vendor-proposed binary format (AgileDelta’s Efficient XML format), the W3C is creating a truly open standard that offers significant advantages over plain-text XML. XMI is a good move for our increasingly mobile universe and an excellent step forward in the evolution of XML.