Keep All Re-use in mind when establishing your Software Development Process

Published in CMCrossRoads.com September 2002 Newsletter

Software re-use is a worthy and noble ideal to aim for during any development, but why not let’s take a bigger picture view of the whole software development environment. Make the goal to set up our process so that as much as possible is re-used on subsequent projects. Here are some thoughts on achieving this...

Introduction

It has always amazed me at how many individuals and companies take such a short term view on all their software development projects. Of the three most recent high profile large projects (>100 people) I was involved with over the last four years, helping implement process, there seemed to be a recurring theme of everyone being in the mindset of “let’s just get this software working and worry about anything else later”. By anything else I mean concepts such as:

· defining a Configuration Management Policy

· defining a Change Control Policy

· defining a Requirements Management Policy

· defining a Software Architecture Document

· defining a Project Software Development Plan

· defining a Software Testing Policy

· defining a Deployment policy

· etc

At best they may have given in to developing process and policy around some of the above concepts but only in the light of the “current project”, certainly not even thinking about the next project or processes that could be re-used at an IT level on future projects in general.

I realize I am generalizing and making broad sweeping statements. No doubt there are countless places where the control over software development is far more mature and controlled than I have described above, but I would also guess that these are probably far smaller projects and teams on less high profile projects.

Personality profiles, team-dynamics and re-using people on projects

There seems to be a natural tendency in life for louder, more assertive and aggressive people to reach positions of leadership and control in software projects. While it is necessary to have firm leadership and some sense of discipline, it is sometimes in direct conflict with the type of people that are actually needed in these situations of complex software development, where the quieter types of thoughtful people who think and plan first using raw logic, are far better at putting into place what is required for both short and long term success. Often these people are not assertive enough to push their well thought out ideas and they get steamrollered by the louder more impetuous management types.

I assert that the mix of team member profile types required in the software development process should be a mixture of very different kinds for true project success, but they ought to be able to collaborate efficiently together with mutual respect for one another’s key skills.

A lot of very interesting work has been done in this area, initially started by Carl Jung, and has more recently evolved into different profile measuring mechanisms, such as MBTI, and MTR-I, etc. Check out http://www.typelogic.com for the different profiles, also http://www.teamtechnology.co.uk for the different team dynamics and how these types interact. There is a lot that can be said and discussed about these personality types in relation to software development processes, which I’ll save for another article in the future.

Suffice to say that if the mix of people is not firstly appreciated and secondly correct, the balance is easily lost making it more difficult to succeed. As an ongoing effort, the team mix at a senior level has to be brought to a balanced state, re-using certain people and bringing in others on the basis of their profile types for the role to keep the balance.

So from project to project one should aim to build up a permanent key set of mutually balanced profiled type people. This is an iterative process both over projects and on any one project.

Concept vision for Artifact and Architecture re-use planning

I envisage a day, within a large global IT environment where, when a new project starts, the software development environment is configured by instantiating an instance of a previous project, and removing all past project content. This would mean that you would have:

A ready set up office of available PC’s with a new Project Footprint according to the latest company standard development process and software development environment.
This PC’s footprint would have all Software Integrated Development Environments on it. E.g. UML Modeller, Code IDE, CM Tools, Change Management tools, Requirements Management Tools, Project Tools, Web Servers, App Servers, DB Servers, etc. (Obviously this would always be under constant incremental improvement and version control.)
Ready defined blank templates of all documents, with company logo’s, company font and colour scheme aesthetics for all possible artifacts. Typically a super-set of what’s likely to be used.
Ready defined Architectural Models (in UML or other modeling standards) of the Company Hardware, Operating Systems and Middleware layers.
Access to any related Applications Models that your new project may have to interface with or even change. This would include all Use Case Textual and Diagrammatic Models, All Design and Implementation models.
All defined Configuration Management plans and policies, Change Control plans and policies, Requirements Management plans and policy, Software Testing plans and policy, Deployment plans and policy, etc.
All of the above accessible through the company standard Software Configuration Environment with full Version, Build and Release control.
A standard intranet framework for this particular project, ready to add in the people on the project and ready to begin being the “newspaper” and shared central communication mechanism of the project, for the project’s lifecycle.

The Process Engineering team for the IT department would continuously refine the process (defining the software factory) across projects and within individual projects, using the same version and configuration control that the actual developers use to manage their software (software built in the factory).

Conclusion

I guess the message I’m trying to convey is, try and think further than this project in all that you develop. Embrace the concept of re-use in all dimensions, not only software components, but Artifacts, Architecture, People, Process, Projects, etc.

[This article probably raises more questions than it answers! I’d be interested in email comments or questions where I may have been a little vague or you don’t understand.]

References

Less Haste, More Speed - Nicolle, Lindsay 2001