Introduction
I have been thinking a lot recently about the future of software development and where I see it going. I have worked for seven companies since leaving university (two design studios, two software studios, one community startup, one Internet bank, and one investment bank), and my conclusion is that all of the SSADM (Structured Systems Analysis and Design Methodologies), or Development Lifecycle, that I learned in university does not work in the real world. Yes, if you can charge your customers two million for an intranet that you will deliver over two years, you can do what you like, but these days, your customer's business moves too quickly for this to work. A solution that was started last year, or the year before in my current company, is obsolete, and has to be binned and started again. Or if the business has had its fingers in your specification from the get-go and if they have no idea what "signed-off" means, you will get only one result; you will never finish, and what you do finish will not meet the business need (80% syndrome).
With all of this in mind, we need to concentrate on Software Factories and Web Services that will allow us to reduce the time to market and increase the happiness of our clients. To do this, you need two distinct teams and an interface between them.
Why Ssoftware Factories?
Software factories are the answer to the ever increasing need to shorten development lifecycles. You can build and test large blocks of code in preparation to building certain types of applications. If you write effective software factories that you use regularly, you will be able to achieve a situation where you are 80% complete even before you start.
Why Web Services?
The main reason to use Web Services is centralized access to data and functionality. If you build your contact management system with Web Services on the back end, you will be able to link any other system that requires all or a part of that data. If you build your address checking system with Web Services, then any time you need an address in any application, you will be able to leverage the same tools.
Factory Development Team (The Brains)
The role of the factory team is to produce generic code packages that can be utilized by many applications to make the job of the product team easier and quicker. This can be done at the totally generic level, like the Web Service Software Factory from Microsoft, or at the specific level, for example, an implementation of Dijkstra's algorithm as a factory. The members of the factory team would spend a lot of their time in research and development of factory solutions, and quickly integrate any new technologies into their models. The Factory team must comprise the very best, guru and above, developers to be able to get useful solutions from them, and they need to be able to adapt quickly, and not be upset if an entire factory has to be dropped, due to the direction the business is taking, and a new one built from scratch. For the factory team, testing and stability is paramount, so it will take time to get to the right level.
Product Development Team (The Brawn)
The product team concentrates on delivering effective business solutions quickly using the factories provided by the factory team. The developers on this team only need to be of average skill to be able to use the provided frameworks effectively. The test time for solutions will be a lot quicker as the most complex code parts will have been fully tested by the factory team and it should be like using a boxed product.
Developer Evangelist (The Nerves)
The responsibility of the developer evangelist in this instance (although they have other roles) is to help the developers get to grips with the software factories and to take any feedback from the product team back to the factory team for them to incorporate into the next version of the factory. In addition to this, they should make sure that any developmental production problems are communicated effectively to the factory team. This is probably the most important role, encompassing trainer, developer, diplomat, and negotiator into one role for the aim of producing more value to the business, be it internal or external projects. The developer evangelist should be aware of, and be conversant, in all of the new technologies to be able to alert the factory team in new factory opportunities and to train the product team in them. They should have good links with the vendors of the products to be able to prepare the entire development and management teams in the advantages that can be gained by the new features.
With this model, your business will be able to effectively deliver solutions that will provide your, or your clients', business with an advantage over the competition. Yes, it takes dedication and perseverance to start this approach as it takes time to build your initial software factories. Obviously if you already have a development team that is currently producing solutions, then it will be all but impossible to change, but if you are starting out and have the freedom to construct a development team from scratch...
