Don't Nest Too Deep

Nesting IF-THEN-ELSE statements greatly simplifies programming logic. On the other hand, nesting them more than, say, three levels deep decreases their understandability considerably. The human mind is capable of remembering only a certain amount of logic before it becomes confused. A variety of simple techniques can be used to reduce nesting.


Reference:
McConnell, S., Code Complete, Redmond, WA: Microsoft Press, 1993.

Structured Code Is Not Necessarily Good Code

The original definition of structured programming presented by Edsger Dijkstra was provided to facilitate program proving. The constructs he recommended (IF-THEN-ELSE, DO-WHILE, etc) have now become so commonplace (though program proving has not) that their use is now called "programming" rather than "structured programming." It is important to note; however, that not all "structured" programs are good. One can write incredibly obscure programs that are still structured. Structure is almost a necessary, but far from a sufficient, condition for quality programming.


Reference:
Yourdon, E., How to Manage Structured Programming, New York: Yourdon, Inc., 1976.

You Can Use Unstructured Languages

Unstructured code violates Edsger Dijkstra's guidance to restrict control structures to IF-THEN-ELSE, DO-WHILE, DO-UNTIL, and CASE. Notice that it is possible to write structured code in languages without these structures, such as in assembly languages, by documenting the use of GOTOs to implementing these structures only.

To do this, first write your algorithms using the aforementioned control structures. Next, convert these into in-line comments. Next, translate the comments into their equivalent programming language statements. GOTOs will appear, but they will be implementing the better constructs and will facilitate, not hamper, readability, maintainability, and provability.


Reference:
McConnell, S., Code Complete, Redmond, WA: Microsoft Press, 1993.

Dumbheart

Dumbheart: A Get Fuzzy Collection by Darby Conley
My rating: 5 of 5 stars

Despite be 10 years old, I find all the republican/democrat jokes to be spot on. I'm not sure they were balanced by it was nice to see both sides lampooned.

View all my reviews

Google AutoML And Thinking Machines

After attending a machine learning presentation I got the chance to talk to the presenter about AutoML. He said that it is out-performing a lot of data scientists at Google. Which really peaked my interest. I asked him if the software was similar to the software Daniel Hillis wrote back in the '90s to generate code that was out-performing human coders (see The Pattern on the Stone). Sadly, he had no idea who Daniel Hillis is. I think the idea of software generated code never caught on because no one could understand why it was faster but everyone could agree that it wasn't safe because it was so difficult to decide if it would always work correctly. Which brings to mind the question - is AutoML safe? Will it create bias because the data is formatted a certain way?

I look forward to learning more about how AutoML works. I'm also interested in learning how to use AutoML but am vastly more interested in its internals.

Monitoring Matters

My mornings start with me reading my Google news feed. This morning included a story about Wow Air closing. Approximately four hours later I ran the following Google query:

Imagine my surprise to see a large travel company still running ads for Wow Air. At this point operations had been ceased for around ten hours. Ads for such a competitive market would probably cost one to six dollars per click. And with Wow Air being in the news curious people probably clicked that ad to see what was being sold in addition to people who wanted to travel to Iceland. I clicked it. It was a branded page but when I dug into the options Wow Air was already removed from the list of carriers. This highlights the different speeds with with different departments react to changes. And moreso, it highlights the lack of communication in businesses. Someone, probably many someones, knew that Wow Air was no more so they removed it as a flight carrier option. They did not, it would seem, reach out to Marketing and say, "Hey, you'll want to disable your ads." This is the downside of work silos. It would never have crossed their minds that such a thing could be helpful. Besides it is not their job...

For small businesses and account managers, it often isn't a problem to respond to an issue within 24 hours. Something I use and have shared with some account managers is Google Alerts. This works well but can take a day to get an alert. Basically, you get notified if some keywords you specify are referenced when a new webpage gets indexed. This might not help you if an existing webpage is updated. It depends on whether your keywords didn't use to match but do after the webpage is re-indexed.

