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.

Ethical vs Policy Crisis

This past Christmas I read a lot of posts from my friends about their kid's love of Harry Potter and their Harry Potter themed Christmas gifts. It is pretty awesome that they were able to have this shared interest. So when I read this past Penny Arcade comic, https://www.penny-arcade.com/comic/2018/04/30/hogwash, I was shocked and angered. This hits close to home: My friends might be experiencing this extortion. If the comic doesn't provide enough information (it didn't for me) then read (or skim) https://www.eurogamer.net/articles/2018-04-27-harry-potter-hogwarts-mystery-is-ruined-by-its-in-game-payments.

Summary: There is a scene in the game where the player (your child) is getting choked by a vine. They can either pay real money in order to stop it or wait for their energy to recharge (many minutes of watching their avatar get choked). And there are many other things like that.

This comic strip is so spot on; panel 2, especially so. I've read several articles in the last few months calling for Computer Science to include ethics in more classes instead of the traditional capstone course on ethics. In the Jan 2019 issue of CACM, Moshe Vardi pointed out that more ethics in classes will be nice but that it won't change anything. The only thing that will force these companies to change is public policy -- regulation that bans these practices that target children. (Sorry, I have to say it for the sake of completeness.) If this stuff* matters to you then you need to write to your state representatives.

* stuff being any unethical practice being carried out via a computing device.

Use Meaningful Names

Some programmers insist on naming variables with names like nflt or nFlight. The usual argument is that it makes programmers more productive because of reduced key presses. Good programmers should spend a very small percentage of their time typing (maybe 10 to 15 percent); most time should be spent thinking. So how much time is really being saved?

A better argument is that overly shortened names actually decrease productivity. There are two reasons:

1. Testing and maintenance costs rise because people spend time trying to decode names, and
2. more time is spent typing comments to explain the shortened names!

Reference:

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

Know Your Application

No matter how well the requirements have been written, the selection of optimal architectures and algorithms is very much a function of knowing the unique characteristics of an application. Expected behavior under stress situations, expected frequency of inputs, life-critical nature of response times, likelihood of new hardware, impact of weather on expected system performance, and so on are all application-specific and often demand a specific subset of possible alternative architectures and algorithms.


Reference:
Curtis, B., et al, "A Field Study of the Software Design Process for Large Systems," CACM, November 1988.

Specify When Environment Violates "Acceptable" Behavior

Requirements specifications often define characteristics of the system's environment. This information is used in making intelligent design decisions. It also often implies that the developer is contractually obligated to accommodate such characteristics. What happens after deployment when the environment exceeds the specified limits?

Suppose the requirements for an air traffic controller system specify that the system shall handle up to 100 aircraft in a sector simultaneously. They system is built and correctly satisfies this requirement. Three years later 101 aircraft accidentally enter a sector. What should the software do? The possibilities are:

1. Print an error message.
2. Crash.
3. Ignore the 101st aircraft.
4. Process all 101 aircraft but perhaps not satisfy some other timing constraint (such as how often the screen is updated).

Obviously, options 1, 2, and 3 are unacceptable. Yet they are valid system responses as (not) stated in the requirements. The right solution is to explicitly state in the software requirements specification (SRS) the expected system response when the environment exceeds any of the constraints defined for it.


Reference:
Davis, A., Software Requirements: Objects, Functions, and States, Prentice Hall, Englewood Cliffs, 1993.

Follow The Lemmings With Care

"If 50 million people say a foolish thing, it is still a foolish thing."
-- Anatole France

Just because many (perhaps even, most) people are doing something does not make it right for you. It may be right, but you need to carefully assess its applicability to your environment. Some examples are:

• object-orientation, software measurement
• You Can Optimize Whatever You Want*
• Collect Data Unobtrusively*
• Know Before You Count*
• Collect Productivity Data*
• Don't Forget Team Productivity*
• software reuse
• You Can Reuse Without a Big Investment
• process maturity
• Use an Appropriate Process Model
• computer-aided software engineering (CASE)
• Technique Before Tools
• Use Tools, but Be Realistic
• Give Software Tools to Good Engineers
• Tools Are Expensive
• prototyping
• Build the Right Kind of Prototype
• Build the Right Features into a Prototype
• Build Throwaway Prototypes Quickly
• Prototypes Reduce Risk in Selecting User Interfaces

In all cases, these offer very positive opportunities for increased quality, decreased cost, or increased user satisfaction. However, the advantages are available only to those organizations in which it makes sense. Although the rewards are significant, their potentials are often oversold and are by no means guaranteed or universal.

When you learn about a "new" technology, don't readily accept the inevitable hype* associated with it. Read carefully. Be realistic with respect to payoffs and risks. Run experiments before making major commitments. But by no means can you afford to ignore "new" technologies (Don't Ignore Technology).

