Parallel Development Strategy

Software development is a fast-pace profession that requires team qualities that only people can bring to the project. Once a development team is in place there is a strategy that I call the Parallel Development Strategy that can speed along development. Before I reveal the particulars of my Parallel Development Strategy I want to briefly review what is needed from the people on the team first.

In some cases that I’ve witnessed, there is too much initial focus on “the project” and whenever concerns are made about the team it is dismissed with the unthoughtful comment “just throw another body on the project”. I went over the qualities that only people can bring to projects in my blog post Qualities Only People Bring to Projects. It’s not enough to just have people, or to “just throw another body on the project”, because those people have to have the necessary qualities for the team to succeed.

The process of developing software can suffer from the “just get it done” mentality in offices where it’s left up to the developers to create the application. One way I’ve been able to notice when projects start on the infinite development track is after an initial conversation with the client someone sits down at a computer and starts building a database with tables, columns and maybe some test data. What’s important to have before building the database is an understanding of the people that are going to use the application, how the application will work for the people, and how the people will interact with the software. Once this is truly defined outside of the application in a model space that people can understand, not just database administrators or programmers, then everyone can buy-in to the project before development starts.

Software Architecture Diagram

Once development starts then this is where I have enjoyed the benefits of using the Parallel Development Strategy. The diagram on the left is of the software architecture that Parallel Development uses. The key is starting in the middle of the architecture by defining the interface first and then working in parallel in two separate tracks outward. This is instead of starting at the bottom by defining the SQL database first and working up by code-generating a data layer and then building context and application use ontop of the coded data layer. It’s a name that I’ve given to a bundle of existing strategies and coding techniques that have been around for years. When I use them it is using Microsoft .NET programming languages like VB.NET or C# and SQL Server. One reason that Microsoft .NET is unique compared to other languages is because in version 3.5 they introduced LINQ which lets us easily move our queries from the database level up into the code level, letting us define our business logic the same across different data contexts. By using LINQ data providers we are able to abstract our SELECT statements and WHERE clauses up into the code level to be used even if we switch our database engine from SQL Server to Oracle or MySQL.

Why is this important? It let’s developers use the definition of the application that is in model space prior to development and create a rich API in code using interfaces. An interface is used to define how the API is defined without implementing the details. This is where we can fork our development efforts and potentially achieve Parallel Development speeds instead of using a linear development approach.

First, let me define what I mean by linear development. I use the term linear development to define what I observe in some software development shops where the database is created first, then a data layer is hand coded or code generated, and then a programmer databinds user interface elements and creates input forms against the data layer. If you succeed the first time then there is no problem. However, if there is a change to the design later on or that ominous one database field is missing then the whole data layer has to be re-generated and could then the programmers at the top level can see what changes they need to make to databinding or input fields.

Now, what I mean by Parallel Development is where the API or program interfaces are created first using interfaces in VB.NET or C#. Then after the interface is defined the development can fork so that both tracks can be started in parallel. In the first track there is a database designer that creates the database and a programmer that builds the implementation of the interface in the form of a LINQ data context. In the second track is the programmer that is databinding user interface elements and creating input forms that reference the interface. In this way, the programmer that is in the second track can be creating the input forms, business logic and data binding at the same time the database is being designed. If there is a need to add, “just one more field”, then this can be changed in the interface and data entity first and then the two tracks of database designer and top-level programmer can work in parallel again to implement the new field.

The SELECT statement queries can be defined in the business context in the programming layer using this strategy also so that the database does not have to be implemented before the business logic development starts. We can view this as a third track that can work in parallel as well.

There is a general Visual Studio 2008 project that I’ve created to illustrate the details of a Parallel Development project that you can use for reference that I will be publishing on Microsoft’s CodePlex website in my next blog post. Until then, I’ve provided a diagram that is an overview of the architecture after using a Parallel Development Strategy.