Alchemy

Alchemy: 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

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.

People Are The Key To Success

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.

Understand The Customers' Priorities

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.

Don't Believe Everything You Read

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.

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.

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.

Analyze Causes For Errors

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.

Instrument Your Software

When testing software, it is often difficult to determine why the software failed. One way of uncovering the reasons is to instrument your software, that is, embed special instructions in the software that report traces, anomalous conditions, procedure calls, and the like. Of course, if your debugging system provides these capabilities, don't instrument manually.

Reference:
Huang, J., "Program Instrumentation and Software Testing," IEEE Computer, April 1978.

Rust by Jonathan Waldman

Rust: The Longest War by Jonathan Waldman
My rating: 5 of 5 stars

Rust (corrosion) is a constant companion to all life on Earth. It seems to happen so slowly that we fool ourselves into thinking that we can deal with it later. This book covers corrosion across the range of human experience. It interesting due to how tremendous of an impact corrosion has on modern life. A lot of the book is detailed and filled with facts. It slowed my reading down as I tried to absorb and remember information.

View all my reviews

Who Goes There

Who Goes There? by John W. Campbell Jr.
My rating: 5 of 5 stars

An excellent short book for October as Halloween quickly approaches. A lot of the language describing the shapeshifting alien so much reminds me of how they described and detected for Changelings in Star Trek: Deep Space 9 that I suspect that those writers were also fans.

View all my reviews

Don't Integrate Before Unit Testing

Under normal circumstances components are separately unit-tested. As they pass their unit tests, a separate team integrates them into meaningful sets to exercise their interfaces. Components that have not been separately unit-tested are often integrated into the subsystem in a vein attempt to recapture a lost schedule. Such attempts actually cause more schedule delays. This is because a failure of a subsystem to satisfy an integration test plan may be caused now either by a fault in the interface or by a fault in the previously untested component. And much time is spent trying to determine which is the cause.

If you are managing a project, you can do a variety of things to avoid this situation. First and foremost is to develop an integration test plan early (for example, very soon after high-level design is complete). This plan should specify which components are most important to integrate first and in what order components may be integrated. Once you have written this down, allocate appropriate resources to coding and unit testing of specific high-priority components to ensure that integration testers don't spend an inordinate amount of time idle. Second, as it becomes evident that important components for integration testing are going to be unavailable as needed, have the integration testers start developing temporary scaffolding software to simulate the missing components.


Reference:
Dunn, R., Software Defect Removal, New York: McGraw-Hill, 1984.

Angle of Attack

I've been reading Flying Beyond the Stall: The X-31 and the Advent of Supermaneuverability by Douglas A. Joyce. Very quickly what struck me was that the issue that caused the X-31 to crash in 1995 was incorrect Angle of Attack (AoA) sensor data causing the software to override the pilot and crash the plane. Which was the same thing that happened to the Boeing 737 Max planes that crashed.

Maybe it is because I'm getting older but I'm getting more and more concerned about how the Tech industry forces older engineers out and tries to replace them with entry-level programmers. This isn't an natural issue of passing the baton. This is an issue of trying to replace highly skilled and experienced people with minimally skilled and no experience people.

So many of the software issues that we fight today have already been solved. If we just take the time to learn from the past then we could avoid repeating these mistakes.

Spaceman

Spaceman: An Astronaut's Unlikely Journey to Unlock the Secrets of the Universe by Mike Massimino
My rating: 5 of 5 stars

Wow! Who hasn't dreamed of spaceflight?! I loved the humanity that Massimino brings to the subject. This is a story that is told from his perspective but goes through many subjects that many people either relate to or want to know more about - childhood dreams, college, work, NASA, flight, spaceflight, parenthood, etc. It is wonderful to see those things through Massimino's eyes. Space exploration is awesome, and it needs people like Massimino to share the story; to bring us all along.

View all my reviews

Starman Jones

