Desirable Characteristics of a Design

A high-quality design has several general characteristics. If you could achieve all these goals, your design would be very good indeed. Some goals contradict other goals, but that’s the challenge of design—creating a good set of tradeoffs from competing objectives.

Here’s a list of internal design characteristics:

Minimal complexity The primary goal of design should be to minimize complexity for all the reasons just described. Avoid making “clever” designs. Clever designs are usually hard to understand. Instead make “simple” and “easy-to-understand” designs. If your design doesn’t let you safely ignore most other parts of the program when you’re immersed in one specific part, the design isn’t doing its job.

Ease of maintenance Ease of maintenance means designing for the maintenance programmer. Continually imagine the questions a maintenance programmer would ask about the code you’re writing. Think of the maintenance programmer as your audience, and then design the system to be self-explanatory.

Loose coupling Loose coupling means designing so that you hold connections among different parts of a program to a minimum. Use the principles of good abstractions in class interfaces, encapsulation, and information hiding to design classes with as few interconnections as possible. Minimal connectedness minimizes work during integration, testing, and maintenance.

Extensibility Extensibility means that you can enhance a system without causing violence to the underlying structure. You can change a piece of a system without affecting other pieces. The most likely changes cause the system the least trauma.

Reusability Reusability means designing the system so that you can reuse pieces of it in other systems.

High fan-in High fan-in refers to having a high number of classes that use a given class. High fan-in implies that a system has been designed to make good use of utility classes at the lower levels in the system.

Low-to-medium fan-out Low-to-medium fan-out means having a given class use a low-to-medium number of other classes. High fan-out (more than about seven) indicates that a class uses a large number of other classes and may therefore be overly complex. Researchers have found that the principle of low fan-out is beneficial whether you’re considering the number of routines called from within a routine or from within a class.

Portability Portability means designing the system so that you can easily move it to another environment.

Leanness Leanness means designing the system so that it has no extra parts. A book is finished not when nothing more can be added but when nothing more can be taken away. In software, this is especially true because extra code has to be developed, reviewed, tested, and considered when the other code is modified. Future versions of the software must remain backward-compatible with the extra code. The fatal question is “It’s easy, so what will we hurt by putting it in?”

Stratification Stratification means trying to keep the levels of decomposition stratified so that you can view the system at any single level and get a consistent view. Design the system so that you can view it at one level without dipping into other levels.

For example, if you’re writing a modern system that has to use a lot of older, poorly designed code, write a layer of the new system that’s responsible for interfacing with the old code. Design the layer so that it hides the poor quality of the old code, presenting a consistent set of services to the newer layers. Then have the rest of the system use those classes rather than the old code. The beneficial effects of stratified design in such a case are (1) it compartmentalizes the messiness of the bad code and (2) if you’re ever allowed to jettison the old code or refactor it, you won’t need to modify any new code except the interface layer.

Posted in Design & Programming

Major Development Practices Checklist

The following checklist summarizes the specific practices you should consciously decide to include or exclude during development.

Coding

• Have you defined how much design will be done up front and how much will be done at the keyboard, while the code is being written?

• Have you defined coding conventions for names, comments, and layout?

• Have you defined specific coding practices that are implied by the architecture, such as how error conditions will be handled, how security will be addressed, what conventions will be used for class interfaces, what standards will apply to reused code, how much to consider performance while coding, and so on?

• Have you identified your location on the technology wave and adjusted your approach to match? If necessary, have you identified how you will program into the language rather than being limited by programming in it?

Teamwork

• Have you defined an integration procedure—that is, have you defined the specific steps a programmer must go through before checking code into the master sources?

• Will programmers program in pairs, or individually, or some combination of the two?

Quality Assurance

• Will programmers write test cases for their code before writing the code itself?

• Will programmers write unit tests for their code regardless of whether they write them first or last?

• Will programmers step through their code in the debugger before they check it in?

• Will programmers integration-test their code before they check it in?

• Will programmers review or inspect each other’s code?

Tools

• Have you selected a revision control tool?

