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.

Tuesday, December 10, 2019

Good Management Is More Important Than Good Technology

Good management motivates people to do their best. Poor management demotivates people. All the great technology in the world will not compensate for poor management. And good management can actually produce great results even with meager resources. Successful software startups do not become successful because they have great process or great tools (or great products for that matter!). Most have been successful because of great management and great marketing.

As a manager, you have a responsibility to do your best. There are no universally "right" styles of management. Management style must be adapted to the situation. It is not uncommon for a successful leader to be an autocrat in one situation and a consensus-based leader in another, just a few minutes later. Some styles are innate. Others can be learned. If necessary, read books and take short courses on management style.


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

Monday, December 09, 2019

Don't Take Errors Personally

Writing software requires a level of detail and perfection that no human can reach. We should dedicate ourselves to constant improvement, not perfection. When an error is detected in your code either by you or by others, discuss it openly. Instead of castigating yourself, use it as a learning experience for yourself and others.


Reference:
Gerhart, S., and Yelowitz, L., "Observations of Fallibility in Applications of Modern Programming Methodologies," IEEE Transactions on Software Engineering, Sept 1976.

Saturday, December 07, 2019

Analyze Causes For Errors

Saturday Night Live "fix it" skit.

Errors are common in software. We spend enormous amounts of resources detecting and fixing them. It is far more cost-effective to reduce their impact by preventing them from occurring in the first place. One way to do this is to analyze the causes for errors and they are detected. The causes are broadcast to all deverlers with the idea being that we are less apt to make an error of the same type as one whose cause was thoroughly analyzed and learned from.

When an error is detected there are two things to do: 1) Analyze its cause and 2) fix it. Record everything you can about the cause of the error. This is not just technical issues like, "I should have checked the passed parameter for validity before using it" or "I should have found out if I needed to execute the loop n or n-1 times before I gave it to integration testing." It is also management issues like, "I should have desk-checked before unit testing" or "If I had let Ellen check the design to see if it satisfied all the requirements when she wanted to, ..." After collecting all this information, broadcast it, letting everybody know what caused the errors, so that such knowledge can become more widespread and such errors can become less widespread.


Reference:
Kajihara, J., Amamiya, G., Saya, T., "Learning from Bugs," IEEE Software, Sept 1993.