Starman Jones by Robert A. Heinlein
My rating: 5 of 5 stars

I loved the concern that Max had for his library book. That really hooked me into the book. After that it was a fast, fun ride.

View all my reviews

SuperFreakonomics

SuperFreakonomics: Global Cooling, Patriotic Prostitutes And Why Suicide Bombers Should Buy Life Insurance by Steven D. Levitt
My rating: 5 of 5 stars

Second time reading and still worth the read. It can be a little disheartening to know that some (many / maybe most) of the things discussed didn't make it into mainstream in the past 10 years. That is a lesson in itself and the concept is supported by a few of the stories in SuperFreakonomics.

View all my reviews

Achieve Effective Test Coverage

In spite of the fact that testing cannot prove correctness, it is still important to do a through job testing. Metrics exist to determine how thoroughly the code was exercised during test plan generation or test execution. These metrics are easy to use, and tools exist to monitor the coverage level of tests. Some examples include:

1. Statement coverage, which measures the percentage of statements that have been executed at least once.
2. Branch coverage, which measures the percentages of branches in a program that have been executed.
3. Path coverage, which measures how well the possible paths have been exercised.

Just remember that, although "effective" coverage is better than no coverage at all, do not fool yourself into thinking that the program is "correct" by any definition (see Testing Exposes Presence of Flaws).

Reference:

Weiser, M., Gannon, J., and McMullin, P., "Comparison of Structural Test Coverage Metrics," IEEE Software, March 1985.

Use Effective Test Completion Measures

Many projects proclaim the end of testing when they run out of time. This may make political sense, but it is irresponsible. During test planning, define a measure that can be used to determine when testing should be completed. If you have not met your goal when time runs out, you can still make the choice of whether to ship the product or slip the milestone, but at least you know whether you are shipping a quality product.

Two ideas for this effective measurement of test progress are:

1. Rate of new error detections per week.
2. After covertly seeding the software with known bugs (called bebugging), the percentage of these seeded bugs thus far found.

An ineffective measure of test progress is the percentage of test cases correctly passed (unless, of course, you know that the test cases superbly cover the requirements).

Reference:

Dunn, R., Software Defect Removal, New York: McGraw-Hill, 1984.

The Dictator's Handbook

The Dictator's Handbook: Why Bad Behavior is Almost Always Good Politics by Bruce Bueno de Mesquita
My rating: 5 of 5 stars

I was expecting stories about evil dictators, not a practical guide to politics. The real-world feel of this book made me continuously think of the book Physics for Future Presidents.

View all my reviews

Use McCabe Complexity Measure

Although many metrics are available to report the inherent complexity of software, none is as intuitive and as easy-to-use as Tom McCabe's cyclomatic number measure of testing complexity. While it is not absolutely foolproof, it results in fairly consistent predictions of testing difficulty. Simply draw a graph of your program, in which nodes correspond to sequences of instructions and arcs correspond to non-sequential flow of control. McCabe's metric is simply e-n+2p where e is the number of arcs, n is the number of nodes, and p is the number of independent graphs you are examining. This is so simple that there is really no excuse not to use it.

Use McCabe on each module to help assess unit testing complexity. Also, use it at the integration testing level where each procedure is a node and each invocation path is an arc to help assess integration testing complexity.


Reference:
McCabe, T., "A Complexity Measure," IEEE Transactions on Software Engineering, Dec 1976.

The Big Bang Theory Does Not Apply

As a project nears its delivery deadline and the software is not ready, desperation often takes over. Suppose the schedule called for two months of unit testing, two months of integration testing, and two months of software system testing. It is now one month from the scheduled delivery. Suppose 50% of the components have been unit tested. A back-of-the-envelope calculation indicates that you are five months behind schedule. You have two choices:

1. Admit the five-month delay to your customer: Ask for a postponement.
2. Put all the components together (including the 50% not yet unit tested) and hope for the best.

