Click here to Skip to main content
13,452,396 members (56,561 online)
Click here to Skip to main content
Add your own
alternative version


16 bookmarked
Posted 21 Aug 2007

The future of software development

, 21 Aug 2007
Rate this:
Please Sign up or sign in to vote.
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...


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...


This article, along with any associated source code and files, is licensed under The Microsoft Public License (Ms-PL)


About the Author

Martin Hinshelwood
Instructor / Trainer naked ALM
United States United States

About the Author: Martin has worked with many customers in government, finance, manufacturing, health and technology to help them improve their processes and deliver more. He provides management and technical consulting that intends to expose processes and practices to gain transparency, uncover impediments to value delivery and reduce cycle-time as part of an organisations path to agility. Martin is a Professional Scrum Trainer as well as a Visual Studio ALM MVP and Visual Studio ALM Ranger. He writes regularly on, and speaks often on Scrum, good practices and Visual Studio ALM.

You can get in touch with Martin through naked ALM.

You may also be interested in...


Comments and Discussions

GeneralI do not agree Pin
Tomaž Štih22-Aug-07 10:17
memberTomaž Štih22-Aug-07 10:17 
AnswerRe: I do not agree Pin
Martin Hinshelwood22-Aug-07 10:46
memberMartin Hinshelwood22-Aug-07 10:46 
GeneralRe: I do not agree Pin
Tomaž Štih22-Aug-07 19:31
memberTomaž Štih22-Aug-07 19:31 
GeneralGeneral solutions... Pin
Marc Clifton22-Aug-07 2:30
protectorMarc Clifton22-Aug-07 2:30 
...often do not fit specific requirements.

Software factories sound great, but what they produce doesn't usually fit well from one application to another, as there's new technologies to deal with, new requirements, and so forth.


GeneralRe: General solutions... Pin
Martin Hinshelwood22-Aug-07 9:09
memberMartin Hinshelwood22-Aug-07 9:09 
Generalnot the future... [modified] Pin
toxcct21-Aug-07 23:00
mvptoxcct21-Aug-07 23:00 
GeneralRe: not the future... Pin
Martin Hinshelwood22-Aug-07 9:02
memberMartin Hinshelwood22-Aug-07 9:02 
GeneralRe: not the future... Pin
toxcct22-Aug-07 21:22
mvptoxcct22-Aug-07 21:22 
GeneralRe: not the future... Pin
Martin Hinshelwood22-Aug-07 22:26
memberMartin Hinshelwood22-Aug-07 22:26 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Terms of Use | Mobile
Web03 | 2.8.180318.3 | Last Updated 22 Aug 2007
Article Copyright 2007 by Martin Hinshelwood
Everything else Copyright © CodeProject, 1999-2018
Layout: fixed | fluid