Managing Software Engineers
description
Transcript of Managing Software Engineers
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)