In the first case, you are admitting defeat, perhaps prematurely. In the eyes of your managers, you might be giving up before you've done everything in your power to overcome the problem. In the second case, there might be a chance that, when you put it all together, it will work and you'll be back on schedule. Project managers often succumb to the latter because it looks like they are trying everything before admitting defeat. Unfortunately, this will probably add six more months to your schedule since you'll be trying to retrofit quality. You cannot save time by omitting unit and integration testing.

Reference:

Weinberg, G., Quality Software Management, Volume 1: Systems Thinking, New York: Dorset House, 1992.

Always Stress Test

Software design often behaves just fine when confronted with "normal" loads of inputs of stimuli. The true test of software is whether it can stay operational when faced with severe loads. These severe loads are often stated in the requirements as "maximum of x simultaneous widgets" or "maximum of x new widget arrivals per hour."

If the requirements state that the software shall handle up to x widgets per hour, you must verify that the software can do this. In fact, not only should you test that it handles x widgets, you should also subject the software to x+1 or x+2 (or more) widgets to see what happens and determine when environment violates "acceptable" behavior. After all, the system may not be able to control its environment, and you do not want the software to crash when the environment "misbehaves" in an unexpected manner.


Reference:
Myers, G., The Art of Software Testing, New York: John Wiley & Sons, 1979.

Test Invalid Input

It is natural and common to produce test cases for as many acceptable input scenarios as possible. What is equally important -- but also uncommon -- is to produce an extensive set of test cases for all invalid or unexpected input.

For a simple example, let us say we are writing a program to sort lists of integers in the range of 0 to 100. Test lists should include some negative numbers, some nonintegral numbers, some alphabetic data, some null entries, and so on.


Reference:
Myers, G., The Art of Software Testing, New York: John Wiley & Sons, 1979.

Range: Why Generalists Triumph in a Specialized World

Range: Why Generalists Triumph in a Specialized World by David Epstein
My rating: 5 of 5 stars

I loved it, but I'm biased since I have always been more of a generalist. :-D
Anyway, Range is packed with information. I found myself stopping a lot just to ponder what I had just read. I loved all the stories that were referenced as examples and food for thought.

The "Learning to Drop Your Familiar Tools" chapter was just brilliant. The description of the smokejumpers who just couldn't fathom dropping their tools is poignant and heartbreaking. Even though there are a ton of books on NASA culture and the Challenger and Columbia disasters, I'm certain that I would read a book on this topic if David Epstein wrote it.

View all my reviews

Chain of Communication

The following is paraphrased for my benefit. It is taken from an interview with Rex Geveden documented in the book Range: Why Generalist Triumph in a Specialized World by David Epstein.

I expect disagreement with my decisions at the time we're trying to make decisions, and that's a sign of organizational health. After the decisions are made, we want compliance and support, but we have permission to fight a little bit about those things in a professional way. There is a difference between the chain of command and the chain of communication, and that the difference represents a healthy cross-pressure.

I'm going to communicate with all levels of the organization from the CEO all the way down to the interns, and you can't feel suspicious or paranoid about that. I will not intercept your decisions that belong in your chain of command, but I will give and receive information anywhere in the organization, at any time. I just can't get enough understanding of the organization from listening to the voices at the top.

Problem Solving

Beware of the person who knows all the answers:

Suppose two politicians are running for president, and one goes through the farm section and is asked, "What are you going to do about the farm question?" And he knows right away - bang, bang, bang. Now he goes to the next campaigner who comes through. "What are you going to do on the farm problem?" "Well, I don't know. I used to be a general, and I don't know anything about farming. But it seems to me it must be a very difficult problem, because for twelve, fifteen, twenty years people have been struggling with it, and people say that they know how to solve the farm problem. And it must be a hard problem. So the way I intend to solve the farm problem is to gather around me a lot of people who know something about it, to look at all the experience that we have had with this problem before, to take a certain amount of time at it, and then to come to some conclusion in a reasonable way about it. Now, I can't tell you ahead of time what solution, but I can give you some of the principles I'll try to use - not to make things difficult for individual farmers, if there are any special problems we will have to have some way to take care of them," etc., etc., etc.

