Rinat Abdullin

Agile Software Development is an iterative and incremental approach in software development, where requirements and solutions evolve through a tight collaboration of self-organizing cross-functional teams.

Simply put, Agile Software Development is a group of software development methodologies that work quite well when:

• projects are not mission-critical;
• business requirements change extremely fast;
• there are great developers available;
• development teams are small;
• development culture and mentality favors self-organization and self-learning.

In other words, Agile works quite well in situations when some unique software project has to be delivered really fast in order to seize the market opportunity. This works because Agile software methodologies allow development teams to adapt quickly to the rapidly changing business requirements. This happens because of:

• short development iterations allowing to start getting feedback early in the project's life-cycle and incorporate it into the product fast by delivering working software repeatedly and in a timely manner;
• continuous integration helping to reduce development friction and improve quality of a rapidly developing project in self-organizing environment;
• feature-driven development focusing development on delivering features (functionality) bringing real business value to the client (and the project);
• lean software development laying out common principles for efficient software development process;
• eXtreme Programming pushing lightweight software development methodologies to the extreme.

Long-term planning (along with some other formalities of a totally controlled project management process) is mostly sacrificed in favor of the flexibility, fast delivery and self-organization. In such a situation we still have to maintain high quality of the project deliverables (while reducing the resource consumption). This is achieved with the help from:

• test-driven development - provides foundation for the Continuous Integration and facilitates change while maintaining stability of the software project;
• pair programming - improves code quality and allows to have more efficient knowledge sharing.

Related Links:

• Agile Software Development on Wikipedia
• Lean Software Development on Wikipedia
• Scrum on Wikipedia
• Planning poker on Wikipedia
• eXtreme Programming on ExtremeProgramming.com

This article is a part of Software Development Body of Knowledge ABC series. You can subscribe to RSS feed to stay updated.

Cloud computing is about hardware-based services (involving computing, network and storage capacities), where:

• Services are provided on-demand; customers can pay for them as they go, without the need to invest into a datacenter.
• Hardware management is abstracted from the customers.
• Infrastructure capacities are elastic and can easily scale up and down.

There is a powerful economic force behind this simple model: providing and consuming cloud computing services generally allows to have far more efficient resource utilization, compared to self-hosting and data center type of hosting.

This is especially true for bursting into cloud scenarios when cloud consumers use elasticity of the cloud services to handle any spikes they might get. More information is available in article Why is cloud computing important for us?.

Obviously, consuming raw hardware capacities may be too hardcore for some consumers that merely want to have a scalable storage. So it is natural that cloud computing services already got some diversity around them:

• Infrastructure as a Service (IaaS), where customer gets raw hardware resources (i.e.: virtual machines with OS of choice). Examples:

  • Amazon Elastic Compute Cloud - part of AWS that offers scalable Xen-based virtual machines.
  • Mosso - .NET or LAMP web sites, Storage and Linux-based virtual servers. People complain.

• Platform as a Service (PaaS), where service provider builds a platform to simplify solving some technological tasks. This simplifies life for the customer, but also comes with a lock-down cost. Some providers:

  • Microsoft Windows Azure - .NET driven and Microsoft-owned cloud infrastructure, which is behind Amazon in some areas.
  • Amazon Web Services - collection of scalable infrastructure pieces for building your cloud application.
  • Google App Engine - Python-based cloud framework.
  • Amazon Elastic Map Reduce - Apache Hadoop hosted on Amazon cloud services (EC2 and S3)

• Software as a Service (SaaS). At this level everything is way more simple for the customers to consume, since they are provided with actual services generating business value to them. Service providers handle all the technological complexity and provide the support as needed.

From the development perspective, cloud computing is a brand new field (which is especially true for the .NET world). So there are no established patterns and pactices in the field yet. However, common development guidelines tend to work quite well:

• Component-Driven Development with Inversion of Control Containers
• Test-Driven Development
• Continuous Integration for the projects
• Separation of Cross-Cutting Concerns

Related links:

• Cloud Computing article series
• Why is Cloud Computing important for us?
• Cloud computing: a personal review about Azure, Amazon, Google Engine, VMWare and the others by Joannes Vermorel
• Cloud Computing on Wikipedia

This article is a part of Software Development Body of Knowledge ABC series. You can subscribe to RSS feed to stay updated.

Command-Query Responsibility Segregation (CQRS) is a way of designing and developing scalable and robust enterprise solutions with rich business value.

In an oversimplified manner, CQRS separates commands (that change the data) from the queries (that read the data). This simple decision brings along a few changes to the classical architecture with service layers along with some positive side effects and opportunities. Instead of the RPC and Request-Reply communications, messaging and Publish-Subscribe are used.

If we go deeper, Command-query Responsibility Separation is about development principles, patterns and the guidance to build enterprise solution architecture on top of them.

Such enterprise solutions aim to be:

• Scalable
• Focused on the business rather than the technology
• Can grow to handle complex problems without growing development costs
• Adapt to changing business requirements
• Efficiently integrate with other software and systems
• Benefit from the cloud computing
• Inherently handle multiple users

While going for these goals, CQRS attempts to solve problems of:

• Performance bottlenecks and scalability
• Concurrency conflicts, their resolution and prevention
• Data staleness
• Complexity of the design, development and maintenance

Related links:

• CQRS introductory video.
• Clarified CQRS paper by Udi Dahan.
• DevTeach Video
• DDDD, CQRS and Other Enterprise Development Buzz-words

