Journey of the Software Professional: The Sociology of Software Development [Hardcover]

Luke Hohmann (Author)

Book Description

Publication Date: October 17, 1996 | ISBN-10: 0132366134 | ISBN-13: 978-0132366137 | Edition: 1

A comprehensive guide to the software development process that will help software developers at every stage of their career: improving personal performance, learning to work well in a team, and managing to create an environment where others can be most effective.Addresses the psychological and sociological aspects of software development, presenting a thorough model of individual and collective software problem-solving behavior, and practical techniques for enhancing the process. Covers the structures, processes and outcomes common to most software development projects, and how to improve them. Presents ideas on using tools and training more effectively, and on improving the performance of teams. Shows how to build on your personal and management successes, and avoid the most common errors.Programmers, developers, software managers, students, and anyone involved in the software creation process.

Editorial Reviews

From the Publisher

A comprehensive guide to the software development process that will help software developers at every stage of their career: improving personal performance, learning to work well in a team, and managing to create an environment where others can be most effective.

From the Inside Flap

It was my first managerial assignment. I was ready. I had worked as a developer for several years on many different projects. Some were successful. From these I learned what to do. Some were failures. From these I learned what not to do. I was armed with a masters degree in Computer Science and Engineering from a prestigious University. I had studied software engineering and was ready to apply it. I read a lot of books on managing people and projects, from Peopleware to The Mythical Man-Month. Their advice and insights from the trenches of software development made sense. I was going to follow all of it.

The cold truth slowly sank in. My first job as a manager was less than a stellar success. Yes, the project was completed, the system was implemented, but I could have done a far better job. Since then I've led other projects and in the process learned many things. Past project experiences don't always apply in new projects. In fact, what brings success in one context causes failure in another. Learning about software engineering is far different from doing software engineering. And, while all the advice given in “Peopleware” books is definitely useful, I found myself continually asking, “What are the underlying principles of software development? What might guide or drive the advice and insight of people like Gerald Weinberg, Frederick Brooks, Larry Constantine, and Tom DeMarco1?”

This book was written for three reasons. First, it explores the underlying principles of software development through a simple but comprehensive theoretical framework. Second, it shows how to put this framework to good use through practical advice built on top of the theory. Third, it contains specific advice for both developers and managers in a clear and understandable format.

Why include practical advice and the theoretical framework supporting it in the same book? If a book gives practical advice but lacks a theoretical foundation you are left wondering from what credible principles the “advice” is drawn and how to successfully apply the "advice" in your environment. If a book provides only theory, you are left wondering about its practicality. Even the most elegant theory requires examples of how it is used to provide value. Theory is important for providing a way of thinking about a topic, but theory without practice is a car with no engine. While the majority of the book consists of practical advice, it contains the theory necessary to support it.

One advantage to practical advice is that it can provide a ready response to a tough situation. But, what happens when you are faced with a situation not described in this book? Alternatively, what happens when you disagree with my advice? Once again the theoretical foundation of this book becomes essential, for it provides you with the tools you need to create your own advice and respond effectively to novel situations.

Finally, you may have wondered why I've included specific advice to developers and managers in the same book. Their jobs are decidedly different and often antagonistic, right? A book certainly cannot give advice to both at the same time, right? Wrong. Certainly the jobs of developers and managers are different. So what? Take any difficult problem faced by a group of developers and their management. Unless each member of the group understands what they can do to improve the situation and plays their role things are not likely to improve. Isn't the real job of every person involved with the development effort to ship the best system possible? Instead of emphasizing differences, perhaps we should emphasize the ways developers and managers can work together. This book was not written for the intersection of the population of developers and managers. It was written for the union.

“What's In it For Me?”

Here is what this book will do for you:

- it provides a simple and comprehensive theory of how developers and teams of developers create software.

- it shows how advice found in other books makes more sense when applied in the context of this theory. After reading this book, you will never think of a data model or a coding standard in the same way again!

- it will introduce you to several new strategies and techniques on improving you and your team's effectiveness.

- it makes understanding and implementing these strategies and techniques easier by giving explicit advice to both managers and developers. I don't want you to waste any time trying to determine if the practical advice in this book is intended for a manager or a developer. Instead, I want you put these ideas into practice as quickly as possible.

- it addresses a broad range of topics and issues not usually addressed in most books on software development you will encounter over the course of your career. While you may not have an immediate need for every chapter, owning this book means you will be prepared to address these issues when they do arise. And they will.

Finally, it seeks to entertain you with personal stories and anecdotes that illustrate, expand, or otherwise bring to life the ideas in the book. These are offset from the main text in an italicized font.

Content and Organization

This book is organized in five parts.

