Recently I had a conversation with my colleague about the performance and primary focus of the Dr.Explain development team. What should go first: the number of new features or the quality of architecture and of source code?
I agree that the number of new functions and features in a software product is very important for attracting new customers and improving customer loyalty, especially in the very beginning.
When you’re releasing a pilot version of your software, your main objective is to verify and test your business idea. Time to market is very important, so you may focus on the key functions and features of your product while not investing a lot of efforts in good architecture design and code quality.
If your idea works and if you are serious about developing your product in the forthcoming years, you’ll probably have to throw out your pilot version and rework it almost from scratch, this time paying attention to code quality and clearness, smart project structure, and scalable architecture.
Maintaining high quality of source code and of architecture design is a long-term investment. Surely at the beginning it will take a lot of time and efforts, but later it will give you many significant advantages over your competitors.
Our team has been developing, producing, and selling Dr.Explain for 7 years. (It’s a very sophisticated application for authoring help files and online manuals.) Now I’m happy that our team has always adhered to the standards of high quality code and good architecture. Here are some of the advantages that we’ve gained.
Higher Reliability of Our Software
Our software has to provide the highest level of reliability as it’s business oriented, namely meant for creating software documentation. For business users, even a rare bug may cost thousands of dollars due to a loss of important data, inaccuracy, or unexpected delay. While a bug in a video game or media player can disappoint the end user, a bug in a business application can potentially have much more serious consequences.
To ensure stability and reliability of our system and to predict any potential problems, we must have total control over our source code. We need to understand how every function and every operator works. We must have a clear vision of all interactions, data exchanges, and relations among all parts of our application. That would be impossible if our source code looked like a patchwork and was full of “dirty” hacks.
Higher Speed of Development Due to Code Reuse
Our properly organized and documented source code provides an excellent way to boost our team’s productivity as we can reuse common approaches, methods, and functions every time we need it. It has taken us years to iteratively build several problem-oriented libraries and SDKs consisting of carefully tested and organized functions and classes. Now we can often implement a very sophisticated functionality in a new module simply by using our ready-made and tested approaches. Quick and easy access to such common methods saves us many hours of designing, developing, and testing.
Quick Start for New Developers
We have about 1,600 files containing more than 500,000 lines of source code, plus various resource and configuration files. Poorly organized source code would become a real torture for a new developer joining our project. But when we’re hiring new team members, we can significantly shorten their learning curve by giving them logically organized, self-documenting, clear, and readable code. Otherwise, it would take years for a newcomer to understand how to change a single piece of text on some button.
Faster Code Review Process
To guarantee the reliability of Dr.Explain, our developers review all changes made in the source code by other team members. To evaluate the design and implementation of a certain function, a developer must understand what his colleague wanted to write and what he actually wrote. In other words, they must speak the same language, even the same dialect. All of them must follow the same coding standard, rules, and principles. All of them must care about code quality to effectively help each other to move forward. Otherwise, project development would grind to a halt due to conflicts, misunderstandings, and disputes.
One of the attributes of high-quality code is proper naming and structuring of all its elements: classes, functions, identifiers, and macros. Using a good naming convention enables developers, testers, and managers to work with source code effectively without the need for deep knowledge of its specification, design, or behavior. Team members can easily read their colleagues’ source code, understand its logic, and evaluate its consistency. There is no need to consult secondary documentation sources and therefore to maintain them.
Easiness of Adding New Features, Enhancements, or Extensions
A good software system architecture assumes that its parts are isolated from each other and use only clear and transparent connections and ways of communication. Our source code must clearly represent the architecture of the entire application and show the interactions among all its parts. If a developer understands what functionality a certain structure implements, he can easily modify or extend it without much affecting other parts of the project. All possible ways of affecting other parts are under control as all mechanisms of interaction are identified and designated. This minimizes the risk of introducing bugs into working code.
Easiness and Completeness of Testing
Again, if the application is designed in such a way that its modules are isolated from each other and use only clearly defined ways of interaction, then we know exactly which modules could be affected by certain changes in the source code. Therefore, we can run comprehensive tests on all critical modules and basic tests on other modules. Such tactics lets us minimize the time for integration testing without compromising quality.
Developers Love Their Product and Are Proud of It
The last but not the least benefit of high code quality is a great motivation for our team members. As we keep our project code clear, well-thought-out, documented, and almost bug-free, we know that we do our job perfectly. We respect our users, ourselves, and our work, and we are really proud of it. This is a very inspiring feeling that keeps us together and helps us to develop Dr.Explain and to move forward, to deliver greater value to our customers through our products.
Next time I’ll tell you about techniques that we use to maintain good architecture and to ensure high quality of code.