Considering the Performance Triangle

It has been at least ten years ago now that I was reading an article and considering its ramifications in light of my current book. The name of the article has fallen by the wayside over the years, but the book was entitled, “.NET Development Security Solutions.” I was considering two important questions in the creation of my book:


  • Is it possible to create a truly secure application?
  • What is the actual cost of a secure application?

They’re essential questions and the answers to them continue to have an effect on my book writing efforts. The answer to the first question is yes—it’s possible to write a truly secure application. However, in order to obtain such an application, it can’t have any connectivity to anything. The second that an application has any connectivity, whatsoever, with anything else, it becomes contaminated by that connection. Don’t just think about users entering incorrect data here. The data on a hard drive can be corrupted, as can the memory used to hold the application. For that matter, someone could probably make the argument that it’s possible to create serious problems in the processor. My readers are a truly ingenious lot, so I’m sure if I gave you enough time, you could come up with an application that has no connectivity whatsoever with anything, but the usefulness of such an application is debatable. What good is an application with no inputs or outputs? I came to the conclusion, after quite a few hours of thought, that the most secure application in the world does nothing at all, interacts with nothing at all, and is pretty much worthless.

As I considered this security dilemma, it occurred to me that a truly secure application has no speed and is completely unreliable, given that it doesn’t do anything at all. As I worked through this book, I eventually came up with a performance triangle, where these sides are based on:


  • Security: The ability of the application to prevent damage to the application data, application code, the host system, and any connected systems.
  • Reliability: The accessibility of the application by the user. A reliable application is available for use at all times and makes every possible feature available to the user in a manner that precludes damage to the data or the system.
  • Speed: The pace at which an application can accept input, perform tasks, and provide output.

In order to increase speed, you must remove code that provides security and reliability. (I’m assuming here that the code is already as efficient as you can make it.) Likewise, when adding security features, you decrease
application availability in some situations and also add code that affects application speed. Making code reliable (which infers accessibility) reduces security and speed. The performance triangle has worked out for me for many years now as the basis for thinking about how application code actually works and the tradeoffs I must consider while writing it.

The use of the performance triangle isn’t based on language or platform. Whether you work on a Macintosh, Linux system, or Windows, you need to consider the effects of the performance triangle on your application irregardless of the host system. Likewise, language choice doesn’t affect the performance triangle, except that some languages provide more features that enhance a particular triangle element more than others. For example, C++ provides a significant speed advantage over many applications, but at a known cost to both security and reliability because the programmer is made responsible to adding the required safeguards. C# provides more safeguards, which enhances reliability, but at the cost of speed.

A problem in the current application design environment is that developers often focus on one element of the triangle (normally speed or security) at the cost of the other two. In order to build an application that performs well in a specific situation, the developer must consider the ramifications of all three triangle elements—an incredibly difficult task in some situations.

Even the questions that developers ask about the three elements of the performance triangle are often flawed. For example, many developers equate reliability with up time, but up time is only part of the reliability picture. An application that produces inconsistent results, denies required access to the user, or damages data in some way is unreliable. Robust applications explore all of the elements fully.

In the end, developers are usually faced with an imperfect scenario. Conflicting requirements and real world necessities often serve to weaken a good application design so that the developer must carefully craft the application to meet the maximum number of these requirements with the fewest possible faults. The situation comes down to one of weighing risk. A developer needs to ask which issue is most likely to cause the most harm and then write code that addresses that issue.

What sorts of design issues are you facing when developing applications? Do you use something like the performance triangle to help you consider the risks incurred when choosing one course over another in application development? Let me know your thoughts at


More on CFL Usage

Readers came back with a few questions about CFLs after reading my CFLs for Free post. The one thing I want to get across clearly is that the article is emphasizing that you can buy new CFLs using the savings from previous purchases. You need to make the investment in the first CFL to get started and then use the savings from that investment to buy future CFLs. No one is going to mysteriously pay you to buy CFLs, but if you buy smart, you can indeed get future CFLs for free after making the initial purchase. Eventually, you’ll pay off the initial purchase using the savings as well.

