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.

To get an idea of what tomorrow brings, we can look to companies such as Mercedes-Benz and their Adaptive Cruise Control technology, or even Chrysler’s U-Connect system that will transform you into a rolling WiFi hotspot. At first glance, these two technologies may seem to be totally unrelated. But you would be wrong to think that. In fact, these both open up a new phase in automotive evolution. Believe it or not, but our cars are becoming “social”.

Social, you say? Take for instance the Adaptive Cruise Control system. The basic premise is that your car will emit radar or laser signals to help guage the distance between itself and the car in front of you. When you get too close, it will automatically adjsut its speed or alert the driver of an impending crash. Your car is now self aware, albeit in a very primitive manner.

The U-Connect system (and other similiar implementations) opens the door even further. Once your car becomes part of a network, it will be able to communicate to other cars and/or computers on the very same network. If that network in turn is connected to the internet, as it undoubtedly will be, it will open up a whole new realm of possibilities. For instance, not only will your car will know about the other cars around it, but it will also know about its surroundings as well.

Despite the obvious privacy issues that will surely be raised, there will be plenty of practical uses for this technology. For example, a traveler may be alerted when they are running low on fuel and then offer them directions to the nearest station. Once there, they’ll simply fuel up and then drive off – the bill will have already been paid for via a wireless transaction.

On a separate occasion, a driver might even be alerted to an accident ahead and then be offered an alternate route. In fact, cars will eventually be able to tell one another about traffic conditions in real time by broadcasting their location, direction and speed so that others may select a different route. The days of the rush hour traffic-copter are surely winding down.

Many of the above technolgies are already available today and will soon be common place – just like power windows and heated seats. But what about the future, the part after tomorrow? This is where things really get exciting.

Qualities Only People Bring to Projects

As a professional software developer I have to constantly remain focused on who my work is for, which is people. Software has never paid me or thanked me. I continuously study, experiment and innovate because I want to remain ready and able to start building software today for tomorrow’s uses. I am determined to get my software in the hands of the people that are going to use it for their purposes.   These are qualities I do my best to bring to every project. These are qualities only people can fulfill on my team.

Each individual on the team has to contribute these qualities for the team to succeed. There is no project management software, development tool, or manual that can act as a substitute for these qualities in people. Where these qualities are lacking in people, no dress code or punctual arrivals can make up for it or paper over the money lost.

The vision is at the center, being the purpose for bringing into alignment and harmony the qualities of people.