I’m no thought leader on the future of IT, but I do have a vision of how software development will evolve in the next couple (or hundreds) of years and Team system plays a big part in it. But before we dive into this vision, let’s have a look at what the development world looks like today.
What does software development look like today?
Today, software development is a craftsmanship, a lot like conventional industry was 400 years ago. Most software development teams are made up of a small amount of specialist developers, of which only a few actually master most of the available technologies or as Bart calls them in his article ‘The developer gap’, expert and regular developers.
In some cases these teams are self organizing, which means that they have managed to gather the right mix of developers, each talented in their own way, so that they can make all the necessary decisions for themselves. If you are in such a team, great, but reality tells me…
That there are just not enough good developers on the market to be sure that you can compose a self organizing team in the limited time you have to set up the project. Often you just have to work with less talented people, or people whose talents don’t match with the needs of the project.
And if you do manage to find the expert developers, you will only find a few and they will be pretty expensive. Both of these factors make that the software, which is supposed to add value to the business, will take several months to develop and will cost a lot of money. By the time the software is released, the market will already look differently and a lot of the effort goes to waste.
Don’t get me wrong, I like the idea of the self organizing team, and I would love to have a few thousands of colleagues that have as much expertise as the few dozen I currently have, but that’s just not how our market works. And trust me, after being in the Compuware recruiting team for a few years now, there are not many good developers available on the market.
Where should the industry go to?
In my opinion, the total cost of software development and the lack of talent on the market will force us to hire low cost, less skilled workers to complete our projects. We still have to go through the same revolution as happened with conventional industry in the 1800’s, we need to improve the current processes of software development and automate them into factories.
The biggest difference between IT and conventional industry, however, is that we are not developing the same parts all over again, which makes standardization a lot harder. Each project has different business needs and is started to solve a different problem, it will be very difficult to design a ‘Customer’ class that will fulfill the needs of a local grocery shop or that of your countries biggest transport company.
I don’t believe we can make some ‘Robot’ that will generate all the code of an application for us; instead I believe we should organize our software factory around a development process for which some tasks are fully automated, a few are done by expert developers and most of the labor is done by less skilled people, who don’t necessarily have to have skills in software development.
What needs to happen before we can achieve this?
As the state of software development is today, I don’t believe this revolution is at hand in a very short time. A lot needs to be changed before we can even think about large scale automation:
First of all, we need to find the default software architecture. If we want to automate the development of most types of software, we need to figure out what the default architecture is for each kind of application and define the common denominator. Today most teams start all over again for each software project they attempt, but to be productive they should start off with the default architecture and only make minor changes to it if a special feature is required. I believe this is probably the hardest task we are facing; I do have a default architecture for services, one for smart clients and one for web applications, but to achieve this goal all kinds of applications should be architected the same way preferably. Multiple defaults are possible as well, but that would make reuse of the assets much harder.
Secondly, all software components should be standardized. This means they all should conform to a certain design, a fixed interface. In transport, all containers fulfill to a number of standard sizes, no matter what can be transported with the container, no matter how it’s going to be transported. This way the containers are interchangeable allowing trucks, trains and boats to be designed without knowing what they are going to be used for. Once the interfaces of all software components are stabilized, general infrastructure code can be provided to allow faster and easier development.
Finally, each detail of the software development process, or better, the entire application lifecycle, should be studied and documented in detail. When a car manufacturer starts his assembly line, he will know exactly what parts are used at which points of the line, he knows how many milliseconds it will take to put a screw into the chassis, each part of the assembly line is controlled and monitored with great detail. When all details are documented, they can be assigned on an individual basis to non developers as well, in my opinion. With the correct documentation I do believe that a non developer can perform a code review targeting coding guidelines for example.
What technologies are required?
In order to automate some of the tasks, we can resort to code generation. However I’m not a big believer of code generation as each piece of code to be generated has its own specific needs. What I do believe in though is discrete code generation in the form of snippets and GAT recipes that can be used by less skilled developers to perform a specific task like creating a data access component for example.
If we would like to use non developers to actually create parts of the application, we need to provide them with a DSL so that they can configure the component with terms they know and have the code generated when they are finished.
But a software factory is more than just snippets, recipes and DSL’s. Each of these technologies is like a robot in a factory that can perform a small specific task. All of these robots should be combined with people (both expert developers as unskilled ones), to form an assembly line. The role of the assembly line can in my opinion be played by Team Foundation Server, and more specifically the process template and continuous integration features.
Team Foundation Server
Besides all the necessary tools that TFS provides us, like work item tracking, version control and a build server, it has one big advantage over different products: The process template. The process template gives us the means to set up the configuration of an assembly line.
We can create custom work items that can be interpreted by humans to perform a task, but using the work item object model, software components can interpret them as well and could automate some of the jobs. Obviously a standardized and well controlled process is crucial to achieve this.
Work items can be linked to code, in order to keep track of the time it took to complete the work, so that we can monitor how the assembly line is doing. Check-in policies allow us to enforce the linkage so that human interactions can be tracked as well.
Team build and more specifically MS Build allows us to perform automated compilation, testing, code metrics collection and automated deployment without knowledge of the developer checking in his code. With the TFS 2008 features and the SDC library, this task becomes even trivial.
All collected information is gathered in a data ware house so that the management team has a clear view of performance and quality at any moment through advanced reports.
My plans in the near future
I hope I have convinced you that TFS, or one of its successors, will be the key to the future software factory that I have in mind. In the near future I hope to write a series of articles on several parts of TFS and how you can use it to automate some of the tasks that need to be performed during the development of an application.
I will double post the articles that are directly related to software factories on both my own blog and the intofactories blog. Articles that cover only technical details of TFS like the build API or process customization will only be posted on my own blog so that IntoFactories stays focused on software factories only.