A number of people asked about the startup surge (also known as inrush current). The startup surge is something that occurs when you first apply power to the light. This surge is extra electricity that’s required to get the bulb started. The amount of power the bulb requires decreases as it gets to operating temperature, which isn’t very long in most cases. Of course, some people are worried about this electricity surge as some people often think they are experiencing a power surge. Luckily, these two things are quite different. If a homeowner did experience a power surge, it would be worth them contacting a company like Safe and Sound Electric to install some surge protection to prevent this happening again. However, this bulb requires that extra surge, so don’t be concerned if you notice a quick surge. I’ve read a number of conflicting opinions about the startup surge of CFLs. My take on everything I’ve read is that the startup surge will vary by bulb vendor and type of light. A tube light has a smaller startup surge for a significantly smaller time than the twisted bulbs. Vendors who meet Energy Star requirements tend to produce bulbs that have a smaller startup surge than the less expensive bulbs.

A few readers also asked about long term efficiency of CFLs. From personal experience Rebecca and I have found that CFLs do provide an efficiency advantage if you use them for one long interval, rather than several short intervals. In other words, if you burn the light for four hours solid instead of two, two hour intervals, you’ll gain an efficiency advantage. In addition, turning the light on and off reduces its life expectancy.

Efficient energy use is why Rebecca and I tune our work schedule to follow the sun. We get up at 5:30 am (sometimes a bit earlier) during the summer months to make maximum use of the daylight hours, but we get up at 7:00 am during the winter months to ensure we won’t have to turn the lights on in the morning. The actual difference between summer and winter work times is 2½ hours due to the effect of daylight saving time. We do work later into the evening during the winter months to make up for the later start time, so everything evens out. Using this approach has had both health and monetary benefits, but we also understand that it’s not a solution that most people can use.

There are a lot of myths, misconceptions, and outright controversies about CFLs online. In addition, I’m finding that people have individual experiences based on how they use lighting in their home. However, after researching this topic intensively, I’m finding that the following tips about CFLs seem to be true for just about everyone:

  • Buying CFLs with the Energy Star label tends to pay dividends in reduced operating costs and longer life, but you must weigh these benefits against the increased initial cost. In general, buying Energy Star products save you money.
  • If you must use a CFL in a socket controlled by a dimmer, buy a CFL designed for that purpose. Using a standard CFL in a dimmer-controlled socket greatly reduces bulb life and could damage the dimmer.
  • CFLs require more air to work properly. They’re more heat sensitive, so putting one in a can or recessed fixture will result in a reduced life expectancy. The exception is that there are CFLs specially designed to work in recessed fixtures, but you’ll also pay a premium price for them.
  • CFLs also don’t like
    damp or wet conditions. If you need to use a CFL in a damp or wet
    condition, make sure you get one rated for that purpose.

  • Standard CFLs don’t work well in fixtures that vibrate, such as the lighting kits for fans. If you want to use a CFL with a fan or other fixture that will vibrate, you need to get a CFL designed for the purpose. (I finally gave up using a CFL in my garage door opener light socket because even the CFLs designed for use in vibration don’t last long in that particular application.)
  • Excessive on and off cycles in a given day will most definitely reduce the life expectancy of your CFL. I researched this one a lot and didn’t get a definitive answer for you. The most common guidelines say that you should strive to keep on/off cycles below 20 for any given CFL during one day. It’s commonly said that CFLs have a life expectancy of 7,000 on/off cycles if you observe the 20 on/off cycle per day limit. The source of problems in this case is the electronic ballast that CFLs use, which aren’t designed for heavy on/off cycles.
  • Faulty wiring affects CFLs considerably more than incandescent bulbs. If your wiring is such that it causes flickers or flashing with an incandescent bulb, the CFL won’t last very long. Even if you can’t see the flickering, small dips in power can cause early CFL failure. If you find that your bulbs aren’t lasting very long, have the power checked and bring in an electrical repair company similar to to fix it. Faulty wiring also affects the cost savings from a CFL in a big way because the bulb never quite gets to its operating range.
  • Line noise will also affect CFLs. For example, if you have a heavy duty motor (such as a refrigerator) on the same line as a CFL, the drop in line current when the motor starts can affect the life expectancy of the CFL. Line noise will also affect the cost savings you see from a CFL because the bulb isn’t operating properly.

