Managing Software Engineers

Taken from an article by Philip Greenspun

October 2002

You’ll all be managers in 5 years!

I predict, if you go into software development, that you will be managing from 3-8 programmers and/or software engineers within 5 years.

Plan now to gain the skills necessary to support this task.

Take some other elective management courses.

Take anything the company offers as “in house” manager training.

Software Engineering is Different

Only the best people contribute to achievement.

Traditional management techniques assume a distribution of talent among the workers.

Each worker is contributing something useful and the challenge is to get each one to perform at his or her maximum potential.

In the same factory, the best worker may produce two or three times as much as the average, but all are contributing.

In Software Engineering

A good programmer is at least 10 times more productive than an average programmer.

An average programmer will consume nearly their entire work day just in reading and understanding the new code generated by the good programmers.

The challenge of a S. E. Manager are: Create a working environment where good

programmers will be satisfied enough to stay. Create a system via which average

programmers can become good.

Software Engineering is Different

People at all levels perceive themselves to be equally intelligent.

People with bad ideas and low productivity often think of themselves as supremely capable. They are the last people whom one can

expect to fall in line with a good strategy developed by someone else.

Each programmer thinks his or her idea about what to build and how to build it is the best.

Software Engineering is Different

A leaf-node worker is more expert than any manager, even when the manager is a great engineer, in at least the small portion of the system that he/she has personally built.

The organization can’t afford to lose the individual productivity of the best people by pushing them into management.

Measurement is notoriously difficult. The world is full of products that failed due to

overly complex and tasteless designs.

Software Engineering is Different

It is a bit easier to count up the lines of code per day produced by a programmer but if the project was not very tightly specified originally, how do you know whether or not these lines of code are useful?

Ideas To Steal

People don’t do what they are told. All performers get the right consequences

every day. Small, immediate, certain consequences are

better than large future uncertain ones. Positive reinforcement is more effective than

negative reinforcement. Ownership leads to high productivity.

People Don’t Do What They Are Told

If we did, we would all eat nutritious foods, never drink too much alcohol, and exercise regularly.

A corollary is that people do what you reward them to do, not what you hope they will do. If the managers don’t have an engineering

background, they’ll probably be unable to perceive when a programmer is accomplishing nothing. (the “four programmers story”)

So, the programmer who does nothing is rewarded with a paycheck and continues to do nothing.

All Performers Get The Right Consequences Every Day The natural way to manage is to spend time

with people who aren’t doing a good job. This is probably the right consequences for someone who is underperforming.

What about the people who ARE performing? What if you ignore them day-to-day?

They’ll probably lower their productivity to average or even lower and not put in extra time when needed.

Good performers need positive feedback too!

Small, Immediate, Certain Consequences are Better Than Large, Future Uncertain Ones

An annual review and bonus is not considered a very good way to motivate people. It’s too far away.

Come up with some more immediate way!

Positive Reinforcement Is More Effective Than Negative Reinforcement

Schools often practice negative reinforcement at the undergraduate level. If the student does not do a problem set by a certain deadline, we give him or her a bad grade. (negative reinforcement)

At the graduate level: If a student finishes some research, the most

effective faculty advisors immediately pay attention, help design the next experiment, and help draft a paper outline. (positive reinforcement)

Ownership Leads To High Productivity

Include contingent rewards. The author did:

Gave one programmer total responsibility for one project.

The programmer owned that customer. If the project went well, the payment was given

nearly all the money. If the project went badly and they got fired by

the customer, it wasn’t hard to figure out whose fault it was.

People worked insanely hard to make their projects successful and their clients happy.

Building And Keeping A Good Software Engineering Team

Hire a few to begin with. Seek the most challenging problems. Build something important. Have other programmers admire their work. Build a good working environment.

Programmers DREAD elaborate process, endless meetings, and layers of marketing approval.

Reduce the design team to as near two people as possible.

Reduce Team Size

A product is going to get out the door faster if it is built by 4 people working 70 hour weeks than 12 people working 40 hour weeks. Four people: 180 productive programmer-

