This entry is a reaction paper in our Software Engineering class regarding Frederick P Brook’s essay entitled “The Surgical Team”
INTRODUCTION
“When Compliance and Lesson Learned Converged In a Paper”
This is a compliance.
Among the ways to start a paper’s introduction, the above statement is “inappropriate” in nature and specifically “direct” in approach. But it only shows what this paper is all about. This is indeed a compliance that needs to be submitted on time and would require a lot research effort in order to showcase the author’s intent and ideas. It is called “reality” and more often than not, the truth is painful.
Frederick P Brook’s essay dubbed “the Surgical Team” exposes such reality through an analogy of a “surgical team” in order to address an impeding problem in developing software systems as a team. It is an eye-opener and a lesson learned particularly if you were able to experience working with a group of programmer enthusiasts eyeing to deliver a “working” system. It presents collaboration, effective distribution of work, responsibility, and most importantly the trust that the whole group will be able to make it.
This paper is just a commentary written in words but the lesson you can get goes beyond that. It might be a compliance but when converged with real life’s insights becomes a sound that knows no end, knows no bound.
Sit back and relax. Let me unravel what Mr Brooks wants you to learn when he wrote the book 10 years ago.
THE “DILEMMA”
Mr Frederick Brooks called it the “problem” but I prefer calling it the “dilemma”. The issue raised on the initial statements of “the Surgical Team” essay talks about two major concerns – first is the need to deliver a large-scale project (the requirement) and second is the number of people who will do it (the performers).
The requirement has been identified in an exaggerated way to showcase the extremity and the possible complexity of the client’s expected system. What if your company is to develop a huge and critical system in a small span of time, limited budget, and only a number of people? Added to the agony is the diversity of your group that consists of good and bad programmers. Since you have to deliver immediately and with quality, you certainly have the option to play around with your members – to either allow all of them to work and embrace the possibility of mediocrity plus high cost or to just choose those performing programmers who can really deliver but will jeopardize delivery time.
This problem is not new mostly in a software development setup. A research conducted by Roger D Pendharkar in 2009 stated that project managers tend to increase the team size due to the following:
A) Pressure to meet the schedule, as competitive advantage of the technology decreases with time.
B) Assigning one person to a project does not mean linear completion time.
C) Dividing work into small sub-projects allows many people to work on a project simultaneously.
Yet like what Mr Brooks mentioned that this setup will lead to high cost of communication and ill effects of correcting miscommunication. On the contrary, if the “small sharp” group will remain and as mentioned if the development will utilize the “brute force” approach, the number is too small for large systems. This is now a crossroad between efficiency plus conceptual integrity and bringing considerable manpower for the project to be timely.
Now the big questions are – How are we going to combine these options? If not, what are we going to choose?
A Computer Science professor at the Florida Institute of Technology named “Harlan D Mills” had a fresh and creative solution. What if instead of giving the task to all the members that leads to expected undesirable results, we segregate the large tasks to separate team where one does the work while the others support him. The analogy used is a “surgical team” but in the real world they called it the “development team”.
WHEN A SURGICAL TEAM STARTS TO CODE
Mr Harlan D Mills suggested a way in order to address the problem in the timely delivery of the system and maximizing the available people in a team. He proposed that each segment of a large job be tackled by a team but that team be organized like a surgical team. One will be “main implementer” while the others give him all the support that will enhance his effectiveness and productivity. They call this technique the “chief programming concept”.
This approach, ideally, consists of ten people (seven of which are professionals) where each member will be given a specific role. Metaphorically, Brooks explained the functions of each member by using its analogy to a surgical team:
The Surgeon is also called the “chief programmer” where he does most of the critical tasks – defines the functional and performance specifications, designs the program, codes it, tests it, and writes its documentation. He is the major player in the team where other tasks are inline to his plans and execution, making programming as Brook relates a “public practice instead of a private art”. This is still being applied in the current software development team set-up though the “one-man show” approach is not always the case. The roles of the chief programmer currently is divided into four other personalities or groups – System Analysts (design), Programmer (coding), Quality Assurance (testing), and Documentation (documents). If this approach will be explicitly followed, though armed with other support co-team members, might also lead to undesirable results knowing the flexibility, dynamism, and fast-paced requirements of current systems.
The Co-Pilot is the assistant of the chief programmer. He is an evaluator of what the chief does and also thinks of designs for the system. He knows the code intimately and might do coding but not as a primary duty. In current implementation, this one plays the role of assistant technical lead.
The Administrator is the one responsible for the management of other the team’s other operational aspects such as money, people, space, machines, and other administrative duties. In the current implementation, the roles played by this person are assumed by other personalities such as – CEO, Human Resource Manager, Accountant/Finance, Facilities and Equipment. Again, it would be cumbersome in the current setup for one person or group to do all these tasks mostly if the personnel number is quite huge.
The Editor is the one who scrutinizes and improves the documentation done by the chief programmer. A company editor or team editor is what this person plays in the current set-up. Though, again, everything is being done initially by the chief.
Two secretaries for administrator and editor which is also currently being applied.
The Program Clerk does all the archiving of technical records of a team in a programming-product library. This role is beneficial to the team mostly when codes are to be re-used and project archiving is necessary. Though current implementation makes this role an automated one with programs such as Online Archiving or the CVS. This allows the programmers or even QA and Documentation to archive and manage their files individually, at their own convenience, and real time. This also includes logging capability, continuous status update, and easy file retrieval.
The Toolsmith develops online and interactive special tools such as specialized utilities, catalog procedures and macro libraries that will allow the team to focus on their specific tasks. There are some software development companies who hire and maintain people who dedicatedly develop utilities or tools for the consummation of the organization. It does not only simplifies the task but it also introduces innovative ways on dealing with repetitive and manual manner of doing things.
The Tester is the one who assures quality by creating test cases based on functional requirements and creating data for the chief’s day-to-day debugging. This is still being applied in the current setup though the bulk of testing work is now assigned to the QA team instead of just by the chief programmer.
The Language Lawyer is the “expert” or “consultant” as what the current software development teams call them. They mastered the programming language being used by the chief programmer and advise on certain scenarios.
These are the people that compose the whole “surgical team”; each of which has a function to perform and an expected deliverable. Implementation of such approach according to Brooks will lead to the following results:
A) As compared to conventionally organized programmers where tasks are divided to different developers and design/implementation are different, the chief and the co-pilot are both aware of the design and code. This saves the labor of allocating space, disk access, and ensuring of conceptual integrity of work.
B) Since in a conventional team partners are equal, differences in judgement must be talked about or compromised. In the surgical team, the chief solves the differences unilaterally and specialization of the remainder team permits a radically simpler communication pattern among members.
Though if we are to apply such concept in the development of current software systems, it is still safe to say that such approach may seem inappropriate. Here are some of the considerations:
A) In a research entitled “The Role of Motivation and Risk Behaviour in Software Development Process” by Kenneth R Walsh and Helmut Schneider, they raised the concern on implementing such concept in ERP systems. According to them, a chief programmer may push a technical solution rather than a business solution. The responsibility for ERP projects rest with the line management because a successful implementation requires reengineering of business processes that are the responsibility of the respective managers. However, line managers often lack the understanding of information technology, and may take higher risks than appropriate.
B) It will be quite tedious for a chief programmer (or at most two programmers) to do the critical tasks of analysing to testing. Though supporters might verify, this might lead to a monopolized decision.
SO WHAT NOW?
So, what now?
This question poses the challenge to you, the reader. The beauty of software development does not only depend on the outcome of each project but primarily on how it is being done. We can follow a well-proven and well-tested approach or we take the risk of implementing a new one to see what happens. The “Surgical Team” approach may be appropriate to answer the need of doing large systems with a number of people and other factors or otherwise. Nonetheless, this option has been introduced to give you a wide array of possible approaches on a certain problem.
Once again, what now?
The answer lies in your hands.
REFERENCES
Details of this reaction paper are taken from the following resources:
BROOKS, F. (2009). The Mythical Man-Month – Anniversary Edition. 29-35.
PENDHARKAR, P., & RODGER, J. (2009). The Relationship between Software Development Team Size and Software Development Cost. Communications of the ACM, 52(1), 141-144. Retrieved from Business Source Elite database.
SAWYER, S. (2004). SOFTWARE DEVELOPMENT TEAMS. Communications of the ACM, 47(12), 95-99. Retrieved from Business Source Elite database.
WALSH, K. (2002) The Role of Motivation and Risk Behaviour in Software Development Process. 1-5.
http://en.wikipedia.org/wiki/Harlan_Mills