For things that need immediate handling when there is a change then that usually requires being proactive. For example, there are lots of services that will notify you within a few minutes that a webpage has changed. In this case, if you are the person handling Ads for Wow Air then you would probably want to know anytime the main landing page changes. Most of the time the changes won't matter to you but they could reflect a need to update your ads or in an extreme case - this case - the need to disable your ads. Several years ago, I had a job where it was very helpful for me to know when and if a set of services were down or had changed. I used https://www.runscope.com/ to notify me if a set of tests didn't pass.

As a software engineer, it is really valuable to listen to the problems that your coworkers are facing, even the ones in different departments. You might hear an account manager complain about how much of a hassle it is to constantly check for press releases that relate to any of their accounts. Then you can helpfully share that you use Feedly to monitor the release of new webcomics and they could use it to get notified of press releases or anything online.

Your Brain At Work

Your Brain at Work: Strategies for Overcoming Distraction, Regaining Focus, and Working Smarter All Day Long by David Rock
My rating: 3 of 5 stars

Great advice but the presentation via examples made the material hard to endure. Also the examples were so extreme I found them to be a bit off-putting. They followed a pattern of saying that without the miracle techniques being presented in the book you would end up poor and unloved and it would be your own fault. But by applying the strategies from the book you would be successful in business, friendship, parenthood, and you would have more sex.

Don't get me wrong. There is undoubtable good advice in this book but results will vary. Some of the strategies will likely offend other people because they might feel that they are being manipulated. Read this book with a large pinch of salt.

View all my reviews

Inspect Code

Inspection of software design and code was first proposed by Michael Fagan in "Design and Code Inspections to Reduce Errors in Program Development," IBM Systems Journal, July 1976. Inspection can account for as much as 82 percent of all errors found in software. Inspection is much better than testing for finding errors. Define criteria for completing an inspection. Keep track of the types of errors found through inspection. Fagan's inspections consume approximately 15 percent of development resources with a net reduction in total development cost of 25 to 30 percent.

A project schedule should account for the time to inspect, and correct, every component. It might seem that a project cannot tolerate such "luxuries." However, inspection should not be considered a luxury. Data has shown that you can even reduce the time to test by 50 to 90 percent. If that's not incentive, I don't know what could be. By the way, there is a wealth of support data and tips on how to do inspections well in "Key Lessons in Achieving Widespread Inspection Use," IEEE Software, July 1994 by R. Grady and T. VanSlack.

Smoke Gets In Your Eyes

Smoke Gets in Your Eyes: And Other Lessons from the Crematory by Caitlin Doughty
My rating: 5 of 5 stars

A fascinating book with a lot to teach. I wouldn't recommend it for someone who is young. There are a lot of the lessons are hard ones. However, I wonder if it should be required reading for an adult or a kid in high school.

View all my reviews

Hand-Test Every Component

It might take 30 minutes to test a software component by hand with a few simple test cases. Do it! I am suggesting this in addition to, not in lieu of, the more thorough computer-based unit testing that is already being performed. What is the cost? Just 30 minutes. What is the alternative? Save 30 minutes now, proceed with unit, integration, and system testing. The system fails. Three to four person days are spent trying to isolate the cause of the failure. A half-dozen components are isolated as possible candidates. Each is given to its developers for further examination. Each candidate spends 30 minutes testing the component by hand with a few simple test cases. In short, 30 minutes are less than three to four person days plus 6 x 30 minutes.

Another reason to perform routine manual testing is that it identifies components that need to be updated. All your builds and automated tests will pass and not complain with outdated tech. But when developers have to manually test a component with an outdated build or libraries, they will complain and get it updated. Which will keep the software relevant.


Reference:
Ledgard, H., Programming Proverbs, Rochelle Park, NJ: Hayden Book Company, 1975.