Managing Software Engineers

1
Managing Software Engineers

• Taken from an article by Philip Greenspun
• October 2002

2
Youll 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.

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

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

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

6
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 cant 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.

7
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?

8
Ideas To Steal

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

9
People Dont 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 dont have an engineering
  background, theyll 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.

10
All Performers Get The Right Consequences Every
Day

• The natural way to manage is to spend time with
  people who arent 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?
• Theyll probably lower their productivity to
  average or even lower and not put in extra time
  when needed.
• Good performers need positive feedback too!

11
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. Its too far
  away.
• Come up with some more immediate way!

12
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)

13
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 wasnt hard to figure out whose
  fault it was.
• People worked insanely hard to make their
  projects successful and their clients happy.

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

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

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

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

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

18
Physical Comfort

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

19
Aesthetic

• Finished
• Well executed
• Look as though they were planned and decorated by
  someone with taste.
• Look nicer than most of the programmers houses.

20
Entertainment

• Big screen TV
• Video Games
• Piano

21
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

22
Turn Average Into Good

• A person wont become proficient at something
  until he or she has done it many times.
• A person wont 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.

23
Turn Good Programmers Into Good Managers

• Schedule a weekly review of subordinates 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.

24
Daily Feedback Helps, But

• Consider the average programmers 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 Others Code
• Attending Meetings
• Helping Sales and Marketing Staff

25
Authors 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 programmers 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.

26
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 Ones Own Incompetence Lead to
  Inflated Self-Assessments, Justin Kruger and
  David Dunning, 1999 Journal art.

27
References (cont.)

• Peopleware, Tom DeMarco and Timothy Lister, 1999
• Making the Cisco Connection The Story Behind The
  Real Internet Superpower, Brunnel et al 2000
• Parkinsons Law, C. Northcote Parkinson 1958
• A Pattern Language, Christopher Alexander et all
  1977

28
Managing Software Development

• http//www.murrayc.com/ subjective/managingdev.shm
  l
• The Problems
• It is not easy to find high-quality developers.
• It is not easy to integrate developers into
  unfamiliar practices, particularly when it does
  not represent a long term investment for the
  developer.
• 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.

29
Problems (cont.)

• It is not easy for a customer/requester to
  explain what he needs, and it is not easy for a
  developer to understand.
• It is not easy for many developers to work
  together on a single project.

30
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)