More Peopleware quotes

“The business we’re in is more sociological than technological, more dependent on workers’ abilities to communicate with each other than their abilities to communicate with machines.”
― Tom DeMarco, Peopleware: Productive Projects and Teams

“The purpose of a team is not goal attainment but goal alignment.”
― Tom DeMarco, Peopleware : Productive Projects and Teams

“The statistics about reading are particularly discouraging: The average software developer, for example, doesn’t own a single book on the subject of his or her work, and hasn’t ever read one.”
― Tom DeMarco, Peopleware: Productive Projects and Teams

“On the best teams, different individuals provide occasional leadership, taking charge in areas where they have particular strengths. No one is the permanent leader, because that person would then cease to be a peer and the team interaction would begin to break down.”
― Tom DeMarco, Peopleware : Productive Projects and Teams

“Whether you call it a “team” or an “ensemble” or a “harmonious work group” is not what matters; what matters is helping all parties understand that the success of the individual is tied irrevocably to the success of the whole.”
― Tom DeMarco, Peopleware: Productive Projects and Teams

“So far, the results confirm the folklore: Programmers seem to be a bit more productive after they’ve done the estimate themselves, compared to cases in which the manager did it without even consulting them. When the two did the estimating together, the results tended to fall in between.”
― Tom DeMarco, Peopleware: Productive Projects and Teams

peopleware

Open Office Plans – Excerpt from Peopleware

From PeopleWare: Productive Projects and Teams, Third Edition, by Tom DeMarco & Timothy Lister, © 2013 Addison-Wesley.


The bald fact is that many companies provide developers with a workplace that is so crowded, noisy, and interruptive as to fill their days with frustration. That alone could explain reduced efficiency as well as a tendency for good people to migrate elsewhere.

The hypothesis that qualities of the workplace may have a strong correlation to developer effectiveness is an easy one to test. All you have to do is devise a set of fixed benchmark tasks, similar to those that developers do in their normal work, and observe how well they perform each of these tasks in different environments. The Coding War Games were designed with exactly that purpose in mind.

In order to gather some data on the workplace, we had each war game participant (prior to the exercise) fill out a questionnaire about the physical quarters in which the work was to be performed. We asked for some objective data measurements of the dedicated space provided and the height of partitions, (for example) and for answers to some subjective questions like “Does your workplace make you feel appreciated?” and “Is your workplace acceptably quiet?” Then we correlated their answers to their performance in the exercise.

An easy way to spot the trend is to look at the workplace characteristics of people who did well in the exercise (based on a composite performance parameter) against those of participants who didn’t do so well. We chose to compare the top quarter of finishers with the bottom quarter. Average performance of those in the top quarter was 2.6 times better than that of those in the bottom quarter. The environmental correlations are summarized in Table 8-1.

The top quartile, those who did the exercise most rapidly and effectively, work in space that is substantially different from that of the bottom quartile. The top performers’ space is quieter, more private, better protected from interruption, and there is more of it.

Table 8-1. Environments of the Best and Worst Performers in the Coding War Games
Environmental Factor Those Who Performed in 1st Quartile Those Who Performed in 4th Quartile
1. How much dedicated work space do you have? 78 sq. ft. 46 sq. ft.
2. Is it acceptably quiet? 57% yes 29% yes
3. Is it acceptably private? 62% yes 19% yes
4. Can you silence your phone? 52% yes 10% yes
5. Can you divert your calls? 76% yes 19% yes
6. Do people often interrupt you needlessly? 38% yes 76% yes

Looking Ahead to 2017

I have been living on the academic calendar for the past three years. One or two nights a week I have been completing coursework toward a Master of Software Engineering degree at Seattle University. So even though its a new year tomorrow, it feels like the one-third point for me. I’ve written about getting my degree a little bit before. As an already-working software engineer with ten years of experience, most of my colleagues (with a few exceptions) have thought it crazy to sink tens of thousands of dollars into a graduate degree.

What can you get from the classroom that you can’t learn better on the job?

Isolate Change in Microservices

I’m finally seeing the “microservice” trend starting to fade a bit. An excellent article came through my Twitter feed the other day, Sean Kelly’s “Microservices, please don’t.” His stuff is remarkable for how he draws the connection between coding practices in a monolith and their equivalent in a microservices architecture. It seems obvious but I haven’t seen too many people pay attention to it.

A solid SOA approach begins in the code itself and moves out into the physical topology of the stack as time moves on.

One of the issues that should be addressed in SOA is how to avoid shackling services together. A simple change in one of them shouldn’t create a cascading set of changes across multiple services. Likewise code in a monolith should be architected to isolate change and prevent cascading updates across classes or packages.

Domain-Driven Design addresses this issue for the single application and some of its rules apply equally well. For example, don’t pass the same object around inside the application that you pass across externally. There’s always a layer in true DDD applications that takes any DTO from an external source (like a web service or database) and keeps it external to the application by translating it to another object in the language of the domain inside the application. There’s a huge temptation to skip this step but every time I’ve seen it done it creates huge problems at some point.

Likewise in a microservices world, the requests and responses chattering between the services should never be a reverse dependency that force all of the services to change whenever they do, whether the specific service cares about the change or not. There should be a good fencing strategy going on that allows them to change with a minimum of pain. And that’s really no different than all of the classic object-oriented design advice. Keep in mind that Uncle Bob’s definition of “single responsibility” is “one reason to change”–not some of the other common misunderstandings passed around.

Anyway, the bottom line point in this is what software luminaries have always known and said: there’s no architecture, no ceremony or formula that you can follow which will not crumble when divorced from the context of good underlying engineering principles .