Part I describes the mental processes of software development. It integrates cognitive models (models of how we think) with software methods (specifications of the activities we should undertake when developing software).

Part II explores a wide variety of topics on how individuals and their managers can improve performance using the SPO framework presented in Part I. My goal is two-fold. First, I hope to show how some of the traditional advice found in other books on such topics as code reviews makes better sense when applied in the context of the SPO framework. Second, I hope to introduce you to some new ideas such as future perfect thinking and how (and when) to make pancakes!

Part III applies the SPO framework to teams. It moves from cognitive models (which describe the individual) to organizational models (which describe interactions between individuals). Integrating organizational models with methods shows how the SPO framework provides a single, cohesive framework helping us to understand, predict, and guide both individual and collective behavior.

Part IV mirrors part two by using the SPO framework as the foundation for practical advice designed to enhance the effectiveness of teams. Again, I hope to show how traditional advice on such topics as the importance of standards make better sense when discussed in the context of the SPO framework. Of course, I also hope to introduce you to some fresh approaches to common problems such as building trust between developers, creating appropriate system architectures and structuring teams to support them, and writing useful status reports.

Part V concludes with a discussion of issues related to context-such as learning how to avoid poor working environments. It also deals with creating (or finding) the right context in which to apply the advice contained in parts two and four and serves to round out the book.

There structure of the book is as follows:

The Individual Chapters

Part One: Theory

1 - 2

Part Two: Practice 3 - 6

The Team

Part Three: Theory 7 - 8

Part Four: Practice 9 - 14

Context

Part Five

15 - 17

Audience

There are three distinct paths in the journey of the software professional. In the first, effort is focused inward, and the goal is improving personal performance. In the second, effort is directed outward, and the goal is improving both self and others. In the third, effort is directed upward, and the goal is to create an environment whereby others can be most effective. This book was written to address the needs of a developer on each stage of the journey.

Here are some ways specific populations can benefit from this book.

If you are a student or developer with less than 3 years working experience you are likely to be concentrating your efforts on stage one of the journey. If this is true then reading this book will provide you with the theoretical foundation necessary to understand how to improve your effectiveness. At times the book may be a bit challenging, but rest assured the effort you put into reading it will be worthwhile.

If you are an experienced developer (e.g., a senior architect or lead designer), then you are probably in the second stage of the journey. In other words, your primary job is to help others be effective by capitalizing on your experience. Such a job is uniquely demanding: you've got to marry technical and social demands. But how do technical and social issues really interact? Reading this book provides the foundation for discussing the answer. Of special interest to you are parts three and four which concentrate on teams, especially chapters seven and twelve.

Finally, managers of all levels of experience can derive several benefits from reading this book.

First, an understanding of how developers work both individually and in teams as they create software is a necessary prerequisite for the establishment of effective managerial practices. To see why, just read any Dilbert cartoon!

Second, the practical advice serves as a managerial handbook and provides specific answers to difficult questions in the context of a strong theoretical framework. Third, as a manager you have the responsibility for creating an effective work environment. A strong theoretical framework enables you to accomplish this effectively (see especially chapters nine, ten, and eleven).

How to Read This Book

First, read chapter one. The primary constructs of the SPO framework are established in chapter one. Reading this chapter first will provide a background in the primary terms as used in the remainder of the book.

Second, feel free to skip chapters in parts two and four. This book can be read quite satisfactorily in a non-linear fashion. Be forewarned some of the practical advice may seem a little out of place without the theoretical foundation in place to support it. Because of this, I do recommend you read part one before any chapter in part two, and part three before any chapter of part four.

Finally, read aggressively. Highlight or underline passages you think are important. Make notes to yourself in the margin. Dog-ear important pages for quick reference. Do whatever you need to do to make the most of it!

One Final Word

The writing of this book, like the creation of a large software system, is a strange journey, one never quite finished. To further my own personal journey, I ask you write me concerning the material presented herein. What did you like? What is useful? What benefits have you derived from reading this book? How can I improve the material in either form, content, or presentation?

I wish you a long and interesting journey, filled with an appreciation for our chosen profession. Thank you, and enjoy what follows.

Luke Hohmann lhohmann@objectspace

See all Editorial Reviews

Product Details

• Hardcover: 454 pages
• Publisher: Prentice Hall; 1 edition (October 17, 1996)
• Language: English
• ISBN-10: 0132366134
• ISBN-13: 978-0132366137
• Product Dimensions: 9.3 x 6.3 x 1 inches
• Shipping Weight: 1.6 pounds (View shipping rates and policies)
• Average Customer Review: 3.8 out of 5 stars  See all reviews (13 customer reviews)
• Amazon Best Sellers Rank: #1,436,106 in Books (See Top 100 in Books)

More About the Author