Now such a man would never get anywhere in this country, I think. It's never been tried, anyway. This is in the attitude of mind of the populace, that they have to have an answer and that a man who gives an answer is better than a man who gives no answer, when the real fact of the matter is, in most cases, it is the other way around. And the result of this of course is that the politician must give an answer. And the result of this is that political promises can never be kept. It is a mechanical fact; it is impossible. The result of that is that nobody believes campaign promises. And the result of that is a general disparaging of politics, a general lack of respect for the people who are trying to solve problems, and so forth. It's all generated from the very beginning (maybe - this is a simple analysis). It's all generated, maybe, by the fact that the attitude of the populace is to try to find the answer instead of trying to find a man who has a way of getting at the answer.

 —Richard Feynman

And make sure that person is not you.

A Test Case Includes Expected Results

Documentation for a test case must include the detailed description of the expected correct results. If these are omitted, there is no way for the tester to determine whether the software succeeded or failed. Furthermore, a tester may assess an incorrect result as correct because there is always a subconscious desire to see a correct result. Even worse, a tester may assess a correct result as incorrect, causing a flurry of designer and programmer activity to "repair" the correct code.

Develop an organization standard for test plans that demands the documentation of expected intermediate and final test case results. Your quality assurance organization should confirm that all test plans conform to the standard.


Reference:
Myers, G., The Art of Software Testing, New York: John Wiley & Sons, 1979.

Use Black-box And White-box Testing

Black-box testing uses the specification of a component's external behavior as its only input. It is mandatory to determine if the software does what it is supposed to do and doesn't do what it is not supposed to do. White-box testing uses the code itself to generate test cases. Thus white-box testing might demand, for example, that a certain level of code coverage is obtained. Be aware; however, that even with both black-box and white-box testing, testing can make use of only a small subset of possible data values from the input domain.

To demonstrate how black-box and white-box testing complement each other, let's look at an example. Let's say a procedure's specification states that it should print the sum of all numbers in an input list. When programmed, it looks for one input of 213 and, if it finds it, sets the sum equal to zero. Since that was not in the specification, there is no way to find the error by black-box testing except by accident. White-box testing would demand that paths are more adequately tested, and thus would probably detect the "213" situation. By combining black-box and white-box, you maximize the effectiveness of testing. Neither one by itself does a through test.


Reference:
Dunn, R., Software Defect Removal, New York: McGraw-Hill, 1984.

Track Errors To Find More Errors

Conservative estimates indicate that, in large systems, approximately half of all software errors are found in 15% of the modules, and 80% of all software errors are found in 50% of the modules. More dramatic results from Gary Okimoto and Gerald Weinberg indicate that 80% of all errors were found in just 2% of the modules. Thus, when testing software, you might consider that, where you find errors, you will probably find more.

Maintain logs not only of how many errors are found per time period for the project, but also how many errors are found per module. When history shows a module to be highly error-prone, you are probably better off rewriting it from scratch, with an emphasis on simplicity rather than cleverness.


References:
Okimoto, G. and Weinberg, G., Quality Software Management, Vol. 1: Systems Thinking, New York: Dorset House, 1992.

Endres, A., "An Analysis of Errors and Their Causes in System Programs," IEEE Transactions on Software Engineering, June 1975.

A Successful Test Finds An Error