hours per week 12 people: same 180, but much more

coordination and additional managers.

For This Level Of Work, Programmers Must Live At The Office

What makes a nice office? Social Physical Comfort Aesthetic Entertainment Attractive

Social

Informal gathering places. Sofas Coffee Tables

Programmers can “eat”, “talk”, and occasionally listen to presentations.

Shared writing surface, e.g. Whiteboard Very easy for programmers to invite friends

over. Open office plan.

Physical Comfort

Programmer’s choice: Chairs Keyboards Dual Monitors

Air Conditioning 24/7 summer Heated and Humidified 24/7 winter Clean Air 30 square feet work surface 100 square feet dedicated space

Aesthetic

Finished Well executed Look as though they were planned and

decorated by someone with taste. Look nicer than most of the programmer’s

houses.

Entertainment

Big screen TV Video Games Piano …

Attractive

Have one thing that is extremely attractive about the physical environment for any particular prospective software engineer. E.G. Dog-friendly policy Grand piano Climbing wall Indoor garden Aquarium Koi pond Exercise room with fancy machines Pinball machine

Turn Average Into Good

A person won’t become proficient at something until he or she has done it many times.

A person won’t retain profiiciency at a task unless he or she has at one time learned to perform that task very rapidly.

Technology shifts force a programmer to go through bursts of learning every year or two.

Turn Good Programmers Into Good Managers Schedule a weekly review of subordinate’s

work. Decouple responsibility for review from

responsibility for scheduling review. Expect them to still write cde, develop SQL

data models, write system design documents and write journal articles.

Daily Feedback Helps, But

Consider the average programmer’s task list: Surfing USENET Surfing Slashdot Reading Docs Questioning Colleagues Writing Specs and Designs Writing Docs Writing Code Testing Code Fixing Bugs Filing Bug Reports on Other’s Code Attending Meetings Helping Sales and Marketing Staff

Author’s Summary

“Building and managing a peak-performing software engineering organization is challenging but extremely profitable. The core Ariba product was written by two programmers, yielding a market capitalization of $30 billion.

Start by attracting a good core team. Provide a productive working environment and a

physical environment that is better than the average programmer’s house.

Provide daily positive reinforcement. Provide daily feedback showing the programmer

more or less exactly what he or she has accomplished, plus a graph for the preceding few months showing the trend.

Aim to install a feeling of ownership in each worker.

References

Bringing Out The Best In People, Aubery Daniels 1999, McGraw Hill

The Mythical Man-Month, Fred Brooks, 1995 (still an excellent book!)

Managing the Professional Service Firm, David Maister, 1993.

Unskilled and Unaware Of It: How Difficulties in Recognizing One’s Own Incompetence Lead to Inflated Self-Assessments, Justin Kruger and David Dunning, 1999 Journal art.

References (cont.)

Peopleware, Tom DeMarco and Timothy Lister, 1999

Making the Cisco Connection: The Story Behind The Real Internet Superpower, Brunnel et al 2000

Parkinson’s Law, C. Northcote Parkinson 1958

A Pattern Language, Christopher Alexander et all 1977

Managing Software Development

http://www.murrayc.com/ subjective/managingdev.shml

The Problems:1. It is not easy to find high-quality developers.2. It is not easy to integrate developers into

unfamiliar practices, particularly when it does not represent a long term investment for the developer.

3. It is not easy to measure other developers’ progress on a project. And only experienced developers can give accurate estimates of time required on their own projects.

Problems (cont.)

4. It is not easy for a customer/requester to explain what he needs, and it is not easy for a developer to understand.

5. It is not easy for many developers to work together on a single project.

Solutions

Use Mentoring (helps with 1 and 3) Use Mainstream Tools, and Techniques (Helps with

1, 2, 3, and 5) Create Reusable Components (Helps with 3) Use Feature Lists (Helps with 3 and 4) Develop Incrementally (Helps with 3 and 4) Recognize that Customers/Requesters are the best

testers (Helps with 3 and 4) Constantly Share Code (Helps with 5) Documentation (Helps with 4 and 5)