Managing Software Engineers

1. Managing Software Engineers Taken from an article by Philip Greenspun October 2002

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

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

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

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

10. 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!

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. It’s 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 wasn’t 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 • 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

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

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

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

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

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

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 One’s 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 • Parkinson’s Law, C. Northcote Parkinson 1958 • A Pattern Language, Christopher Alexander et all 1977

28. Managing Software Development • http://www.murrayc.com/ subjective/managingdev.shml • 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)