Default Isn’t Always Default: Reimagining Code Standards

The Critical Role of Defaults in Software Development: A Decade of Memories

Reflecting on the past years as software developers, we are struck by the critical role that defaults have played throughout our journey. These pre-set values or configurations or behaviors often called Defaults, often unnoticed, have consistently influenced the usability, security, and performance of the systems we’ve worked on. Let’s walk through some pivotal memories and lessons learned about defaults, grouped into key themes that have shaped our understanding and practices.

The Learning Curve of Technologies

Getting back to the release of Java 8. The introduction of parallel streams was groundbreaking. Eager to leverage this new feature, many of us soon discovered that the default thread pool it used was a double-edged sword. While beneficial for some operations, it caused significant performance degradation for others. This experience taught us the importance of scrutinizing new features and their defaults before widespread adoption.

Another significant lesson came from configuring the garbage collection algorithms in the JVM. Initially, it seemed convenient to stick with the default settings, but it quickly became apparent that this was not always optimal. Through trial and error, and much research, we learned how crucial it was to understand the nuances of each algorithm to ensure our applications ran smoothly and efficiently.

Handling Application Behavior and Performance

A critical turning point was the debate on application startup behavior. Should an application fail silently on misconfigurations, or should it refuse to start altogether? At IPSY, we adopted the philosophy that it was better for an application to fail the startup if it didn’t meet its minimum dependencies. This self-healing approach ensured reliability, as the scheduler would continuously attempt to meet the criteria, reducing the risk of hidden issues.

Routing rules presented their own set of challenges. As an example sometime ago we had a particularly tricky situation involving cascading rules that inadvertently hid the intended behavior. This overlap often led to unforeseen consequences. Through careful analysis of rule sets and rigorous unit testing, we learned to handle these scenarios more effectively, ensuring our rules did not conflict and behaved as expected.

Application configurations also held their fair share of pitfalls. Setting harmful defaults, such as database connection settings, could lead to unintended consequences during deployment. Defaults suitable for local setups can lead to your manager getting angry because you promoted the same configuration to production! Through careful consideration and adjustment, we learned to avoid costly mistakes and ensure our applications performed reliably across environments.

Service responsibilities often sparked lively discussions. For instance, when one service communicates with another, who should handle connection settings like timeouts? There was no universal answer; it depended on the scenario. Should Service A be responsible for releasing the connection, or should Service B ensure it’s closed after a certain period? These decisions required careful consideration of defaults.

At IPSY we work in a microservices ecosystem and we are always looking for opportunities to improve these responsibility patterns as much as possible.

Managing Resources and Infrastructure

Resource management, particularly logging systems, highlighted the dangers of assuming endless resources. At IPSY, one good example was the setup we have made on logs quotas to prevent applications from logging too much taking resources from other applications and to control the associated expense. We can have fine grained control over the application logs volume and mitigate unusual logging needs as they happen and trigger actionables afterwards.

Infrastructure defaults brought their own complexities. We could have an incident caused on Kubernetes if we don’t specify initial resources for our pods. The scheduler places pods on any available node, leading to crashes when resources are insufficient. Similarly, not setting maximum limits resulted in resource monopolization by single pods, disrupting the entire system. These experiences taught us the critical need for clear and precise default settings in infrastructure management.

Enhancing Development Efficiency

The introduction of templates revolutionized our workflows. Defaults in the form of templates for pull requests, application scaffolding, and documentation helped standardize our processes and improve efficiency. These templates saved us significant time and ensured consistency across our projects, highlighting the positive impact of well-thought-out defaults.

At IPSY we are always looking for new ways to build templates and guidelines so we can improve the communication and collaboration between colleagues. For instance, we have a lot of templates built on Confluence and Jira.

Finally, the power of abstractions at IPSY provided developers with building blocks to create applications quickly and with built-in quality. These abstractions, combined with industry best practices, allowed us to focus on specific tasks without getting bogged down by default settings. This balance between known configuration sets and flexibility was crucial for efficient and effective development.

At IPSY we are always leveraging the right balance of known configuration sets that just work out of the box versus the flexibility to tweak all the settings. On the other hand we rely on industry best practices and tools such as Kubernetes, Observability, Service mesh, Configuration management, etc, to make our applications agnostic of the underlying technologies and empower developers to focus on what matters the most.

For example we provide a framework to deploy our applications into different platforms such as EC2, Lambda, S3, Kubernetes with good combinations of settings but also adding capabilities to let it customize for advanced users.

Security and Best Practices

Security considerations emphasized the importance of changing third-party defaults. Exposing vulnerabilities, such as web server default pages revealing product versions or default usernames and passwords, posed significant risks. Implementing strict policies and enforcing best practices helped mitigate these threats, illustrating the critical role of security-conscious defaults.

Customer Experience and User Interfaces

Customer-facing issues revealed how defaults could impact user experience. Inconsistent user flows due to outdated links on troubleshooting pages created endless loops, frustrating customers. Ensuring user interfaces were updated and assets were appropriate for different devices became crucial to avoid such pitfalls, underscoring the need for thoughtful defaults in UX design.

Conclusion

It’s clear that defaults have played a pivotal role in shaping our practices and outcomes. From adopting new technologies and managing application behavior to handling resources and enhancing security, defaults have influenced every aspect of our work.

In conclusion, default plays a critical role, have many aspects and it is important to be aware of them in order to weight-in what is most important on some cases or what is the recommendation in some others; there is no golden rule above them all but a good combination of knowledge and context will make you choose the right path for your situation.