• Have you selected a language and language version or compiler version?

• Have you selected a framework such as J2EE or Microsoft .NET or explicitly decided not to use a framework?

• Have you decided whether to allow use of nonstandard language features?

• Have you identified and acquired other tools you’ll be using—editor, refactoring tool, debugger, test framework, syntax checker, and so on?

Posted in Design & Programming

Defensive Driving in Development

Do you have a problem on how to protect yourself from the cold, cruel world of invalid data, events that can “never” happen, and other programmers’ mistakes. Try being defensive. Be a defensive programmer by defensive programming.

In defensive programming, the main idea is that if a routine is passed bad data, it won’t be hurt, even if the bad data is another routine’s fault. More generally, it’s the recognition that programs will have problems and modifications, and that a smart programmer will develop code accordingly.

The idea is based on defensive driving. In defensive driving, you adopt the mind-set that you’re never sure what the other drivers are going to do. That way, you make sure that if they do something dangerous you won’t be hurt. You take responsibility for protecting yourself even when it might be the other driver’s fault.

Happy Driving!

Posted in Design & Programming

Do’s and Dont’s in Optimization

There are certain rules that you have to follow in optimizing your site for the search engine rankings.

The Do’s

• Create a web site that contains meta tags, content, graphics, and keywords that help improve your site ranking.
• Use keywords liberally on your site, so long as they are used in the correct context of your site topic and content.
• Include reciprocal links to your site from others as long as those links are legitimate and relevant.
• Encourage web site traffic through many venues, including keyword advertising, reciprocal links, and marketing campaigns.
• Submit your web site to search engines manually, rather than waiting for them to pick up your site in the natural course of cataloging web sites.

The Dont’s

• Trick search engines by imbedding hidden keywords in your web site. This is a practice that will very likely get you banned by most search engines.
• Artificially generate links to your site from unrelated sites for the purpose of increasing your ranking based on link analysis. Most search engines have a built-in mechanism that will detect this type of deceptive practice.
• Artificially generate traffic to your web site so that it appears more popular than it is. Again,there are safeguards in place to prevent this from happening, and if you trip those safeguards,you could end up on the banned list for many search engines.
• Force your web site to appear in search engine rankings by submitting the site repeatedly for inclusion in the rankings. A good general rule of thumb is that you should submit your site once and then wait at least six weeks before submitting it again. Submitting it repeatedly will, again, only lead to something nasty like being banned from the search engine.
• Expect search engines to automatically rank you at the top of your topic, category, or keyword as soon as the site is picked up. It could take a little time to build the status that you need to reach a high search engine ranking. Remember, SEO is a process.

Posted in SEO / SEM

Page Ranking - The Holy Grail

As the adventures of Thomas of Hookton on the Quest for the Holy Grail. We can compare the adventures of Search Engine Optimizers on their quest for the Page Ranking of their pages in the Top results of Search Engines unto the Holy Grail. That is the very reason of their existence, and until they achieve that and remain there then their quest is not finished. Come to think of it, it really will never be finished. Only a chosen few really get that top spot and it takes a lot to accomplish that feat.

Page ranking is a very precise science. And it differs from search engine to search engine. To create the best possible SEO for your site, it’s necessary to understand how these page rankings are made for the search engines you plan to target. And ranking factors such as Location, Frequency, Links, and Click-throughs can then be taken into consideration and used to your advantage when it’s time to create, change, or update the web site that you want to optimize.

Posted in SEO / SEM

Spiders, Crawlers, and Robots - One of a Kind

Would you imagine that a toy, which is a specialty in Japan, is related to an insect that has bitten Peter Parker. Well, Domo Arigato Mr. Roboto, that is the case in the world wide web.

If you’ve spent any time on the Internet, you may have heard a little about spiders, crawlers, and
robots. These little creatures are programs that literally crawl around the Web, cataloging data so that it can be searched. In the most basic sense all three programs — crawlers, spiders, and robots — are essentially the same. They all “collect” information about each and every web URL.

