Are You Developing with Your Clients' Best Interests in Mind?
Software and Database engineering / architecture are difficult jobs. It's absolutely necessary to constantly learn more design patterns and to keep up with new developments so that one can implement best-practices. Frequently, web developers who are under-qualified for database architecture jobs end up in that role due to team size constraints or due to management not realizing that there is a need for experienced professionals. We end up with developers obsessing over every small performance hit while remaining somewhat oblivious to the big picture.
It's important to choose the right tools for the job. By observing basic practices such as reducing the number of queries per page, reducing the number of hits to the server per page, and intelligently caching our data we can keep performance quite high under a heavy load. Should the site become a massive success and performance starts to become an issue then that is a GREAT problem to have. We're building successful web applications and we're making some money. You can then start load balancing your web servers and using data storage patterns such as the "data warehouse" in order to kick your system's performance back up to the top.
The biggest issue that our clients come against tends to NOT be performance. Instead, it tends to be their ROI (return on investment). The less money that our clients spend developing (or paying us to develop) and paying for maintenance (adding features and generally just making changes to keep up with their business) the more income becomes profit. I submit to you that our primary goal should be to reduce the lifetime cost of the products that we're either building in house for a company or are turning over to clients.
We can reduce the lifetime cost of our products by:
- Using industry standards across all aspects of our development (from database architecture to variable naming conventions).
- Keeping our code small and easy to read (code should read like a sentence, variable names should be easy to understand).
- Using technologies that are established and have strong community support.
- Properly refactoring code when the need presents itself.
Your Choices Directly Influence Your Clients' Costs
It's important to remember that code you write is going to eventually enter into the hands of another developer. You may hand a product off to a client who then hires an internal development team. The experience level of that development team is an unknown. It's quite possible that they hired inexperienced developers in order to reduce their costs. The more difficult it is for these developers to understand and maintain your code the more likely the modifications that they make will be of the "hacked up" persuasion. This can violate the integrity of the project's conventions, reduce performance, and reduce readability and maintainability. This turns your product into a long-term challenge for the company involved. It's easy to blame your client for not having hired experienced development, but our profession is one that is easy for amateurs to enter into and is difficult for many business people to understand. Sometimes the budget for an experience developer simply does not exist. It is not our job to predict or judge the failings of our clients but to improve their experience with the product that you created for them.
By developing your code by standards and intentionally making sure that your code is self-documenting (easy enough to read that you don't need to generate as much documentation) you're reducing the lifetime cost of the software for your client. By using established technologies you're giving yourself and others access to free community support.
This is the philosophy that leads Big Name's web development decisions. Do you agree with us or does your organization subscribe to a different philosophy?