Managing Software Engineers - PowerPoint PPT Presentation

1 / 30
About This Presentation
Title:

Managing Software Engineers

Description:

An annual review and bonus is not considered a very good way to motivate people. ... Big screen TV. Video Games. Piano. Attractive ... – PowerPoint PPT presentation

Number of Views:53
Avg rating:3.0/5.0
Slides: 31
Provided by: csMon
Category:
Tags: big | engineers | games | good | in | managing | not | software

less

Transcript and Presenter's Notes

Title: 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)
Write a Comment
User Comments (0)
About PowerShow.com