I have often heard a programmer or tester gleefully declare, "Great news! My test was successful. The program ran correctly." This is the wrong attitude to have when running a test. It also supports the position that programmers should never be the sole testers of their own software. A more constructive attitude is that one is testing to find errors. Thus, a successful test is one that detects an error. Look at the analogous situation with a medical test. Suppose you are feeling ill. The doctor sends a sample of your blood to a laboratory. A few days later, the doctor calls to tell you, "Great news! Your blood was normal." That is not great news. You are sick or you wouldn't have gone to the doctor. A successful blood test reports what's wrong with you. The software has [the potential for] bugs. A successful test reports how these bugs manifest themselves. When generating test plans, you should first select tests based on the likelihood that they will find faults. Only after those tests are written and ran should you write tests for the sake of code coverage.


Reference
Goodenough, J., and Gerhard, S., "Toward a Theory of Test Data Selection," IEEE Transactions on Software Engineering, June 1975.

The Obstacle Is the Way

The Obstacle Is the Way: The Timeless Art of Turning Trials into Triumph by Ryan Holiday
My rating: 5 of 5 stars

A perfect book to carry with you everywhere. The chapters are short and standalone so you can skip them or jump around or re-read certain chapters without it interrupting the flow of the book.

View all my reviews

Absence of Errors Fallacy

Though copious errors guarantee worthlessness, zero errors says nothing about the value of software. This is Gerald Weinberg's "Absence of Errors Fallacy." It really puts testing into perspective. It also puts all software engineering and management into perspective. The first part of the principle is obviously true; software with many errors is useless. The second part provides food for thought. It says that, no matter how hard you work to remove errors, you are wasting your time unless you are building the right system. Akao's Quality Function Deployment provides details on one method of ensuring that you are building the right system throughout the live cycle. A corollary to this principle is that all the formal methods, all the testing, and all the product assurance in the world won't help if you are building the wrong system.


Reference:
Weinberg, G., Quality Software Management, Vol. 1: Systems Thinking, New York: Dorset House, 1992.

Shakedown

Doctor Who: Shakedown by Terrance Dicks
My rating: 4 of 5 stars

Can you really have a Doctor Who story that is not about Doctor Who? Yes! In fact, this story is certainly better for having so little focus on the Doctor.

View all my reviews

Doctor Who: The Mind of Evil

Doctor Who: The Mind of Evil by Terrance Dicks
My rating: 3 of 5 stars

The BBC Audio is from the television soundtrack which leaves a fair amount of detail out. It is okay if you are a Doctor Who fan and know who the characters are but in no way should it be considered a standalone book.

View all my reviews

When to Rob a Bank

When to Rob a Bank by Steven D. Levitt
My rating: 3 of 5 stars

There are a few gems in here that should be revisited and reframed for today. There is also a lot that was only relevant in the past. Overall, it is worth reading but maybe with an eye to skipping anything that seems overly out-of-date.

View all my reviews

Wayne of Gotham

Wayne of Gotham by Tracy Hickman
My rating: 2 of 5 stars

While reading this book I felt that there was too much everything. The crazy people were too crazy. The rich people were too snobbish and blind. Batman was too paranoid.

And yet, after finishing and thinking back on it I cannot come up with a better way of handling the story. The crazy people only seem too crazy because fragmented and false memories really do leave people making no sense. And maybe rich people really are snobs and blind to the world beyond their money. And Batman being paranoid is not a new theme and why wouldn't it just get worse as he gets older?!

View all my reviews

Testing Exposes Presence Of Flaws

No matter how through, testing simply exposes the presence of flaws in a program; it cannot be used to verify the absence of flaws. It can increase your confidence that a program is correct, but it cannot prove correctness. To gain true correctness, one must use completely different processes, that is, correctness proofs.


Reference:
Dijkstra, E., "Notes on Structured Programming," in Structured Programming, Dahl, O., et al., Academic Press, 1972.

Don't Write Your Own Test Plans

Not only should you not be the sole tester of your own software, but you should also not be responsible for generating the test data, test scenarios, or test plans for your software. If you are, you may make the same mistakes in test generation that you made in software creation. For example, if you made a false assumption about the range of legal inputs when engineering the software, you would likely make the same assumption when generating test plans.

