Journey of the Software Professional: The Sociology of Computer Programming

About

Features

• 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.

Description

23661-2

A breakthrough model for understanding software development— and breakthrough techniques for improving it!

You can't improve the way you develop software if you don't understand it. Journey of the Software Professional offers the first complete model of software development—based on the newest research in cognitive psychology and organizational behavior. But that's just the beginning. At its heart, this is a book of practical advice for developers and managers who are serious about enhancing their own effectiveness, and the effectiveness of their teams.

This book transcends the boring, self-evident advice you've heard a thousand times before, with fresh insights into:

• Choosing the best work environment for your personality and workstyle
• Building on your personal and management strengths, and avoiding common errors
• Finding better ways to approach individual and team problem-solving
• Creating a better team culture
• Improving communication effectiveness
• Managing both technological and organizational change

Crammed with advice for both developers and managers, Journey of the Software Professional covers an extraordinary range of topics—and presents them through a coherent Structure-Process-Outcome framework that helps you make sense of your own experience.

You'll discover tools and techniques for building and implementing your own career development plan. You'll learn the concepts underlying well-designed system architectures and how to apply these concepts to create an architecture appropriate for your project. At the same time, you'll learn how to create organizational structures that support this architecture and manage the growth of the team over the life of the project. You'll learn how to develop long-term strategies for improving your organization's software development. And a whole lot more.

No matter what role you play in software development, or where you are in your career, this book represents a breakthrough in understanding what you're doing — and how to do it better!

“In many ways, it opened my eyes. If you are a software professional, I think it will open yours as well.” —Gerald M. Weinberg

Sample Content

Table of Contents

PART I.

Problem Solving: Descriptions and Prescriptions. Cognitive Models. Benefits of Cognitive Models. Method. Benefits of Methods. Comparing Methods and Cognitive Models. Structures, Processes, and Outcomes: An Overview. Process. Linking Methods to Cognitive Models. Process Leveling and Experience. The Descriptive Benefits of Process Leveling. Process Leveling, Stepwise Refinement, and Opportunistic Design. Outcome. Preparing Outcomes for Understanding. Lessons From Architecture. Structure. The Structure-Process-Outcome Framework. The SPO Franewire in Action. The Critical Role of Feedback. Review.

Values. Personality. Goals. The Integrated Framework. Conflict and Tension Among Components of the Framework. Review.

PART II.

Create Structures and Processes to Achieve Outcomes. Practice Future Perfect Thinking. Review Early and Often. Kinds of Reviews. Formal Review Structures. Grow Your Experience. Use Multiple Models. Generate Alternatives. Differentiate.

Clarify Values. Understand Your Personality. The Kirton Adaption- Innovation Inventory. The Myers-Briggs Type Indicator. Relationship Between The KAI and MBTI. The Intersection of Personality and Values. Goals. Setting Goals. Organizing Goals. Know What You Are Good At.

Use Tools Wisely. What Is A Tool? Impact of Tools in the SPO Framework. Limitations and Dangers of Tools. Tools for Software Development. Use A Project Notebook. What Is A Project Notebook? What Should It Contain? How to Use A Project Notebook. Managing Time. Structures, Processes and Outcomes for Time Management. Working With Support Staff.

What Is Training? Training In the SPO Framework. Self-Learning. A Competency Framework For Self-Learning. Breadth Vs. Depth In The Competency Framework. Learning Style and Delivery Mechanisms.

PART III.

A Brief Word On Size. Methods And Teams. Beyond Methods: Group Activities. Organizational Theories. What Is An “Organization?” Organizational Interdependence. Rationality. Topologies. Summary. Group Processes. Identification and Distribution. Coordination and Integration. Process Leveling In Teams. Collective Mind and GroupThink. The Impact of Individual Ability. Other Aspects Of Process. Summary. Outcomes. The Creation Of Shared Outcomes. The Meaning Of Shared Outcomes. Reducing Ambiguity and Equivocality In Shared Outcomes. Managing Shared Outcomes. Structure. Essential Structures: System Architecture & Topology. The SPO Framework In Teams. Methods, Teams, and Topologies. Multiple Integrated Frameworks. Timing. Feedback Loops and Crosstalk. Review.

Values. Culture. Goals. Strategy. Corporate Knowledge. The Integrated Framework. Linking Individuals and Teams. Power and Politics. Summary.

PART IV.

Reasonable Persons. Pulling, Not Pushing. Developing Trust. Impact Of Trust. The Johari Window. Interaction Styles. Increasing The Arena Of Trust.

The Creation Of Shared Outcomes. Modeling Communication As Messages. What Is Meaningful Communication? Communication Structures. Communication Processes. Communication Outcomes. Changes Over Time. Know Your Notation. Standards and Guidelines. Status Reports. Effective Meetings. A Model For Effective Meetings. Project Repositories.

Values. Culture. Norms. Rituals. Stories and Symbols. Shared Language. How to Influence Culture. Goals.

Coupling and Cohesion. Software Coupling Revisited. Three Types Of Organizational Coupling. Benefits Of Loose Coupling. Drawbacks Of Loose Coupling. Achieving Loose Coupling. Cohesive Components and Teams. Determining Cohesion. Structural, Procedural, and Outcome Cohesion. Being Cohesive. Complexity and Variety. System Architecture and Organizational Topology. System Architecture. Traditional Topologies. Organization Paradigms: Working Within the Topology. Addressing Size and Growth. Putting It All Together. Roles. Implicit Vs. Explicit Roles. Roles in Support of System Architecture. Roles Associated with Teamwork. Problems Associated With Roles. Structure As Process. The Impact of Structure. More or Less Structure. How Much Structure? The Dangers of Too Much Structure.

General Observations on Change. Innovations. Innovation Structures. The Innovation Evaluation Process. Tools, Techniques, and Interrelated Outcomes. The S-Shaped Curve of Adoption. Making Innovations Happen. Reorganizations. Team Lifecycles. Entrances and Exits. New Organizational Topologies.

Training Benefits. When Is Training Needed? Breadth Vs. Depth In Teams. What to Train. Approaches To Training.

PART V.

Job Mobility. Be A Good Follower. Helping colleagues. Avoid Office Politics. Office Etiquette. Take Care of Yourself. Eat In Moderation. Exercise Regularly. Work As Comfortably As Possible. Take Vacations. Get A Reasonable Amount of Sleep. Know When To Say No. Take Care Of Your Relationships.

Demonstrate Your Skills. Evaluate the Product Release Strategy. Have A Defined Role. Examine the Turnover Rate. Examine the Opportunity for Advancement. Are the Big Three Practiced? Review Outstanding Bug Reports. Interview Your Direct Manager. Talk With Other Developers.

Is It Really That Bad? Work To Improve. Maintain Your Network. Control What You Can Control. Improve Your Skills. Use A Bomb File. Burn Bridges Carefully.

Preface

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.com

Updates

Submit Errata