Produktinformation
Möchten Sie die Produktinformationen aktualisieren oder Feedback zu den Produktabbildungen geben?
Ist der Verkauf dieses Produkts für Sie nicht akzeptabel? |
Vorgeschlagene Tags zu ähnlichen Produkten(Was ist das?)Setzen Sie den ersten relevanten Tag hinzu (ein Schlüsselwort, das mit diesem Produkt in engem Zusammenhang steht).
|
So who could possibly be holding on to a methodology that is demonstrably inappropriate for modern small software groups developing commercial products? Mr. McBreen fingers managers whose pay and prestige depend upon head count. Turning every project into a relay race with analysts, designers, programmers and testers guarantees many billable hours while intellectual property is passed on from group to group. Preferentially hiring young, inexperienced programmers and capping the salary rate ensures a bloated staff with high care and feeding needs. It's a provocative assertion that will certainly engender debate.
McBreen says he wants to join in the public conversation that already includes the voices of Richard Stallman, Linux Torvalds and Kent Beck. His intelligent analysis of the origins of classical software engineering and why it is no longer a good paradigm for commercial software development will help keep that conversation informed and productive, as well as lively.
* Books mentioned by Mr. McBreen include:
The Pragmatic Programmer by Andrew Hunt and David Thomas ISBN: 020161622X
The Inmates are Running the Asylum by Alan Cooper ISBN: 0672316498
Software Craftsmanship presents a view that software developers should return to their craftsman roots in order to deal with the increasing complexity of today's development demands. McBreen makes the case that building software systems requires a set of skills and experiences beyond just book learning, training courses, methodologies, and CASE tools. A craftsman paradigm is presented in which an apprentice software developer learns from journeyman in much the same way other craftsman based professions do.
This concept is both interesting and timely in light of the recent failures of systems ranging from the FAA and IRS to dot-coms. McBreen presents this concept as a counter to software engineering methods (SWE), which he proceeds to blame for many of the woes of the industry.
Starting with the Preface, McBreen confuses the engineering aspects of software with software manufacturing. He quotes a 1969 NATO report from Naur and Randell, which is not only out of date, but inappropriate in todays software engineering discipline. This use of dated reference materials continues in many chapters and creates the impression that McBreen may not have done his homework.
His case against software engineering has useful points but many of the issues he brings up are well worn red herrings. His Big Project example is nearly 20 years old and in a domain unfamiliar to many - a ballistic missile defense system (the first such system). Surely we have learned something about software engineering in the intervening time since 1975.
McBreen approaches the issue of software engineer licensing as a potential threat to software craftsman. But he does not provide a balanced view for this topic, since the licensing of process system engineers writing software for mission critical systems has been in place for decades. A look at the European TÜV and SINTEF regulations would have provided some background on addressing this issue in the US.
One issue with the book is that it does not establish a context in which to discuss the topic of craftsmanship-based software development. Customer relationships, development processes, project management processes, examples of success and failure are not placed in a context. One place to look for a taxonomy of software projects and their attributes would have been the Capers Jones series. These texts provide a broad as well as deep view of the complexities of software development and the risks of naively apply one size fits all to a problem.
This one size fits all approach is addressed by McBreen in a later chapter. He states that ones size does not fit all, but then proceeds to provide advice and direction to the reader on how to apply craftsmanship methods in the absence of a specific problem domain. The process of developing craftsman-based software for a business application with an on-site customer is significantly different than developing software within a highly regulated or globally distributed corporation using COTS products.
Although there is much to offer in the book, I have some specific issues with the material, its sources - or lack of sources - as well as the overall tone for what is presented as a New Imperative.
found the book a stimulating read, although frustrating at times when I encountered comments like the Java one above. The major gaps in understanding might be attributed to McBreen's lack of experience in those areas. Gaps that could have been easily filled with research. These gaps I also attribute to poor copy editing, but that is another issue all together.
I would recommend the book, but with qualifications and caveats. The read should try to put the ideas into a context and ask are these concepts appropriate for my domain? Do the ideas make sense for the specifics of my problem? Does the specific statement actually make sense from my own experience and the experience of others? Have I seem a similar concept in a peer reviewed journal or are these simply the opinions of the author with an axe to grind?
McBreen gives credit to the SEI, Jones, Coplien, Highsmith, Cockburn and others, but he appears to have left much of their contribution out of this book and on the shelf.
McBreen presents an apprenticeship model for the development of programmers that actually has been done at times and places, although much less formally. My first programming job was something similar to this and stands in strong contrast to the world today where a new hire from college has a "software engineer" title and thrown into the deep end of the pool. I imagine many new graduates from MIT or Berkeley would be insulted at the idea of taking a job with a title "Programmer Trainee". Some of us have done just that.
This book is a great read, and, as with so many good books, it's too short. He presents the craftmanship model but the book cries out for more explanation on implementation and what has happened when it is implemented. Many of us cannot implement company-wide changes ourselves, however, we can see programming in a new light and possibly begin change, in our own work, how it's approached and written.
So who could possibly be holding on to a methodology that is demonstrably inappropriate for modern small software groups developing commercial products? Mr. McBreen fingers managers whose pay and prestige depend upon head count. Turning every project into a relay race with analysts, designers, programmers and testers guarantees many billable hours while intellectual property is passed on from group to group. Preferentially hiring young, inexperienced programmers and capping the salary rate ensures a bloated staff with high care and feeding needs. It's a provocative assertion that will certainly engender debate.
McBreen says he wants to join in the public conversation that already includes the voices of Richard Stallman, Linux Torvalds and Kent Beck. His intelligent analysis of the origins of classical software engineering and why it is no longer a good paradigm for commercial software development will help keep that conversation informed and productive, as well as lively.
* Books mentioned by Mr. McBreen include:
The Pragmatic Programmer by Andrew Hunt and David Thomas ISBN: 020161622X
The Inmates are Running the Asylum by Alan Cooper ISBN: 0672316498
|
Das Forum zu diesem Produkt
Fragen stellen, Meinungen austauschen, Einblicke gewinnen Aktive Diskussionen in ähnlichen Foren
Kundendiskussionen durchsuchen
|
Ähnliche Foren
|
||||||||||||||||||||||||||||||||||
|
|
|