This article is a part of Software Development Body of Knowledge ABC series. You can subscribe to RSS feed to stay updated.

Related Links:

Component-Driven Development is an approach in software development in which code is fragmented into reusable and testable components that are combined together to form application foundation for delivering business functionality. The combination and management of components is generally delegated to Inversion of Control Container.

A component itself is a class that implements some service contract and explicitly defines the dependencies that it needs in order to fulfill this contract. Actual implementation is hidden from everybody else outside the component.

Component-driven development really helps to deliver multiple applications and systems efficiently. It happens because:

• important functionality is abstracted in components;
• components are coded and unit-tested only once;
• it is easy to reuse component in similar situations, reducing development effort and avoiding code duplication;
• every component has multiple use cases that provide additional feedback and help to find problems or limitations, if there are any;
• whenever a component is fixed or improved, all its consumers would benefit from that automatically.

Multiple components can have rather complex relations. Thus, visualizing them makes application a bit simpler to understand.

As we go up in the complexity of the development, it becomes too cumbersome to manage components on the individual basis. That's where infrastructure shards come into the play. Infrastructure shard is a group of components used together in a similar manner to deliver certain functionality across multiple applications.

This scenario creates additional benefits for the component-driven development. Some synergy effects might include:

• Business functionality could be used to extend multiple applications. Since UI is shared, we could use shared documentation, tutorials and screenshots as well.
• Sometimes context requires infrastructure shard to be evolved. This brings potential improvements in all existing and new applications.
• When a group of components is developed to be used in multiple scenarios from the start, this polishes the overall design even further than TDD or CDD would alone.
• Localization or UI changes across the software product line become easier, since the effort does not have to be duplicated and tested in multiple codebases.

Related links:

• Component-Driven Development and IoC Containers
• Developing Component-Driven Applications powered by IoC Containers
• Infrastructure Shards and Optional Components
• Visualize IoC Container and Domain Dependencies
• What is Component-Driven Development on Stack Overflow

Continuous Integration (CI) in software development is a set of practices and principles that speed up delivery of software projects and increase quality of their deliverables.

Simply put, Continuous Integration takes a lot of mundane and boring things away from the process of software development, while letting developers to concentrate on more enjoyable and creative tasks.

As the name implies, Continuous Integration is about integrating changes to the development project continuously and automatically. These changes usually come in form of modifications and additions to the source code. When we keep them as small as possible and automatically run all checks available (starting from the compilation process and up to the full test routines), we can detect most breaking issues whenever they are introduced. Since the changes are small, it is much easier to isolate and fix the root cause.

Continuous integration helps to achieve this by reducing development friction involved in project integration. This is done with the help of:

• Version Control Systems that allow large and distributed teams to work together on the same project, while sending their code changes (commits) to the central server. Each commit is stored on the server and could be reviewed or reverted.
• Build Automation that is basically about build tools and scripts that allow to start the complete integration build on a local machine with a single mouse-click.
• Unit Tests ensuring that code stays stable through all the changes (this normally comes with the Test-Driven Development practices).
• Code Quality Tests that consistently enforce development guidelines accepted by the team.
• Regular Commits by developers that reduce amount of change involved in every integration.
• Integrating Every Commit (as soon as it comes) on a central server allows to detect any compilation failures or broken tests immediately. Also this is the best way to deal with "but it works on my machine" problem.
• Publishing Integration Results that get created along with the build project might simplify getting feedback from people outside of the development team. Examples of these results are: unit test results, performance metrics, install packages, code quality reports etc.

From my personal experience, Continuous Integration is a must have in any single project that has a lifespan more than 200 human hours.

Here's the most simple example of CI benefits. When you have proper CI routine at hand, updating a customer with the latest fix (if the fix is in the desktop application, for example) is a mere matter of:

• write the code;
• test the code;
• commit the changes to the server, telling it to publish install packages along the way;
• tell customer to install the latest version (or simply restart the application, if you have autoupdate routine in the application).

Behind the scenes will happen:

• backing up a copy of changes;
• running full suite of tests against the entire codebase;
• computing code metrics and performance statistics;
• publishing development reports for the team;
• updating online documentation that is generated from the code;
• building the project and creating a new version of install package;
• creating a backup of this package (along with all the libraries and PDBs);
• putting install package to the deployment server and updating manifest needed for auto-updates;
• notifying all involved parties about the build and results.

Ability to take all this "behind the scenes" routine for granted definitely reduces development friction a bit, allowing to concentrate on more interesting and creative things.

Software Stack for Continuous Integration in .NET:

• Version Control Systems

  • Subversion (Open Source)
  • Git (Open Source)

• Unit Testing

  • NUnit (Open Source)
  • MBUnit (Open Source)
  • XUnit (Open Source)

• Build Automation

  • MSBuild
  • NAnt

• Continuous Integration Server

  • Cruise Control .NET (Open Source)

• Code Quality

  • Mono Gendarme (Open Source)
  • Microsoft FxCop

Related Links:

• Continuous Integration by Martin Fowler
• Continuous Integration on Wikipedia
• Some integration recipes for the efficient development
• Hunger for the integration builds.
• Recommendations on software and tools for the development
• Organization of xLim solutions: development, svn and integration
• Common development principles for xLim

This article is a part of Software Development Body of Knowledge ABC series. You can subscribe to RSS feed to stay updated.