If you are a programmer and/or designer and your manager has asked you to write your test plans, I recommend you switch the test plan generation responsibility with a fellow programmer and/or designer. If you are a member of a requirements engineering team, with responsibility for system test generation as well, I recommend that members of your team subdivide the responsibilities so that no individual generates tests for requirements that she or he wrote.

Don't Test Your Own Software

Software developers should never be the primary testers of their own software. It is certainly appropriate to do initial debugging and unit testing.

Independent testers are necessary:

1. To check a unit for adequacy before starting integration testing.
2. For all integration testing.
3. For all system testing.

The correct attitude during testing is that of wanting to expose bugs. How can a developer possibly embrace that attitude? Testing is difficult enough without burdening it further with testers who have a bias toward no finding bugs.

Reference:

Myers, G., The Art of Software Testing, New York: John Wiley & Sons, 1979.

Plan Tests Long Before It Is Time To Test

Often software developers create their software product, then scratch their heads and say, "Now, how are we going to test this thing?" Test planning is a major task and must occur in parallel with product development so that test planning and initial (that is, pretesting) development activities are completed in synchrony.

For software system testing, test planners should review the SRS for testability before it is baselined and provide feedback to requirements writers. Serious development of the tests should start soon after baselining requirements. For integrations testing, test planners should review the preliminary design before it is baselined. They should also provide feedback to the project managers and designers concerning (1) sensible allocations of resources to ensure that the "right" components (from a testing point of view) are produced in the right order and (2) modifications to the design to make it inherently easier to test. Serious integration test development should start soon after baselining the preliminary design. For unit testing, unit test plan development can start immediately after the completion of detailed design.


Reference:
Goodenough, J., and Gerhart, S., "Toward a Theory of Test Data Selection," IEEE Transactions on Software Engineering, June 1975.

It's Superman

It's Superman! by Tom De Haven
My rating: 3 of 5 stars

I enjoyed Tom De Haven's writing style and the story was good. But there were too many liberties taken with the idea of Superman for me to really enjoy it. De Haven puts a heavy gloss of reality on the story of Superman and sets the origin story in the 30s.

View all my reviews

Trace Tests To Requirements

It is important to understand which tests verify which requirements. There are two reasons:

1. When generating tests, you'll find it useful to know if all requirements are being tested.
2. When performing tests, you'll find it useful to know which requirements are being checked.

Furthermore, if your requirements have been prioritized, you can easily derive the relative priorities of the tests; that is, the priority of a test is the maximum of the priorities of all its corresponding requirements.

Maintain a large binary table in which rows correspond to all software tests and columns correspond to every requirement in the software requirements specification (SRS). A 1 in any position indicates that this test helps to verify this requirement. Notice that a row void of 1's indicates that a test has no purpose and that a column void of 1's indicates an untested requirement. The successful creation of such a table depends on your ability to refer uniquely to every requirement.

Reference:

Lindstrom, D., "Five Ways to Destroy a Development Project," IEEE Software, Sept. 1992.

Travel Ireland

It has been over a decade since I visited Ireland. Above is a photo of me at Blarney Castle. I like to watch the various travel videos that Expedia makes to remind me of places I've been and places that I would like to go.

Check out "Visit Dublin –Things To Do and See in Dublin, Ireland":

Obviously, I would recommend visiting Blarney Castle once you're done in Dublin.

   

Don't Code Too Soon

Coding software is analogous to constructing a building. Both require much preliminary work. Constructing a building without a solid and stable foundation will not work. Coding without a solid and stable foundation of requirements and design will not work. Think about how much more difficult it is to modify a building after the foundation is poured!
    Don't be coerced into coding prematurely because management wants to see "progress." Be sure the requirements and design are correct and appropriate before baselining them and certainly before coding the final product. Incidentally, don't conclude from this principle that prototyping is bad. There is nothing wrong with experimenting with coding long before requirements are baselined. Just don't consider it the final product. Manny Lehman adds a counterpoint to this principle: Don't code too late!


