Brooks' Law

Measuring a project solely by person-months makes little sense. If a project could be completed in one year by six people, does that mean that 72 people could complete it in one month? Of course not!

Suppose you have 10 people working on a project that is due for completion in three months. You now believe your are three months behind schedule; that is, you estimate you need 60 more person-months (6 months x 10 people). You cannot add 10 more people and expect the project to be back on schedule. In fact, adding 10 more people would likely delay the project further due to additional training and communications overhead.

Approximately a decade ago, I worked on a big project alone. I approached it as proof-of-concept and focused on getting everything to work. Since ensuring that everything worked was my goal I didn't devote a lot of time to good object-oriented programming practices... I'm not going to apologize for that. I still think I did the right thing to ensure that the project worked. Half of the work I was doing was testing another team's API and helping them get it right. However, the project managers really screwed me over by announcing the project finished when reality I had only finished testing the API provided by the other team. My boss put 20 people on the project to finish it in the next month. This could have been a disaster but she did an amazing job coordinating everyone's efforts. While all those people were helpful with writing documentation and performing testing while the code was being rewritten. It really came down to one person, Charles Forsythe, who took the largely procedural code that I had written and turned it into high quality OO code.

This project would have gone more smoothly had we intentionally planned to throw away my prototype. Also, it is generally a bad idea to try to retrofit quality. It is either a testament that my prototype was of high quality code just not of the required OO paradigm and/or that Charles' coding ability overcame the difficulty of performing a retrofit.

The point of that story is that from the outside it looks like 20 people were thrown at the project to finish in a month. In reality, 1 person finished the project in a month and 19 people cleared the way and focused on tasks that multiplied that 1 person's impact. By doing it this way, my manager avoided the additional training and communications overhead. If they all would have tried to develop code for the project then it would have failed due to Brooks' Law. This isn't a guaranteed way around Brooks' Law but it is a good way to reframe development problems.


Reference:
Brooks, F., The Mythical Man-Month, Reading, MA: Addison-Wesley, 1975.

Keep The Office Quiet

The most productive employees and companies have quiet and private offices. They have phones that can be silenced or diverted. They are insulated from regular, nonbusiness interruptions. Contrast this with the general industry movement toward open, landscaped offices, which reduce physical plant cost but dramatically decrease productivity and quality. Of course, the usual management line is that such an arrangement "facilitates communication." Not true. It "facilitates interruption and noise."


Reference:
Tank, A., Why It's Time to Ditch Open Office Plans, 07-Feb-2019. [Online]. Available: https://www.entrepreneur.com/article/327142. [Accessed: 22-Jan-2020]

McGregor, J., Open office plans are as bad as you thought, 18-Jul-2018. [Online]. Available: https://www.washingtonpost.com/business/2018/07/18/open-office-plans-are-bad-you-thought/. [Accessed: 22-Jan-2020]

James, G., Open-Plan Offices Kill Productivity, According to Science, 18-May-2017. [Online]. Available: https://www.inc.com/geoffrey-james/science-just-proved-that-open-plan-offices-destroy-productivity.html. [Accessed: 22-Jan-2020]

DeMarco, T., and Lister, T., Peopleware, New York: Dorset House, 1987.

The Like Switch

The Like Switch: An Ex-FBI Agent's Guide to Influencing, Attracting, and Winning People Over by Jack Schafer
My rating: 4 of 5 stars

Very actionable advice... but a strong undertone of endorsing the idea of lying to people. Please only use Schafer's advice to make real friends and to bring joy to coworkers. Befriending people purely for selfish gains is wrong.

Use his advice to get past those first difficult times of getting to know someone. Make a good first impression then be yourself.

View all my reviews

Carry The Water

When your people are working long hours to get a software engineering job done, you should work the same hours. This sets the right example. Your employees will be more willing to work hard and do a good job if they know you are in the predicament with them. I had a software development manager, Karen Bolda, that did precisely this. It made all the difference in our attitude. During crises, Karen took on the role of "working for her employees." It worked.

If you can't help with the engineering work itself, let them know you are available to coordinate effort, run errands, order food, whatever they need. In short, carry the water.

