Click here to Skip to main content
Click here to Skip to main content

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

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

License

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 http://nakedalm.com/blog, and speaks often on Scrum, good practices and Visual Studio ALM.

You can get in touch with Martin through naked ALM.

Follow on   Twitter   Google+

Comments and Discussions

 
GeneralI do not agree PinmemberTomaž Štih22-Aug-07 10:17 
AnswerRe: I do not agree PinmemberMartin Hinshelwood22-Aug-07 10:46 
GeneralRe: I do not agree PinmemberTomaž Štih22-Aug-07 19:31 
From my experience the sharpest people in IT are the customization guys. They are the real world problem solvers. They get the unperfect tools and shape them into solutions. Developers are commonly a bunch of techies with weird ideas about business and weak relation to the real world. That commonly includes their analysts.
 
I think instead of going into a direction of general purpose software solutions we'll go into the direction of trying to improve selection of special purpose software solutions from a pool of existing solutions and better possibilities of integration.
 
I'd call the model "vertical IT specialization". We'll have expert companies in domain field that will be running the show. For example, one company will be expert in call centers. The difference from now will be that they will not sell their own solution ( which today makes them experts in conflict of interest too Smile | :) ) but instead five or ten different call center solutions - based on their customer budget & need. They'll specialize in projects of introducing IT solutions for call centers to the industry.
 
Indeed there might be some prefabricated components of greater sophistication then before - I agree to that - but from what we got so far (there were several generic business framework projects started by IBM and Microsoft years ago) the closest to success seems to be the classical German SAP/R3 model.
 
I find the Bloomberg model (with their Gateway) quite interesting. It enables you to have all the data from their system in your local database and integrate other systems with it. This practice might increase - business components will be designed with lots of events, lots of channels to import and export data - lots of means to integrate. We might get things such as "open architecture" or "open database". Such components might be produced by your firms. But they shall not prevail.
 
Because for every pocket there is a solution fitting.
GeneralGeneral solutions... PinprotectorMarc Clifton22-Aug-07 2:30 
GeneralRe: General solutions... PinmemberMartin Hinshelwood22-Aug-07 9:09