Well. What I’ve learned from this book, in fact, it’s stated from the start (I don’t remember at which point exactly, but I think it was in the beginning chapters); It’s that there isn’t a thing that causes problems and delays, there isn’t a specific thing that the book, the teacher or anybody else can tell you and warn you about at the moment when you become a software manager, or project owner, or developer.
Things just happen. A lot of them. At the start it’s just something simple, maybe something that no one thought that it could evolve to something else. Then another thing appears, now you notice but you don’t react immediately, and then another, and another, while the progress keeps getting slower and slower. And then the morale gets lower, and the performance too, and the client gets mad.
It’s a sad and stressful path. And there really isn’t something that you could know it will happen in every project. But you can try to prevent, everything, and make plans for every scenario if it comes to be, even if at the end the project goes very well.
And this is what the rest of the book is about. What is to really manage a software project and everything you can do when assuming such position. Either as a manager for the architects or a manager for the implementers, or general manager.
A basic concept for a good project to try to get to the end is communication. There is no chapter in the book where this capacity isn’t mentioned. It’s very important. At first level, there needs to be a very good communication between the architects and the implementers’ representatives. This is essential because the implementer will try to keep the architect from the skies and
Conceptual integrity is to maintain the good initial ideas, even if it implies not making that many features. This is better than having lots of uncoordinated ideas.
Likewise, functionality and simplicity. Which is better? There have been software projects that have an outstanding performance in one of both. But we have to say that it’s a combination of simplicity and straightforwardness. Every part must use the same philosophies, same semantics and syntax and the, you have conceptual integrity.
And how, or more precisely, who will achieve that integrity? Either one mind (Surgical team), the equivalent to an aristocracy; or a handful of minds, with a division of architecture and implementation, the equivalent to a democracy.
And it’s no bad to desire a democracy, but it has several problems. The people in charge of the architecture should consider methods to implement their architecture; the implementers, when suggesting ideas must preserve the integrity of the architects.
That’s why at the end, the aristocracy (Surgical team) is better because as long as the design and implementation are clear in the surgeon’s mind, everything is ok. Or at least, an aristocracy of architects, who have a clear idea of how the system should behave, and they should decide how to maintain integrity, even if that means to leave the implementers with practically no voice, at the end, what must endure the most is the design, not the implementation.
The dream: To develop a project with a small team you can know, and trust in their abilities. Forget the big teams, integrated by mediocre developers. In fact, by spending the double on a very good programmer, 10 times the performance could be expected. We can do this all by ourselves. Ah… The dream…
The reality: Big and complex problems need to be done and big teams are needed to do this.
How? Harlan Mills offers a solution. To make several teams, where only one member of each attacks the problem, and the rest only assist him in achieving maximum productivity. You keep a few number of people in the building design, but a lot of them in the actual construction. Just like a surgical team.
Here are the roles of this approach:
The surgeon: Define functional and performance specification. Designs, codes, tests the program and writes its documentation.
The copilot: Is a less-experienced surgeon. He advises the surgeon, and he can listen to him, or not. He knows the code perfectly but isn’t responsible for it.
The administrator: Even though the surgeon is the boss, he needs someone to be in charge of his administrative (Money, personnel, machines…) decisions. The administrator can serve 2 teams.
The editor: He writes the external and internal documentation. He reworks the draft of the surgeon.
Two secretaries: One for the administrator and the other one for the editor.
The program clerk: He is in charge of the maintenance of the machine and user readable files.
The toolsmith: File, text and debugging services. Made fast and with quality
The tester: Design test cases and data.
The language lawyer: Master of the language selected for development. Can work with 2 or 3 surgeons.
Because the purpose of this team organization such that everyone is represented