Tuesday, January 14, 2020

Trust Your People

Trail bridge in Wilson's Creek National Battlefield. Photo by Jerry Yoakum.

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.

Monday, January 13, 2020

Listen To Your People

National Park service road through the woods. Photo by Jerry Yoakum.

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.

Friday, January 10, 2020

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.

Thursday, January 09, 2020

Grain Brain

Grain Brain: The Surprising Truth about Wheat, Carbs,  and Sugar--Your Brain's Silent KillersGrain Brain: The Surprising Truth about Wheat, Carbs, and Sugar--Your Brain's Silent Killers by David Perlmutter
My rating: 3 of 5 stars

A lot of reviewers complain that this title is very repetitive. It is but for the audiobook that is alright. It is very easy for much of what the author wrote to slip right by especially if I'm doing other stuff while listening. I'm not convinced that this diet is for everyone, but I am convinced that for the people who need this diet that it is life changing. I'll change my food choices some based on this book and definitely watch for future news on this topic.

View all my reviews

Thursday, January 02, 2020

Mycroft and Sherlock

Mycroft and SherlockMycroft and Sherlock by Kareem Abdul-Jabbar
My rating: 5 of 5 stars

Great job of portraying a young Sherlock and explaining why Mycroft didn't go on to more adventures like he had in the first Mycroft book.

View all my reviews

Tuesday, December 24, 2019

Alchemy

Alchemy: The Surprising Power of Ideas That Don't Make SenseAlchemy: The Surprising Power of Ideas That Don't Make Sense by Rory Sutherland
My rating: 5 of 5 stars

With exception of the obvious bias the author has in favor of vaping, this was a very enjoyable book. It is a pleasure to look at problems from different perspectives and this book is largely about reframing questions to find different solutions.

View all my reviews

Monday, December 23, 2019

A Few Good People Are Better Than Many Less Skilled People

This follows immediately from the idea that People Are The Key To Success, which says that you should always hire the best engineers. This principle says that you are better off allocating just a few good, experienced engineers on a critical task than to put many inexperienced engineers on it. This is Don Reifer's "Management Principle #6." On the other hand, Manny Lehman warns that you can't rely too much on "a few good people"; what if they quit? The best advice is to have the right mix of people on a project and take care not to gravitate towards either extreme. Those people with the most experience are probably closest to retirement. Keep them working with people with less experience so their knowledge isn't lost in the future.


Reference:
Reifer, D., "The Nature of Software Management: A Primer," Tutorial: Software Management, Washington, DC: IEEE Computer Society Press, 1986.

Wednesday, December 18, 2019

People Are The Key To Success

On the left, a person is studying under a heading of "Successful People: They Continuously Learn New Things." On the right, a person is sleeping under the heading of "Unsuccessful People: They Think They Know It All."

Highly skilled people with appropriate experience, talent, and training are key to producing software that satisfies user needs on time and within the budget. The right people with insufficient tools, languages, and process will succeed. The wrong people (those with insufficient training, experience, or work ethic) with appropriate tools, languages, and process will probably fail. According to the Constructive Cost Model (COCOMO), the best people are 4 times more productive than others. If the best people cost 4 times the salary, you break even and probably end up with a better product (Great Designs Come From Great Designers). If they cost less, you reduce costs and have a better product. That's a win-win.

When interviewing prospective employees, remember that there is no substitute for quality. Companies often say, after interviewing two people, "Person x is better than person y, but person y is good enough and less expensive." You can't have an organization of all superstars, but, unless you have an overabundance of them now, hire them!


References:
Boehm, B., Software Engineering Economics, Englewood Cliffs, NJ: Prentice Hall, 1984.
Weinberg, G., The Psychology of Computer Programming, New York: Van Nostrand Reinhold, 1971.

Tuesday, December 17, 2019

Understand The Customers' Priorities


Surround yourself with people that understand priorities and are able to execute. #Duty

It is quite possible that the customers would rather have 90 percent of the system's functionality late if they could just have 10 percent of it on time. The corollary of the principle of communicate with customers/users is quite a bit more shocking, but it could very well be the case. Find out!

If you are communicating with your customers, you should be sure you know their priorities. These can easily be recorded in the requirements specification, but the real challenge is to understand the possibly ever shifting priorities. In addition, you must understand the customers' interpretation of "essential," "desirable," and "optional" and prioritize the requirements accordingly. Will they really be happy with a system that satisfies none of the desirable and optional requirements?


Reference:
Gilb, T., "Deadline Pressure: How to Cope with Short Deadlines, Low Budgets, and Insufficient Staffing Levels," Information Processing, Amsterdam: Elsevier Publishers, 1986.

Monday, December 16, 2019

Don't Believe Everything You Read

Two stick figures are talking. One says, "Did you fact check this before reposting it?" The other replies, "I don't need to. It agrees with my preconceived views and biases, so it must be true!"

As a general rule, people who believe in a particular philosophy search for data that supports that philosophy and discard data that does not. Someone who wants to convince others of a position obviously uses supportive, not unsupportive, data. When you read, "Use method X. You too can achieve up to 93 percent increases in productivity (or quality)," the method may really have achieved such results. But it was probably the exceptional case. In all likelihood, most projects experience far less dramatic results. And some projects may even experience decreased productivity using method X.


Reference:
Fenton, N., "How Effective Are Software Engineering Methods?" Journal of Systems and Software, August 1993.