You Can Optimize Whatever You Want

Any project can optimize whatever factor of "quality" it wants to. In optimizing any one factor, other "quality" factors are generally denigrated. In a landmark experiment conducted by Gerald Weinberg and Edward Schulman, five teams of software developers where given identical requirements, but each was told to optimize something different: development time, program size, data space used, program clarity, and user friendliness. In all cases except one the programs produced by the teams where rated best in terms of the attribute they were told to optimize.

If you tell your people that everything (such as schedule, size, maintainability, performance, and user friendliness) is equally important, none will be optimized. If you tell them that only one or two are important and the rest unimportant, only the important ones will be addressed. If you give them an a priori relative ranking, the ranking may not be appropriate in all situations on the project. The fact is that there are trade-offs -- different trade-offs -- to be made constantly during product development. Work with your employees and help them understand your priorities and your customers' priorities.


Reference:
Weinberg, G., and Schulman, E., "Goals and Performance in Computer Programming," Human Factors, 1974.

Winter Reading Challenge

My local library is running a winter reading challenge. The challenge is to read five books that meet the following criteria between January 2 to February 29, 2020.

1. Listen to a Book



2. Teaches You Something New



3. Graphic Novel or Comic Book





4. First in a Series



5. In Another Time or Place



6. Book Club Recommendations (need to finish)



7. Author New To You



8. Outside Your Comfort Zone
• 
  
9. Under 200 Pages (currently reading)



10. Made Into a Movie (want to read)



11. Always Meant to Read
• 
  
12. Retelling of a Story





13. Set in an Imaginary World



14. Author of Color





15. Winter Setting
• 
  

The Ghost Map

The Ghost Map: The Story of London's Most Terrifying Epidemic--and How It Changed Science, Cities, and the Modern World by Steven Johnson
My rating: 5 of 5 stars

The story was great. You might be thinking, "I don't know about reading this. I've heard tons of 10 and 30 minute versions of this story. Is an 8 hour version worth it?" It is.

The last 20% of the book is the conclusion and it gets a bit off-topic. I don't think you'll really miss out on anything if you choose to skip it. There are good points made and discussed but if you're just here for the Ghost Map story then don't worry about it.

View all my reviews

Huge Differences Among Software Engineers

Productivity (measured by lines of code per person-month) can vary by as much as a factor of 25 from the most to the least prolific coder. Quality (measured by bugs found per thousand lines of code) can vary by as much as a factor of 10 from the best to the worst software engineers.

I'm sure you can see my bias in the words above that I think quality is more important than productivity. Unfortunately, I don't have data to see the intersection of those two measures. I suspect that there is a correlation between productivity and quality. But with a diminishing return where the act of writing more code prevents a person from thinking about the stakeholder's true intention or the ramifications of the new code.

As a manager, you have to encourage an optimal mix of productivity and quality. This isn't done just by focusing on a single software engineer. This is a whole team project. For example:

• If quality is down then consider requiring stricter code reviews.
• If productivity is down then consider lighter code reviews.
• If both are down, is your team overworked?
• If both are down, is your team in need of training?
• And, yes, sometimes you do have to single one person out and say, "Slow down. You are making too many mistakes." Or, "Speed up. You are spending too much time testing your code."
• I've heard both of those admonitions. They helped make me a better developer. They helped me find balance between getting stuff done and perfectionism.
• etc...

There is no right way to optimize a development team's productivity and quality. But there is a wrong way - deciding everything for yourself. No one has all the answers and even if they did it would upset the team members to have no input.

Talk to your team! Show them the data that has you concerned and ask for input. Share details about the budget to explain why sending a few people to the QCon conference in Tokyo isn't feasible but the whole team could go to KCDC. Find ways to combine team building with training.

Reference:
Sackman, H., et al., "Exploratory Experimental Studies Comparing Online and Offline Programming Performance," Communications of the ACM, January 1968.