... when developing software means think what you are doing ...
... when developing software was a "state of the art" process ...
... NOT NOW.
(sorry for my horrible English)...Continua
A must read for those work under large software company, or those interested in software engineering.
(1) The surgical team: I buy this idea also. Being a few minds working on a project is the right way to get out of the hell of endless discussion over coding and design. The role of the lead programmer and an assistance is good. But, the role is to lead, but not to dominate in every discussion making.
(2) The complexity of a software is the essence. I agree with this point. The software is one of the way to realize abstract idea into concrete structure(s). It is inevitably the reflection of one's mind. Unless the software is doing dull things, the complexity is the core, not the side-effects or ill-features. I think breaking down such a complexity is futile, instead we need to model as a complexity. To model the complexity is a great challenge, but not beyond today's scope. I hope that one unify way to model software will be out soon.
(3) The great minds are needed. As a educator, I don't buy this idea. But, from an industrial perspective, the great minds really work out effectively, with orders of improvement.
(5) Top-down design. I experienced myself. Without a concrete design and blindly developing "something" from bottom-up is definitely not the way out. It turns out that a project developing using a bottom-up approach would end up with many modules being difficult to communicate.
I end this writing here. But, it is not all the things about this book. It is worth reading, as a matter of fact. It is a valuable book for software managers, and team leaders, but not university students. It is because you can only know how to appreciate this book with a handful of experience....Continua