Some readers have pointed out that CFLs are overrated. I’m not quite sure how to respond to this question other than to say that there isn’t any free lunch. Just about every solution we now have for fixing the planet’s carbon problem is flawed. Even if we were to all go back to burning candles, there would be problems. However, I did spend some time online looking for something a bit less hysterical and a little more scientific than something that says CFLs and other modern technologies are bad. You should embrace CFLs and other good for the planet technologies with open eyes. The best post I found on these issues is one entitled, “Directory:Compact Fluorescent Lighting (CFL) Downsides.” If someone else has a non-hysterical source of additional information, I’d be happy to address it in another post.

I’d welcome verifiable tips from other people. I verified each of these tips against three sources (including government sites when available). That doesn’t mean that every tip will work for you personally, but most people find that these tips work for them. Let me know about any additional thoughts you have about CFLs at

Consumerization of IT as it Relates to Developers

In my book, C# Design and Development, I discuss the need to consider the application environment in a number of places. For example, on page 106 you’ll find a discussion of the corporate environment on the requirements for application speed. A discussion on page 431 describes the need to achieve application goals while treading softly on the user’s environmental settings. Application environment can include a lot of different considerations. That’s the reason the ComputerWorld article entitled, “‘Consumerization of IT’ taking its toll on IT managers” struck a cord with me today. IT is now faced with a situation where users rely on personal devices more often than corporate-supplied devices, which is wreaking havoc in many ways.

The article will enlighten you about the woes that IT faces. What the article doesn’t describe are the woes that the developer faces. When an application developer creates a new application for the corporate environment or provides changes to an existing application, the testing process must consider the devices that the application will run on. When the developer works with a known set of corporate-supplied devices, the testing process is predictable. However, when the developer must also consider personal devices, the testing process is more like the environment for shrink-wrapped software, which means that the developer must now consider an open environment in which the user could rely on any device. In fact, developers must consider the following application design, development, and testing issues as a minimum due to consumerization.

  • Security: Early corporate applications didn’t come with much security at all. As government regulations, data breaches, and other issues have come to light, developers have added security to application, but not at the level of shrink-wrapped software and certainly not enough to ensure protection of corporate data.

  • Reliability: Every device that accesses an application has different characteristics. These characteristics determine how the device interacts with the application. Adding devices increases the number of potential interaction types and reduces overall application reliability due to issues with non-compliant devices. Obviously, testing can no longer have even a hope of finding every application interaction issue, so developer will need to create a robust application error handling mechanism with the organization.

  • Presentation: As device types increase, so do the presentation environments that the application must service. It isn’t just the fact that these devices will have different sized screens, but also the need to address audio and input characteristics of a wide range of devices. A developer must now consider how best to define an application interface so it works with the broadest range of devices possible.

  • Multiplatform Considerations: A development staff may begin designing an application to work on a particular platform, such as Windows, only to find that users also want the application to work on Android or the iOS. Even when the user sticks with desktop or tablet devices, the application may need to support Linux or OS X. In short, the development staff needs to consider multiple platforms when creating an application today. Unfortunately, Web-based applications aren’t always the best choice—leaving the development staff with some tough decisions to make.

There are other considerations to make, but you get the idea. Today’s development environment has become extremely complex due to consumerization. Unless your organization has firm policies about personal device usage in place and actually acts on those policies, you need to consider the idea that the user could access your application using just about any device on the market today. You have a number of ways to deal with this situation, including the following suggestions:

  • Create a list of tested configurations so that users know which devices are most likely to work with the application.
  • Make users part of the initial design process so that you hear about needed device support as early as possible.
  • Track new device releases because many users will get the latest gadget and expect it to work with your application.
  • Define a specific procedure for adding new devices to the application support list so that you don’t have to deal with user requests in a confused manner.
  • Keep an open mind because users will work with personal devices whether you support them or not.

This whole issue of consumerization could easily consume a chapter or more in a book. What have your experiences been with consumerization? Is the new application development environment becoming impossible to manage? Let me know your thoughts at