The difference between a professional grade application and an amateur attempt often depends on how much the customer is prepared to spend and the skill of the development team implementing the solution.  Applications, web or otherwise have specific quality criteria that should be considered as part of the requirements document.

Amateur application

Production grade application

Logging goes to standard out (the console).

Logging goes to files which are limited in size and rotated so disk never fills.

Debug logging is always on.

Information log messages rapidly fill the logs for activities that happen all the time, and contain mostly developer debug information.

Debug logging is switched off, but can be enabled without a restart to solve critical problems.  Information messages are rare and not related to normal user activity so logs do not overflow with content.

It is impossible to use the application in a load balanced environment

The application can be used in a load balanced environment without software redesign

A fixed deployment domain or IP address is assumed, so if the site is deployed elsewhere, it won't work

The site is deployment domain agnostic

Every time data is needed, the application opens a new connection to the database, does its work, and closes the connection afterwards.

The application uses a connection pool to re-use existing database connections, for performance.  Connections are never closed until the application shuts down.

SQL stored procedures and views are the mainstay of the application so a specific database provider is mandated.

The application is database agnostic.  There are few or no SQL stored procedures and views so porting to other databases is easily achieved.

Access to the database is through direct JDBC calls and specific data type conversion, so a specific database provider is mandated.

Access to the database is abstracted through use of the Hibernate persistence layer.  Porting to other databases is easily achieved.

The application needs to be rebuilt and restarted to modify configuration.

The application will automatically update configuration without restart.

Fatal unexpected errors (such as being unable to connect to a database) result in data corruption and unknown behavior.  System administrator alerts (if any) give no clue about what needs to be done to fix the problem.

Fatal, unexpected errors are safely handled and system administrator alerts are raised that give enough detail for something to be done.

If the site goes down, nobody knows until the telephone starts ringing from angry customers.

If the site goes down, administrators know immediately, switch over to a backup system (if  the customer bought one), and fix the problem before anyone finds out.

The application only works beautifully when nothing goes wrong.

Both sunny and rainy day processing is covered.

If something goes wrong, there is no way to tell what caused it.

Everything important that happens in the application is kept in an audit log for when something goes wrong

Data from external parties and systems for the same company are trusted.

Data is mistrusted and validated throughout the application.

The application and database are randomly or never backed up.  If the application is backed up, the files are stored on the same server.

The application and database are backed up incrementally daily and fully weekly.  Backups are stored off-site.

The application runs only on Windows XP, referencing windows operating system folders, with hard coded Windows-specific folder back-slash characters.  There are also native windows DLL libraries used.

The application runs on a Linux platform but could easily be switched within a few hours to run on a Windows platform.  It has platform independence so the customer is not locked in to a particular operating system.

Scheduled batch jobs are executed using CRON jobs with no visibility of what errors occurred or when they last ran successfully.

Scheduled batch jobs are executed using an industry standard scheduler such as Quartz that is hooked into the web server.

Interfaces for external parties are complex and change regularly.

Interfaces are published, reviewed and rarely need to change.  They are also simple to access.

Business logic is defined in many places; java classes in different packages, JSPs, database stored procedures, Hibernate mappings, and scripts.  The information is so spread that it would be impossible to expose the business logic as a web service in future.

Business logic is defined in one place; java code.  A few selected java packages could easily be exposed as a web service in future because they encapsulate the business model and business rules.   The code for rendering a user interface is clearly separated from the code to solve the business problem.

A minor change to configuration requires delivery of a new executable from the developers.

Minor changes to configuration will update the application without a restart.

The application is hosted at someone's home or partly on a desktop PC in the office which could be unwittingly switched off at any time.

The application is hosted by a large internet company with a bullet proof Service Level Agreement.

Note that these items apply to web applications as well as applications without a user interface.

blog comments powered by Disqus