Reference:
Davis, A., "Software Lemmingineering," IEEE Software, September 1993.

Don't Reinvent the Wheel

When electrical engineers design new printed circuit boards, they go to a catalog of available integrated circuits to select the most appropriate components. When architects design homes, they go to catalogs of prefabricated doors, windows, moldings, and other components. All this is called "engineering." Software engineers usually reinvent components over and over again; they rarely salvage existing software components. It is interesting that the software industry calls this rare practice "reuse" rather than "engineering."

Web Development Best Practices

The following are techniques for maximizing website performance on mobile devices. Personally, since more and more mobile devices are being used to browse content, I think all Web development should be done against the constraints of mobile. Please don't make a "full website" and a "mobile website". Those setups never look good or function well. Furthermore, redirecting a mobile request to a mobile site is expensive and slow. If you are dead set on the "full website" and "mobile website" configuration then make mobile the default and redirect to the full site if the request is not from a mobile device.

A mobile site needs to compensate when bandwidth or service becomes spotty. In other words, the site needs to be responsive even when the network is not. The same can be said for regular websites. Especially if you are trying to break into areas with questionable Internet service, e.g. Bolivar, Missouri, or questionable firewalls, e.g. China.

Eliminate HTTP Requests and Round Trips

• Use CSS sprites to represent images embedded as inline data:URLs.
• Use HTML5 application cache (app cache) to force the browser to cache all the unchanging content.
• Insert dynamic content in the document via XHR (XMLHttpRequest).
• Most effective if you can design the prefix of your page to fit into a single packet, 1492 bytes, render a basic framework for the page before any script is executed. To give the user immediate feedback that the page is loading, load the framework of the page as a fade effect by providing an opacity transitions from 0.0001 to 1.0 just after the framework is loaded. If you cannot get the basic framework of your page to fit into the first packet, then you can instead load a spinner or a logo, again as an opacity transition from 0.0001 to 1.0. The spinner or logo should be conditionally loaded after checking whether the app cache is already populated.
• <script>
    if (window.applicationCache.status == 0) { // Reveal the spinner
  } else {
    // Page was loaded from app cache. Bring out the kitchen sink.
  }
  </script>

• Make changes to minimize DNS lookups and redirects.

Use Compression

• nuff said.

Manage JavaScript Parse Time

• Move the vast majority of script to the bottom of the page.
• Allow the browser to load your JavaScript without recognizing it as script and defer parsing and initial evaluation until needed.
• To do this, set the type of the script to an unrecognized type and change it to text/JavaScript later. For example,
  <script type="deferred" id="module1">
    // deferred code here
  </script>
  When you are ready to use the script, reference the script tag by the id and change the type. The browser will parse and evaluate the script at that time.

Avoid Layout and Style Calculation

• Avoid reading properties that rely on the position of elements on the page to be returned. Any such property could cause the browser to recalculate styles on demand and return the value to your script.

Monitor Request Size

• Reduce the number of cookies you are using.
• Ideally, all requests should be smaller than a TCP packet.

Preload Components

• When the odds are good that you know what a user will request next then it is time to preload.
• This can be seen in Google's Calendar website. The next day's events are loaded as the user clicks through each day, giving the effect that all of the data is already loaded.

Optimize Images

• It is worth the time and effort to experiment with finding a good balance of image compression vs image quality.

Common Recommendations with Questionable Consequences

Make JavaScript and CSS External?

• Inlining all your JavaScript and CSS into each webpage will deliver the best results in terms of speed. For maintenance reasons, you could use XHRs to fetch the JavaScript or CSS and the HTML5 database to store the resource for later reuse.

Make AJAX Cacheable?

• Skip trusting the browser to cache AJAX responses. You're better off to build a full-blown write-through cache layer or a XHR caching layer on top of the HTML5 database.

Merciless Refactoring

Many people are afraid to make code changes out of fear that they will break the code. To ensure you can safely make code changes you should change it often. I'm not talking about pointless changes but solid improvements. Run FindBugs against your code and fix the issues. If you disagree with FindBugs then use PMD or any static analysis tool. However, if static analysis suggests that your code looks like a bug then consider changing it to look less dangerous.

Anyway, the point of merciless refactoring is to always be improving your code. To make changes and ensure that it was easy to make those changes. If it isn't fast and easy then you need to make changes to make it fast and easy. Write unit tests, delete unused code, optimize loops, automate tests; everything you can do to make it possible to complete your next project in record time.

Merciless refactoring can also be described as following the boy scouts rule of always leaving a place cleaner than when you found it. If you add a method to a class then add some JavaDocs to the other methods while you're there. If you change a single line of code in a method, take a look at the entire class and fix it up if you can.