Category Archives: Best practices

When to Stop Support for old Browsers such as FireFox 2 and Internet Explorer 6

Let’s face it- old browsers are a pain in the rear. Browsers like FireFox 2 and Internet Explorer 6 do not behave like modern browsers. They do not render HTML in the same way and do not interpret JavaScript in the same way. You can, most of the time, fix these issues, but the process costs a lot in terms of testing, development, and time to market. I was just involved in a project were a client insistent on going through 12 browsers and paid hundreds of thousands of dollars for that line item.

The problem is that clients still use these browsers and expect to view your site properly with their legacy browsers. So, when do you stop supporting old browsers?

Continue reading

Forget About Software Configuration, Settings and Options – Choose the Right Defaults

Common pitfall “I am not sure what to do…. let’s make it configurable”

You hear this all the time in software companies – Some business analysts, developer or product manager trying to solve a dilemma in software development by pushing the decision to the end user side. “Let’s make it configurable” seems like a get-out-of-jail free card if you can’t make you mind about colors, screen layout and many other hard choices we have to make many time when designing our software.

People think they want free choice, while in fact they want the right choice.

It is a common mistake to think that making some aspect of your application configurable is necessarily a good thing. Software users rarely go into configuration and edit the software options to fit their needs. Users expect the software to work “by default” / “out of the box” / “no hustle”. Continue reading

Effective Development Environments – Development, Test, Staging/Pre-prod and Production Environments.

The following happens in many software projects –
At start, it seems you only need one environment for your web application, well, at most two:
One development environment (AKA your PC) and one server.

But as time pass, you find you need additional environments:
The clients might want their own testing environment, sometimes you need to have a pre-production environment or a staging environment, so business managers can approve the ongoing content as well as look & feel.

Do you really need these environments? What are these environment good for?

Here is a short description of some of the more popular environments and their purpose.
Continue reading

10 things every software architect should consider (AKA – 10 key architectural concepts)

After a session I gave about Scalability in Wellington NZ, one of developers asked me what are the things software architect should consider. I have gathered and compiled this list:

1. Security

Application security encompasses measures taken throughout the application’s life-cycle to prevent exceptions in the security policy of an application or the underlying system (vulnerabilities) through flaws in the design, development, deployment, upgradation, or maintenance of the application. [1]

2. Reliability / Consistency

Data consistency summarizes the validity, accuracy, usability and integrity of related data between applications and across the IT enterprise. This ensures that each user observes a consistent view of the data, including visible changes made by the user’s own transactions and transactions of other users or processes. Data Consistency problems may arise at any time but are frequently introduced during or following recovery situations when backup copies of the data are used in place of the original data. [2]

3. Scalability

Scalability is a desirable property of a system, a network, or a process, which indicates its ability to either handle growing amounts of work in a graceful manner, or to be readily enlarged. [3]

4. High Availability

High availability is a system design protocol and associated implementation that ensures a certain absolute degree of operational continuity during a given measurement period.

Availability refers to the ability of the user community to access the system, whether to submit new work, update or alter existing work, or collect the results of previous work. If a user cannot access the system, it is said to be unavailable. Generally, the term downtime is used to refer to periods when a system is unavailable. [4]

5. Interoperability / integration

Interoperability is a property referring to the ability of diverse systems and organizations to work together (inter-operate). With respect to software, the term interoperability is used to describe the capability of different programs to exchange data via a common set of exchange formats, to read and write the same file formats, and to use the same protocols. (The ability to execute the same binary code on different processor platforms is ‘not’ contemplated by the definition of interoperability.) The lack of interoperability can be a consequence of a lack of attention to standardization during the design of a program. Indeed, interoperability is not taken for granted in the non-standards-based portion of the computing world. [5]

6. Maintainability

In software engineering, the ease with which a software product can be modified in order to:

* correct defects

* meet new requirements

* make future maintenance easier, or

* cope with a changed environment;

[6]

7. Recovery / DR

Disaster recovery planning is a subset of a larger process known as business continuity planning and should include planning for resumption of applications, data, hardware, communications (such as networking) and other IT infrastructure. A business continuity plan (BCP) includes planning for non-IT related aspects such as key personnel, facilities, crisis communication and reputation protection, and should refer to the disaster recovery plan (DRP) for IT related infrastructure recovery / continuity. [7]

8. Performance

Determine how fast some aspect of a system performs under a particular workload. It can also serve to validate and verify other quality attributes of the system, such as scalability, reliability and resource usage. Performance testing is a subset of Performance engineering, an emerging computer science practice which strives to build performance into the design and architecture of a system, prior to the onset of actual coding effort. [8]

9. Standards/ Compliance

Software standard essentially is certain agreed to terms, concepts and techniques by software creators so that many different software can understand each other.

For instance, HTML, TCP/IP, SMTP, POP and FTP are software standards that basically all software designers must adhere to if the software decides to interface with these standards. For instance in order for a email to be read from Yahoo! Mail that is sent from a Microsoft Outlook software application and vice versa, the Microsoft Outlook needs to send the email using for instance the SMTP (Simple Mail Transfer Protocol) protocol (standard) and Yahoo! Mail receives it also through SMTP reader and displays the email. Without a standardized technique to send an email from Outlook to Yahoo! Mail, they can’t be able to accurately display emails sent between the two entities. Specifically, all emails essentially have “from,” “to,” “subject,” and “message” fields and those are the standard in which all emails should be designed and handled. [9]

10. User experience

A newly added member – User experience design is a subset of the field of experience design which pertains to the creation of the architecture and interaction models which impact a user’s perception of a device or system. The scope of the field is directed at affecting “all aspects of the user’s interaction with the product: how it is perceived, learned, and used. [10]

Seems about right… What do you think?