Reference:
Berzins, V., and Luqi, Software Engineering with Abstractions, Reading, MA: Addison-Wesley, 1991.

Format Your Programs

The understandability of a program is greatly enhanced by using standard indentation protocols. Which protocol you choose to follow matters little, but, once you select it, use it consistently.

The only thing worse than inconsistent indentations is incorrect indentation (such as, aligning an ELSE with the wrong IF)! To prevent accidental misalignments, use a pretty printer.


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

Harry Potter and the Order of the Phoenix

Harry Potter and the Order of the Phoenix by J.K. Rowling
My rating: 5 of 5 stars

Harry Potter and the Order of the Phoenix assaulted my emotions more than any of the previous books. There were plenty of unfair issues to feel sympathy for in the earlier books but emotions are more quickly evoked in this book. I do hope that Harry is able to better control his anger in the next book. And Snape is such a sad example of what happens to a person when they can't let go of past grievances. Seriously, a study of Snape should be a required course so people can think about would sort of sad sack they might turn into if they hang onto anger and hate. I am thoroughly enjoying the different characters in this series.

View all my reviews

Language Knowledge Is Not So Important

Good programmers are good regardless of the language used. Poor programmers are poor regardless of the language used. Nobody is a "great Java programmer" and a "poor Python programmer." If they really are poor at Python, they probably were not great at Java! In addition, a really good programmer should be able to learn any new language easily. This is because a really good programmer understands and appreciates the concepts of quality programming, not just the syntactic and semantic idiosyncrasies of some programming language.

So the primary driver of language selection for a project should be appropriateness, not the surge of programmers who whine, "But all we know is Ruby." If some quit because the project selected a different language, the project is probably better off!


Reference:
Boehm, B., Software Engineering Economics, Englewood Cliffs, NJ: Prentice Hall, 1981.

https://www.youtube.com/watch?v=fkY7W6kCRY4

Programming Language Is Not An Excuse

Some projects are forced to use a less-than-ideal programming language. This might be caused by a desire to reduce maintenance costs ("All our maintainers know RPG"), to program fast ("It is so easy to get a fully featured application with Python"), to ensure high reliability ("Ada programs are the most fail-safe"), or to achieve high execution speed ("Our applications are time-critical, we need to use C"). It is possible to write quality programs in any language. In fact, if you are a good programmer, you should be a good programmer in any language; a less-than-ideal language might make you work harder, though.


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

Harry Potter and the Goblet of Fire

Harry Potter and the Goblet of Fire by J.K. Rowling
My rating: 5 of 5 stars

Wow! I can see why people raved about the Harry Potter series. There is so much good stuff in here and not just fun adventure but difficult topics like prejudice and death.

View all my reviews

Use Appropriate Languages

Programming languages vary greatly in their ability to help you do your job. Your specific project or product goals will often dictate the appropriate language. The following guidelines are meant to be just that - guidelines, not gospel.

If your number one goal is portability, then use a language that has been demonstrated to be highly portable. If your number one goal is fast development, the use a language that aids in such fast development. If your primary goal is low maintenance, then use a language with many built-in, quality-inducing features. If your application requires a great use of character strings or complex data structures, select a language that supports them. If your product must be maintained by a group of existing maintainers who know language X, then use language X. Finally, if your customer says to use language Y then use language Y or you won't be in business long.

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

Evita anidar demasiado profundo

El anidamiento de las instrucciones IF-THEN-ELSE simplifica enormemente la lógica de programación. Por otro lado, anidarlos más que, por ejemplo, tres niveles de profundidad reduce en gran medida su capacidad de comprensión. La mente humana es capaz de recordar solo una cierta cantidad de lógica antes de que se confunda. Se puede utilizar una variedad de técnicas simples para reducir el anidamiento.

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