MIS41020 - A Field Study of the Software Design Process for Large Systems

Module - Design, Development and Creativity

Class or Article - Article

Lesson or Name - Curtis, B., Krasner, H. & Iscoe, N. (1988) A Field Study of the Software Design Process for Large Systems. Communications of the ACM, 31, 1268-87.

Additional Info - 1268 - 87

Precis

In this article'A Field Study of the Software Design Process for Large Systems' by Curtis and Iscoe they investigate the software design process for large scale systems. Both Curtis and Iscoe are concerned with the problems exhibited by large scale project and set out to identify them. The problems faced by large scale development varied from one project to another. Curtis and Iscoe advocate that large scale projects require to be treated as learning, communication and negotiation processes in a cohesive and integrated manner. People who exerted greater knowledge of application domains tend to hold a greater impact and influence upon the team. Collaboration problem solving across smaller scale teams produced greater productivity over large scale teams. Similarly smaller design teams became increasing influential across multiple projects. A key observation from the research was when exception designers were available they found themselves positioned at the heart of projects and in turn held and accepted the responsibility to depart their knowledge and educate other team members. There are however implications across software tools and practices, project management, software process models and for the research itself into these fields. Curtis and Iscoe go on to future consider their own interview bias and the implications of this upon the research

Reflection

I really enjoyed this article, while long and detailed it was quiet enjoyable with some nuggets of information that I found intriguing but obvious at the same time. While saying their are obvious I do not mean to discredit the findings, I am considering them from my perspective saying that is obvious but it was not something I considered while I have certainly witnessed it. Additionally I have never considered the lack of domain knowledge or atleast the thin level of knowledge spread across teams. The decimation and departing of knowledge upon the team would not have been a role I would have expected or again considered to have been central to a project, but on reflection some of the most influential people on projects who I worked with always had a key skill for cascading knowledge at all levels across a range of different people and skills. These people are actually some of the people who I look up to the most, had the best time on projects with and as a result hold in high esteem. Software design is not easy and creating a great team is not easy, it take time and understanding and on reflection of some of the projects and programmes I have worked on the ones I enjoyed the most is where everyone was treated as equals, contributed and collaborated. On a large scale program everyone needs to know and understand their role, but at the same time support and elevate other members of the team. The behaviours of the key members of the team play a big role in the performance of group.

Quotes