by Warren Gaebel
| Apr 02, 2012
I’ve lived and breathed website performance for the last few months, but sometimes I can get too focussed. Today’s article takes a step back to look at some of the other objectives of typical web-based projects. If you manage a development project or an ongoing operational project, you may find something useful in this article.The definitions below are not intended to be academically correct. The goal is rather to demonstrate the concepts as they apply to typical real-world situations. For a more academic treatment of these concepts, take a look at the references at the bottom.
Performance
Since we’ve been following the performance path in previous articles, let’s start there. Performance is important because users jump ship and search for alternate websites if they have to wait too long. Every tenth of a second bears its cost as more and more users leave. Revenues and profits go hand in hand with users, so poor performance easily results in foregone revenue.There are many performance measurements, but the one that really counts is the one the users have in mind. They are interested in the time from when they request something to the time they are once again able to interact with the application. This is called time to interactivity. There are many important measurements that should be monitored, but this one needs to be at the top of the list.
Scalability
If you’ve built a useful website, there’s a good chance you may see growth. However, if your website has not been created with growth in mind, your good fortune can turn into a major nightmare. Scalability is the feature built into a website that permits it to grow significantly with only minor alterations.Scalability should be on our minds at the very beginning of every web project because it is heavily influenced by the initial design. Making the website scalable later often requires major rewrites.
Maintainability
Because of constantly evolving standards, the dynamic nature of the Internet, and the need to adapt to the user’s changing demands, it is not reasonable to think of a website as finished. We may roll it out into a production environment, but we wisely know that this is just the beginning. There is more to come.There are things we can do during development to make the system more maintainable later. Internal documentation and code-readability pop into mind almost immediately, but modularity and self-descriptiveness have their impact, too. Unfortunately, many projects put these on the back burner without giving them any real thought. Very few projects actually pay more than lip-service to this objective.
Cost
Ah, yes, cost is always a consideration. Someone has to write the cheques, and we can be certain they will want those cheques to be as small as possible.With the system owner’s desire for lower costs and everyone else’s desire for more functionality and a slicker appearance, managers find themselves constantly engaged in a cost vs. benefit tug-of-war. It always comes down to convincing the investors that the benefits to be achieved will create an additional, acceptable return on investment. This is a key skill of the successful manager.Productivity within the development phase is an important consideration, but more than a few managers have found that you can’t rush creativity. There have been attempts over the years to create a well-defined development process that reduces our reliability on creativity and focuses on process instead. However, these techniques have widely varying levels of success and fade into history much sooner than we would like. In the author’s opinion, modularization, object-oriented design, and code reusability offer the most hope in today’s technical environment.
As always, it comes down to the investor getting the most bang for the buck in the long run. Sadly, too many people make decisions in the short run.
Minimal Resource Usage
Resources come in many forms. There is the human resource, the information resource, the capital resource, and on and on. There is one, however, that can dramatically impact all of the above objectives: the technical resources used by the system while it operates.Technical, operational resources include memory, disk space, CPU’s, network connections, operating systems, web servers, database management systems, and even the end-user’s computer. Your technical staff already know what happens when these resources are pushed to their limits, but the manager needs to understand the basic concepts and make sure these resources are provided.Senior technical staff also need to make sure that more junior developers are writing code that minimizes resource utilization. What is perfectly acceptable today may be tomorrow’s bottleneck, which can dramatically impact both performance and cost.
No resource should be treated as if it is unlimited. Develop your own best practices and design patterns. Require your developers to justify any deviation from them.
Usability
There are far more perplexed users out there than we care to admit. They have at their fingertips immense functionality that meets many of their day-to-day needs, but they’re not using it. Do you know why? It’s because they either don’t know they have it or they can’t figure out how to use it.We tend to think of these users as technically illiterate, but that’s not always so. This basic fact of life applies to the more savvy, too.With all their popups, images, animations, sounds, colours, functionality, links, buttons, and more, many web pages are so cluttered that they provide too much of a challenge to the average user, so the page is passed over in favor of something easier to use. Example: Most people still have a phone book sitting nearby even though there are countless websites that offer the same information. Esthetics and richness of content are important, but excesses are just plain confusing.
Our demographics are getting older every day. Even those who grew up in the Internet world eventually find it difficult to grasp newer technical concepts. Innovation is good in many respects, but leading-edge websites sometimes leave older people far behind.
I don’t hear much anymore about human factors, ergonomics, accessibility, ease-of-use, understandability, and simplicity of design. Maybe it’s just that I’m running in different circles these days, but from what I see at most websites, I don’t think so. Example: It takes a great effort to find a resting spot for my mouse on many web pages because of all the popups it generates when I move it. Onmouseover should be illegal!
Another usability issue is poor documentation. There’s nothing new here; I’ve heard people complaining about lack of system documentation since the 1980’s (perhaps earlier). Poor documentation leads to more support calls and lost customers. What seems obvious to your business experts and technical staff is not so obvious to your users.
Correctness
Can you imagine an online banking web app that tells you the wrong account balance? Or how about an e-mail client that files some of your incoming e-mail in the Trash folder? It is hard to imagine, isn’t it. But it has happened. Usually these mistakes are corrected quickly, but they do happen.There is nothing more embarrassing to a website than to generate incorrect results for one of its major features. Users are not likely to chuckle and think, “Isn’t that funny?” No, they are much more likely to phone the support line and listen to the busy signal (because everyone else is trying to phone in, too). Some consider it to be the straw that breaks the camel’s back. They walk away.In almost all cases, the investment in testing varies inversely with the error rate in the final product. There’s nothing new there. That axiom pops up in almost every manufacturing operation. Web applications are no different. Make sure your plans include a good testing strategy. Even more important, when the project falls behind schedule, don’t rob the testing budget to pay for shortfalls elsewhere.
Here’s an interesting definition of correctness: Correctness is the web application’s ability to make the users more productive. Thinking of correctness from that viewpoint is a real mindbender, but the more I think about it, the more I’m convinced that this is the best starting point.
Privacy & Confidentiality
When a website collects, stores, or uses personal information, the users expect privacy and confidentiality. Example: The mere fact that they visited the website sounds trivial, but many users expect even this to be confidential.Every website needs a privacy policy. Users need to be aware of its existence and need to have easy access to it before providing any personal information. The policy should be written in clear language that the user easily understands. Legal jargon should be avoided.The next step, of course, is to make sure the website behaves the way the privacy policy says it should. Example: If the policy statement says that personal information will not be collected unless it is required, every new or changed page must be reviewed to ensure that the collected data is a requirement. Privacy policies don’t implement themselves!
Security
Sadly, there are people out there who think it’s okay to deface your website, steal your data, or even delete your data. Most jurisdictions now make this illegal, but that’s really no comfort when you are the victim. A criminal conviction does not undo the damage.Controlling and auditing access is at the core of most security systems, but you also need to keep your software updated and be aware of newly-discovered vulnerabilities. Don’t leave yourself exposed.
Availability
Uptime is when your server is functioning normally and users are able to complete their transactions. Downtime is the opposite. Users will expect your server to be up and running every time they want to use it. Anything less will be a disappointment to them. They will even blame you when the problem is not your fault (e.g., Internet failure). That’s not fair, but it is reality.99% uptime may seem good, but it equates to almost a quarter of an hour of downtime per day. If that’s a website’s long-run average, the website is driving away customers. 99% is not as good as it sounds.Cloud-based monitoring is available at monitor.us. It’s easy to set up and use, and it keeps a close eye on your website’s availability. Every website should be using this free service.
Portability
Portability may not be an issue …today. If your long-term plans make no mention of changing your platform, portability may not even enter your mind.However, it always seems to be the unexpected that causes us the most grief. Following a few simple rules on an ongoing basis can pay off big time if you ever need to suddenly change platforms.Here are a few portability rules to point you in the right direction:
- Code to standards. Avoid deprecated techniques or anything that is likely to change in some future release.
- Avoid tools and techniques that have not yet proven themselves in the long term. Be leading edge, not bleeding edge.
- If you need something unique, create it or buy it, but make sure you get the source code, too.
- Do not write special code for non-compliant browsers. When this is not possible, modularize so all the browser-specific code is in one place.
Conclusion
Management is so under appreciated. Everyone makes demands, and few of them really care about other people’s demands. Management is expected to juggle all of that and to come up with solutions that keep everyone happy.In the midst of all this, managers must keep their objectives in mind. The above objectives are a good starting point for developing and operating web-based applications. If you’re new to managing technical projects, I hope it has helped you.
References
Evaluating Websites Using a Practical Quality Model by Zihou Zhou. Published 2009 by De Montfort Open University at dora.dmu.ac.uk/xmlui/bitstream/handle/2086/3422/ZihouZhou_Thesis-Final.pdf?sequence=1. Accessed 2012.03.28.Software quality attributes and trade-offs by Patrik Berander, Lars-Ola Damm, Jeanette Eriksson, Tony Gorschek, Kennet Henningsson, Per Jönsson, Simon Kågström, Drazen Milicic, Frans Mårtensson, Kari Rönkkö, Piotr Tomaszewski. Published June 2005 by Universitetet i Oslo at uio.no/studier/emner/matnat/ifi/INF5180/v10/undervisningsmateriale/reading-materials/p10/Software_quality_attributes.pdf. Accessed 2012.03.28.Software Quality Attributes and Architecture Tradeoffs by Mario R. Barbacci. Published 2003 by Carnegie Mellon University at ewh.ieee.org/r2/southern_nj/BarbacciOct03.pdf. Accessed 2012.03.28.
Chapter 3 – Design Guidelines for Application Performance by J.D. Meier, Srinath Vasireddy,. Published Ashish Babbar, Rico Mariani, and Alex Mackman. Published May 2004 by Microsoft at msdn.microsoft.com/en-us/library/ff647801.aspx. Accessed 2012.03.28.
Post Tagged with