Communication Skills Are Essential

When recruiting personnel for your project, don't underestimate the importance of teamwork and communication. The best software architect becomes a poor asset if he or she is unable to communicate, convince, listen, and compromise.

Communication breakdowns can occur at any process level. The effects of these problems are not independent. For instance, fluctuating requirements increase a development team's need for communication both with customers and with the project's other teams.

Exceptional architects are skilled at communicating their technical vision to other project members. They usually possess exceptional communication skills and often spend much of their time educating others about the application domain and its mapping into computational structures. In fact, much of their design work is accomplished while interacting with others. The integrative role of an exceptional designer compounds itself. This happens because those perceived as most knowledgeable will become communication focal points, providing them more knowledge about the system to integrate into a more comprehensive model.


Reference:
Curtis, B., Krasner, H., and Iscoe, N., "A Field Study of the Software Design Process for Large Systems," Communications of the ACM, November 1988.

Expect Excellence

Your employees will do much better if you have high expectations of them. Studies by Warren Bennis prove conclusively that, the more you expect, the more results will be achieved (obviously with some limit). In many experiments, heterogeneous groups were divided into two subgroups with identical goals. One subgroup was treated as if excellence was expected. The other subgroup was treated as if mediocrity was expected. In every experiment, the group for whom excellence was expected outperformed the other group.

You can show in many ways that you expect excellence: Be an example (work hard, be proud of your efforts well done, don't play computer games on the job). Provide educational benefits to your employees to help them achieve their best. Reward excellent behavior.* Coach, tutor, cajole, and attempt to inspire your poorer performers toward better work products and habits. If you (or they) fail, find more suitable opportunities for them within your organization or your company. If all else fails, help them find a job outside. You cannot allow them to stay in an inappropriate job, but you must also show compassion. If you leave them where they are, your product will be of lower quality and your other employees will assume that poor performance is acceptable.


Reference:
Bennis, W., The Unconscious Conspiracy: Why Leaders Can't Lead, New York: AMA-COM, 1976.

Tehanu

Tehanu by Ursula K. Le Guin
My rating: 5 of 5 stars

This is an excellent "see the world through someone else's eyes" book. There will be parts that might be distasteful but that's how parts of people's lives are. Another person's opinions might not be correct but they exist nevertheless. I found the afterward really interesting. The way the author talked about writing the book made it sound like a process of discovery instead of creation.

View all my reviews

Trust Your People

In general, if you trust people, they will be trustworthy. If you treat people as if you don't trust them, they will give you reason not to trust them. When you trust others and give them no reason not to trust you, they will trust you. Mutual trust is essential for successful management.

When one of your employees says, "Can I take off today at 2:00 PM? I'll work a few hours extra later in the week," you should say, "Yes." You lose nothing, and you gain the loyalty and respect of your employee. There are many more opportunities to be the bad guy than the good guy. Take every chance you can get to be the good guy. Who knows, maybe in a few weeks you'll need to ask the employee to work a few extra hours for a job you need to have done.


Reference:
McGregor, D., The Human Side of Enterprise, New York: McGraw-Hill, 1960.

Listen To Your People

The people who work for you must be trusted. If they're not trustworthy (or if you don't trust them), your project will fail. If they don't trust you, your project will also fail. Your people can tell as quickly that you don't trust them as you can when your boss doesn't trust you.

The first rule of trust is listening. There are many opportunities to listen to your people: when they visit your office to tell you about a problem they are having, when you need an estimate from them for a software development, when you are managing by walking around (MBWA), among others. Whenever your people are talking to you, listen and hear. They consider what they are saying to be important or they wouldn't be telling you. There are many ways to let them know you are listening: eye contact, appropriate body language, "playing back" what you think you heard them say, asking appropriate questions to solicit more information, and so on.


Reference:
Francis, P., Principles of R&D Management, New York: AMACOM, 1997.

2020 Reading List

I was continuously updating and referencing this list to guide my reading. Therefore, I decided it was more useful to make it a page instead of a post with a link on my blog's landing page.

https://jerryyoakum.blogspot.com/p/2020-reading-list.html