This information is then cataloged according to the URL on which they’re located and are stored in
a database. Then, when a user uses a search engine to locate something on the Web, the references in the database are searched and the search results are returned.

Posted in SEO / SEM

Gas, Diesel, Search - The Evolution of the Engine

Everytime I pass through a gasoline station the gasoline boys’ first words are always “Premium or Unleaded”. That was everytime I used a sedan, then one day I borrowed my father’s AUV, an ISUZU Crosswind, and was expecting the same words form the gas boy, to my surprise he just asked me if it would be FULL TANK. I got back to my senses and remembered that I’m using a diesel engine automobile which only had one choice which is diesel. Now we have a third type of Engine, and it has more options than all the previous engines combined but it doesn’t run on fuel rather it runs on data. That is the Search Engine. What? said a jeepney driver. Come again. Can you enlighten me on this one. Okay, I’ll try.

Search engines are sophisticated programs, many of which allow you to search all manner of
files and documents using the same words and phrases you would use in everyday conversations.

On the back end, a search engine is a piece of software that uses applications
to collect information about web pages. The information collected is usually key words or
phrases that are possible indicators of what is contained on the web page as a whole, the URL of
the page, the code that makes up the page, and links into and out of the page. That information
is then indexed and stored in a database.

On the front end, the software has a user interface where users enter a search term — a word or
phrase — in an attempt to find specific information. When the user clicks a search button, an
algorithm then examines the information stored in the back-end database and retrieves links to
web pages that appear to match the search term the user entered.

Understood?

Duh!

Posted in SEO / SEM

7 Habits of Highly Effective Websites

Great Websites has some or all of the following habits or might I say qualities:

• It conforms to the way users interact with the Web, but focuses on the activity instead of a specific audience.

• It has only those features that are absolutely necessary for users to complete the activity the application is meant to support.

• It supports the user’s mental model of what it does.

• It helps users get started quickly so they can become intermediate users as soon as possible.

• It makes it easy to recover from mistakes and difficult to make them in the first place.

• It has uniformly designed interface elements, but leverages irregularity to create meaning and importance.

• It reduces clutter to a minimum.

Posted in Design & Usability

Three Categories in Software Metrics

Software metrics can be classified into three categories: product metrics, process metrics, and project metrics. Product metrics describe the characteristics of the product such as size, complexity, design features, performance, and quality level. Process metrics can be used to improve software development and maintenance. Examples include the effectiveness of defect removal during development, the pattern of testing defect arrival, and the response time of the fix process. Project metrics describe the project characteristics and execution. Examples include the number of software developers, the staffing pattern over the life cycle of the software, cost, schedule, and productivity. Some metrics belong to multiple categories. For example, the in-process quality metrics of a project are both process metrics and project metrics.

Posted in Software Metrics

Measuring Customer Satisfaction in Software

In software, the narrowest sense of product quality is commonly recognized as lack of “bugs” in the product. It is also the most basic meaning of conformance to requirements, because if the software contains too many functional defects, the basic requirement of providing the desired function is not met. This definition is usually expressed in two ways: defect rate (e.g., number of defects per million lines of source code, per function point, or other unit) and reliability (e.g., number of failures per n hours of operation, mean time to failure, or the probability of failure-free operation in a specified time). Customer satisfaction is usually measured by percent satisfied or nonsatisfied (neutral and dissatisfied) from customer satisfaction surveys. To reduce bias, techniques such as blind surveys (the interviewer does not know the customer and the customer does not know the company the interviewer represents) are usually used. In addition to overall customer satisfaction with the software product, satisfaction toward specific attributes is also gauged. For instance, IBM monitors satisfaction with its software products in levels of CUPRIMDSO (capability [functionality], usability, performance, reliability, installability, maintainability, documentation/information, service, and overall). Hewlett-Packard focuses on FURPS (functionality, usability, reliability, performance, and serviceability). Other companies use similar dimensions of software customer satisfaction. Juran calls such attributes quality parameters, or parameters for fitness for use.

Posted in Software Metrics