Standardization vs customization: Finding the perfect combination.

In a development environment, it is important to know the balance between standardization and customization. It is an internal struggle between developers who want to standardize everything and account managers who want to customize everything. Each approach has its pros and cons. Let us examine this in greater detail.

Standardization in development
In the purest sense, standardization is the ability to use processes and tools that allow a project to be maintained in the most efficient way. If you build to standards, it tends to allow for greater scalability. It can also increase your development efficiency. If all of your team uses the same tools and coding practices, you can have multiple people on your team be able to work on the same projects with minimal disruption to the workflow. To the contrary, if you have “rogue developers” on your staff who use their own tools and specific coding practices, you become reliant on them because it takes others a much longer time to manage their projects.

The solution to these issues is to get everyone working in the same set of tools, libraries, and code bases. You can also automate process in deployment. Our internal solution architects have been instrumental in taking us to that next level. Use of coding management/depoyment tools like git, chef and vagrant can make things more smooth as well.

The goal of any successful project is to deliver high quality work on time to the client. A secondary goal is to make sure that with every project, your team is evolving and getting smarter. Learning from the mistakes on each project is integral in success. If you consistently make the same mistakes without analyzing those mistakes and correcting those deficiencies, you can not move forward.

Standardization in development relates to this as well. As much as possible, every project should have at least 50% recycled or recyclable code. This is a number that I personally believe, different managers can set their own requirements. If you can maintain a good set of standardized code, your profit margin will soar. Another important aspect of this is that it makes parts of your projects portable. Developing code in isolation mode is the next phase of development evolution. If you build your applications to stand alone, they can more easily be reused.

Customization in development
I view customization as implementing client specific branding, functionality and user experience. Other people may argue for other items to be added to this but at a high level, everything can fit into those categories. On the account management side, typically, this is all that matters. As I have done this for a while, I know this is usually what initially drives relationships in the short term. Long term though, is another story.

In the one-off environment (aka highly customized, non-reusable, lower scalability projects), applications have all the bells and whistles that clients want to see. Keep in mind that for the most part, maintenance cycles are longer and more complex on applications with a highly custom presentation layer.

The Balance
This is where collaboration between each of your teams is key. During discovery, when you are identifying the solutions to client problems, you should also decide which direction the project will go. You must be on board at all levels if you decide to be higher on the standardization side (greater scalability, portability, and less maintenance time) or on the customization side(greater control of design, more cost to maintain, not as scalable). If you can come to a consensus as a team to how each project should be developed, with each project you can get more efficient in processes and close that gap.

Working together is important to developing/managing a project effectively. The development team should have a leader that can educate account services as to how each of these processes work and what each change will mean to the end goal. The account services team should have a leader that can actively convey requests to the dev team before they are requested from the client. To be able to anticipate those questions is important to guide development in order to increase the efficiency and quality of the deliverables.