Luke Hohmann is the founder and CEO of Enthiosys, Inc., a Silicon Valley-
based software product strategy and management consulting firm. Luke graduated magna cum laude with a B.S.E. in computer engineering and an M.S.E in computer science and engineering from the University of Michigan. While at Michigan he studied cognitive psychology and organizational
behavior in addition to data structures and artificial intelligence. He is a former National Junior Pairs Figure Skating Champion and American College of Sports Medicine certified aerobics instructor. He is a member of the PDMA, ACM, and IEEE.

Customer Reviews

Most Helpful Customer Reviews

10 of 11 people found the following review helpful:

5.0 out of 5 stars A software manager's "must read", January 9, 2001

By 

B. Scott Andersen (Acton, MA USA) - See all my reviews
(REAL NAME)   

This review is from: Journey of the Software Professional: The Sociology of Software Development (Hardcover)

Journey of the Software Professional is an impressive work. It begins with a Forward by noted author Gerald Weinberg (The Psychology of Computer Programming, etc.) where Weinberg says "In many ways, it opened my eyes. If you are a software professional, I think it will open yours as well." I couldn't have said it better.

This book should be read by software development managers before their first assignments. Hohmann not only provides software engineering guidance and wisdom in real-world context but also, where possible, backs up his thinking with published works, all carefully annotated.

What separates this work from most software engineering texts is Hohmann's ability to keep the work meaningful and relevant to real-world development environments. Many other texts note that most shops are at an SEI Level I maturity yet those same books delve into COCOMO II or McCabe's cyclomatic complexity--concepts and practices foreign in those same shops. It is easy to fill books with details of these and other software engineering tools and techniques but unless these things are placed in a meaningful context, they are simply tools absent of purpose.

What Hohmann offers is much more: a way to think about the real problem to be solved by engineering management: the maturation of the software development department. It is along these lines that Hohmann shines. For example, in one section discussing conflict, Hohmann asks "How much time, if any should be allocated to the schedule to allow programmers to rework their code?" Refactoring (Fowler) is a new spin on how to accomplish this but acknowledging, at a management level, that such activities go on is not widely discussed in most texts. Hohmann challenges readers to think about problems such as these.

Throughout the book are sections entitled "Advice to Managers" and "Advice to Developers". Most of the advice is rock solid and could apply anywhere for the same reason The Mythical Man Month (Brooks) is still relevant and should be required reading by all software managers: software development is (and always has been) about people! While tools and techniques evolve quickly, people have not.

Because every author wants to bring something new and fresh they'll introduce some spin on their particular approach. Hohmann offers SPO: Structure-Process-Outcome to fulfill this pension. While I think it doesn't add much, neither does it detract. There is plenty in this book to let it stand on its own merit.

I didn't agree with everything in this book. There are few books I can give blanket and unreserved approval to, in fact. But this book did do what Weinberg promised in his Forward: it made me THINK. The book's subtitle is "A Sociology of Software Development" and that description fits well. It is not a substitute for a solid book on software engineering techniques. But, I believe this book would greatly supplement anyone's library whose quest is to better understand the discipline.

4 of 4 people found the following review helpful:

4.0 out of 5 stars Plenty of goodies, but also some aridities, June 7, 1999

By 

SeanFurl (San Francisco) - See all my reviews

This review is from: Journey of the Software Professional: The Sociology of Software Development (Hardcover)

I found it crowded with good advice and ideas. I also found myself skipping and jumping around in it after a while, and putting it down altogether, because it was getting a bit tedious. But I would leave it lying in a visible place and pick it up again some evenings later. And every time I picked it up I found good and valuable advice in it. There are headings and subheadings on just about every page and the text under them is more or less self-contained: so it's amenable to browsing (chapter 1 excepted). And believe me, it has a huge amount of content. One of the things I like is its stated intention to make you a happier developer, not just a better developer. The causes of developer suffering and confusion are predominantly management and human issues, needless to say, since the machine and machine tools continue to be on their best behavior. The book has helped me avoid some suffering and confusion. It is not B.S.

4 of 5 people found the following review helpful:

3.0 out of 5 stars Interesting perspective., April 3, 2000

By A Customer

This review is from: Journey of the Software Professional: The Sociology of Software Development (Hardcover)

This book has an interesting outlook on software development. Beware it is 'the sociology of computer programming' as it says in the title - only read it if this is of interest to you. For this reason it delves into the reasons why people build software the way they do and provides the framework into which all the engineering methods and methodologies fit.

However, it's too tedious in places and contains too many hollow platitiudes despite parts being built on what appears to be a sound academically researched foundation. Pick it up if you have room for a book to round out your engineering expertise but don't expect the kind of experience as in reading 'Design Patterns' for the first time, for example.