Application Development Best Practices and Guidelines

Review requirements and best practices for developing software applications at the University at Buffalo.

On this page

Overview

Purpose

The University at Buffalo depends on custom software to fulfill its mission. It is critical that these software systems are developed using industry best practices to ensure the University protects the information of the students, faculty, and staff that trust and rely on those systems. Application developers are expected to use the guidelines contained within to ensure that applications are secure, meet quality expectations, and are well-supported and maintained.

Scope

The guidelines within this document apply mostly as recommendations unless otherwise specified. However, it is strongly recommended that these guidelines be followed during the development of any software system. In general, the size, scope, and complexity of the application being developed as well as the category of data being accessed will dictate how strictly these guidelines should be followed.

Audience

The intended audience of these guidelines are any faculty, staff or students who are developing software systems for use within the University.

Security Standards

The security guidelines found in the separate security document Secure Application Development and Administration Standard are required for any system collecting, storing or displaying University data depending on the category of data stored/collected in the system.

Accessibility

All web applications and digital content must align with WCAG, ADA Title II and Section 508 compliance. For full details and requirements, refer to the official UB EIT policy and Accessibility Guidelines

Key Requirements

  • Keyboard & Screen Reader Compatibility: Ensure full keyboard operability and screen reader support (JAWS, NVDA).
  • Multimedia Accessibility: Provide captions, transcripts, and alt text for all media.
  • Color & Contrast: Maintain at least a 4.5:1 contrast ratio; don’t rely on color alone for information.
  • Focus Indicators: Apply clear focus states for interactive elements.
  • ARIA & HTML Landmarks: Use semantic HTML and ARIA roles for structured navigation.

Responsibilities

  • Developers must integrate accessibility checks throughout the development process, utilizing semantic markup (e.g., <main>, <header>, <footer>) and applying ARIA attributes only when necessary to enhance assistive technology compatibility. Automated tools such as axe DevTools, WAVE, and Siteimprove should be employed for early issue detection.
  • Testers are responsible for conducting manual accessibility reviews in conjunction with functional testing, documenting and tracking accessibility issues, and validating compatibility using multiple assistive technologies. Accessibility evaluations must be incorporated into continuous integration workflows to maintain compliance.
  • Designers must adhere to university branding and WCAG AA contrast standards, utilize accessible design libraries, and conduct comprehensive accessibility reviews throughout the design process.

Brand and Design

The University at Buffalo’s brand identity is a critical component of its reputation and recognition. All applications must comply with the University Brand Standards to ensure consistency and alignment with the university’s visual and messaging identity outlined on the official brand page.

Visual Identity

By adhering to the branding guidelines within the Branding Quick Guide, we ensure a consistent, professional, and engaging brand presence across all communication materials. All applications must follow the principles of clarity, authenticity, and accessibility. Utilize this guide and the UC website for the official elements and appropriate use of such (logo, color palette, typography, icons and graphics, spacing).

Digital Best Practices

Digital platforms are a primary touchpoint for the University at Buffalo’s audience. Adhering to digital standards ensures a seamless, accessible, and engaging user experience across all devices and platforms.

Web Design Principles

  • Responsive Design (Where Applicable): Applications should consider responsive design principles where appropriate to the scope and intended user base. While full cross-device responsiveness (desktop, tablet, and mobile) is encouraged for public-facing or multi-device platforms, internal tools or applications with a limited user base may prioritize desktop-first or device-specific implementations. Design decisions should be informed by user research, analytics, and stakeholder needs.
  • Layout and Grid Systems: Consistent use of layout structures and grid systems is essential to ensure visual harmony and usability across application screens. Developers and designers should adopt a unified grid framework (e.g., 8pt system, CSS Grid, or Flexbox layouts) to promote consistency, alignment, and scalability in the UI.
  • Call-to-Action (CTA) Styling: CTA elements (e.g., buttons, links) must follow standardized styles for color, shape, typography, and placement to guide user interaction effectively. CTAs should be prominently placed based on user flow and visual hierarchy, ensuring accessibility and alignment with brand design principles.

Design System Library (Recommended for Most Projects)

Teams are encouraged to leverage the UB Design System Library when possible to streamline development and maintain brand alignment. The library includes:

  • Reusable Components: Standardized UI elements such as buttons, dropdowns, modals, and forms that comply with UB’s branding and accessibility requirements.
  • Design Tokens: Centralized variables (e.g., colors, typography, spacing) to enforce consistency and simplify updates.
  • Accessibility Guidelines: Documentation supporting accessible implementation of components, including ARIA roles and keyboard navigation.
  • Templates and Layouts: Predefined page layouts and grid systems to ensure visual harmony and reduce design overhead.

Note: Teams should regularly review and align their implementations with evolving brand standards and accessibility best practices. Contact the EAS Web Team to request access to the UB Web UI Component Library repository.

Design Consistency (Recommended)

To promote a cohesive user experience across digital applications:

  • Use approved design templates where applicable.
  • Maintain consistent interface structures such as navigation menus, headers, and footers.

User-Centered Design (Recommended Practice)

Incorporating user feedback and research improves usability, especially for platforms with diverse audiences. As scope permits:

  • Conduct usability testing and user research with representative groups (students, faculty, staff).
  • Integrate insights to optimize workflows, content structure, and accessibility features.

Performance Optimization (Strongly Recommended for Mobile/Web Apps)

To enhance speed and efficiency:

  • Apply lazy loading for images and components.
  • Use efficient caching strategies and compress assets.
  • Optimize for lower-bandwidth environments where applicable.

Font and Typography Scaling (Recommended)

  • Use relative units (em, rem) for fonts and layout spacing to ensure scalability and readability across different screen sizes and device settings.

Breakpoints and Media Queries (As Needed)

  • Define CSS breakpoints to support transitions between screen sizes.
  • Use media queries to maintain layout integrity across devices.

Cross-Browser and Cross-Device Testing (Context-Sensitive)

  • Test interfaces on commonly used browsers and devices within your target audience.
  • Prioritize platforms most relevant to end-users (e.g., Chrome, Firefox, Safari, Edge).

Coding Standards

By adhering to a well-defined set of coding best practices, development teams can improve collaboration, reduce defects, and ensure the long-term maintainability and scalability of the application. Best practices must be flexible enough to accommodate evolving technologies and business requirements, but firm enough to guide developers toward best practices that result in high-quality, secure, and efficient software.

Error Handling and Logging:

  • Consistently handle exceptions and errors bolstered with detailed logs for critical operations. This makes troubleshooting and tracing issues easier.
  • Ensure error messages displayed to end users are descriptive and display enough information to help resolve the issue.
  • Be careful not to display information in error messages that could be used by an attacker to gain access to the system.

Consistency and Readability

  • Naming Conventions: Establish rules for naming variables, functions, classes, and files to improve readability and maintainability. Use descriptive names that convey purpose or functionality, and adhere to conventions like camel Case for variables, Pascal Case for classes, and snake case for file names, based on language norms.
  • Indentation and Spacing: Maintain consistent indentation (e.g., 2 or 4 spaces) and spacing around operators, braces, and parentheses. This enhances readability and helps developers quickly understand the code structure.
  • Commenting and Documentation: Write clear and concise self-documenting code and provide meaningful comments where necessary.  Comments might focus on complex or non-intuitive logic, complex formulas or intricate business logic.  Inline comments should describe the “why” behind decisions, not just the “what”.

Performance and Efficiency

  • Efficient Algorithms and Data Structures: Adhere to best practices for using appropriate algorithms and data structures to meet performance requirements, such as optimizing loops, reducing time complexity, and minimizing resource consumption.
  • Code Optimization: Avoid premature optimization but ensure that the code is written efficiently. Regularly profile and benchmark code to identify bottlenecks and optimize critical paths as needed.

Frameworks and Libraries

  • Adhere to the established frameworks, libraries, and standards specific to the platform and programming language you are using.
  • Use a linter to analyze sources code for bugs, stylistic errors and suspicious code. Use repository commit hooks and merge checks to automate and force successful linting before allowing new and changed code to be committed to the repository or merged into the finished product.
  • Leverage community-established solutions to ensure that the application remains aligned with industry best practices. (e.g., PEP 8 for Python, Google Java Style Guide for Java, etc.).

Maintainability and Scalability

  • Modularization and Reusability: Code should be organized into reusable modules, functions, and classes. This avoids duplication, promotes reusability, and ensures that components can be independently tested and maintained.  Remember the DRY (Do not Repeat Yourself) principle. It can be good practice to follow when writing reusable code.
  • Separation of Concerns or N-tier architecture: Ensure clear separation between different parts of the application, such as UI, business logic, and data access layers. This modular structure promotes maintainability, scalability, and ease of debugging.

Scaling and load management

  • Scale hardware (virtual/physical) appropriately. Plan for peak load times but consider the criticality of the application to avoid over-scaling when not warranted.
  • Perform load (performance and stress) testing prior to deployment of applications and major updates. This typically influences scaling when appropriate.
  • Monitor system and application load to prevent downtime, optimize performance, and identify potential security issues.

Change management practices/Version Control

  • Code should be stored in a code repository. UB has made GitHub Enterprise available to the campus. If your team has an interest in using GitHub, see UB GitHub.
  • Ensure credentials and secrets are not stored in code and not being saved to the code repository. Secrets required for authentication purposes should be stored in a secure manner.
  • If secrets have been previously included in code, there are free tools out there for cleaning git commit history of secrets exposed in code like BFG Repo Cleaner (https://github.com/rtyley/bfg-repo-cleaner) or git-filter-branch (https://git-scm.com/docs/git-filter-branch) . Clean repos can then be stored in the Cloud or on a remote server anywhere.
  • Manage source code with clear branch management strategies (e.g., GitFlow, trunk-based development).
  • Development teams should build and deploy production code from the repository and should avoid making code changes directly in production or manually pushing code to production.
  • Strive to maintain backward compatibility with previous versions of the application when implementing new features or making changes to APIs, especially in public-facing services.
  • Use semantic versioning (MAJOR.MINOR.PATCH) to clearly communicate changes in functionality and compatibility through version numbers.

Application Lifecycle Management

It is expected and required that once an application has been created, it will be supported and maintained by the developer or development team that created the application. This includes:

  • Regular patching and maintenance.
  • Monitoring for and resolving security vulnerabilities.
  • Monitoring for bugs and issues and correcting those issues.
  • Monitoring all 3rd party libraries, frameworks, and dependencies and patching/updating those components as needed.
  • Ensuring compatibility with new hardware or third-party tools.
  • Modifying features to meet changing business needs or regulatory requirements.
  • Decommissioning of features or the application itself when no longer needed.

Environment Strategy

When building and testing software applications, an application development team typically works within several environments to ensure that the application is developed efficiently and functions correctly. These environments help maintain a structured development process, from initial coding to production deployment.

Depending on the size and scale of the application and the size of the development team, all or some of the following types of environments may be necessary:

  • Development Environment: Focuses on coding and initial testing in isolation.
  • Test Environment: Used for unit and integration testing by QA teams.
  • Production Environment: Live, end-user-facing environment.
  • Integration Environment: Focuses on testing system and service integration.
  • UAT (User Acceptance Testing) Environment: Business validation by end-users or stakeholders.

Service Level Agreement (SLA)

Developers should define and share with the owners of the application a service level agreement that will define responsibilities of the support team, support hours, the process for incident reporting and for escalation of incidents, response times for incidents, etc.

Support Practices

Incident Management Process

All issues should follow a standardized incident management workflow:

  •  Issue Logging:
    • Users should report issues via a ticketing system (e.g., TeamDynamix).
    • Each ticket should include issue details, screenshots, and steps to reproduce.
  • Communication & Status Updates:
    • Regular updates to stakeholders during issue resolution.
    • In the event of a major outage for an application with wide usage an incident report should be generated with a communication plan to stakeholders.

Knowledge Management & Documentation

  • Maintain a Knowledge Base (KB) with common issues, resolutions, and FAQs.
  • Update troubleshooting guides regularly for support teams.
  • Conduct training sessions for new support staff.

Team Structure / Backup

The Team should have well defined roles, responsibilities, and structure to ensure accountability and streamlined issue resolution. A well-structured support team ensures effective issue resolution, minimal downtime, and seamless user experience.

Depending on the size, scale and scope of the application, support teams should ensure they have adequate backup support so there is coverage when team members are out of the office or leave the university.

Students should develop applications only with the guidance and supervision of a full-time staff member. Departments must also plan for student graduation by ensuring there is a clear strategy for transitioning development and support responsibilities to permanent staff.

Managing Technical Debt

  • Technical debt refers to suboptimal code, outdated dependencies, or design shortcuts taken during development to meet deadlines, which may lead to future maintenance challenges. If not managed, it can increase operational costs, decrease performance, and make future enhancements more difficult. Technical debt items should be identified, tracked, and resolved. Effective management of technical debt ensures long-term maintainability, performance, and scalability of an application.
  • Obsolete or no longer supported libraries or applications should be removed and/or decommissioned.

Adherence to Local Business Rules and Standards

Ensure that the software aligns with local business policies, technical best practices, and regulatory requirements. Development teams need to work closely with their customers and experts on any data being processed to ensure a very clear shared understanding of both the data and the business logic surrounding the use of that data otherwise inaccurate data could be presented or stored.

Business Rules Compliance

  • All applications must comply with UB specific business rules, workflows, and approval processes.
  • Business logic should be modular and reusable to ensure maintainability and scalability.
  • Application functionality should align with local regulatory requirements, including data retention, financial reporting, and industry standards.

Development Methodology

Application development teams should organize their work using some form of development methodology. These methodologies define how the team operates and how work is organized. This helps ensure structure, efficiency and collaboration throughout the development process.  This guidance does not indicate a methodology to use; we are simply recommending the implementation of a methodology such as Waterfall, Agile, Lean, Spiral, etc.

Quality Assurance/Testing

Best practices for application testing ensure that software meets quality, security, and performance requirements. By following structured methodologies and leveraging automation, development teams can reduce risks, improve performance, and enhance user satisfaction.

Testing Strategies

Below are examples of testing strategies. Based on the size, scope and complexity of the application being developed, teams may need to implement some or all of these strategies.                 

  • Unit Testing: Tests individual components or functions of the application to ensure they work as expected.
  • Integration Testing: Ensures that different modules or services work together correctly.
  • System Testing: Validates the entire system against requirements.
  • Regression Testing: Ensures new code changes do not negatively impact existing functionality.
  • User Acceptance Testing (UAT): Confirms that the application meets business needs and user expectations.
  • Performance Testing: Evaluates speed, scalability, and stability under various conditions.
  • Security Testing: Identifies vulnerabilities and ensures the application is secure against threats.

Testing Tools

Below are examples of testing tools that can help automate and streamline testing:

  • Dedicated Test Environment: A stable environment that closely resembles production for accurate testing.
  • Automated Testing Tools: e.g., Selenium, JUnit, TestNG, Cypress, etc., for efficiency.
  • Performance Testing Tools: e.g., Webload, JMeter, LoadRunner for scalability testing.
  • Security Testing Tools: e.g., OWASP ZAP, Burp Suite for penetration testing.

Testing Documentation and Reporting

Below are some examples of documentation and reporting strategies for testing:

  • Test Plans: Define objectives, scope, and strategy for testing.
  • Test Cases & Test Scripts: Detailed scenarios for manual or automated execution.
  • Defect Tracking: Use a tool for tracking defects to ensure that defects are addressed in an organized, systematic way.

Database

Implementing database best practices ensures data integrity, security, and performance, leading to a more reliable and scalable application.

Establishing Standards and Procedures

  • Develop and enforce standards for database usage to ensure consistency and effectiveness in the database environment.
  • Develop naming conventions.
  • Use data modeling standards.
  • Develop guidelines for database object creation.

Database Hosting

It’s recommended to collaborate with UBIT to set up centrally hosted databases. This enables development groups to leverage the existing infrastructure, security protocols, support and monitoring services.

Database Design

  • Design databases with normalization (1NF, 2NF, 3NF) to minimize redundancy and enforce data integrity using primary and foreign keys.
  • Use clear naming conventions, appropriate data types, and indexing strategies to optimize performance while balancing read/write operations.
  • Ensure scalability, enforce constraints for data consistency, implement role-based security, and document schema changes using version control.
  • Transaction Auditing.
  • Maintain an audit trail that logs all critical actions (create, update, delete) with timestamps, user identification, and before-and-after values for traceability.
  • Secure logs with access controls, immutable storage, and a defined retention policy to ensure compliance with regulations (e.g., GDPR, HIPAA, SOX).

SQL Optimization

  • Use indexing strategically to speed up queries while balancing write performance.
  • Optimize queries by selecting only necessary columns, filtering data early with WHERE clauses, and limiting result sets.
  • Avoid unnecessary subqueries, redundant calculations, and excessive JOINs; instead, use batch operations and caching where possible.
  • Analyze execution plans with EXPLAIN, keep database statistics updated, and consider partitioning large tables for better efficiency.
  • Minimize locking issues by keeping transactions short and using appropriate isolation levels.

Determining Storage Requirements

  • Data Size: Estimate initial storage needs based on database structure, data granularity, and multimedia content while accounting for metadata storage.
  • Growth Rates: Project storage growth by analyzing historical trends, data ingestion rates, user expansion, and seasonal fluctuations, ensuring scalability.
  • Archiving Strategy: Define data lifecycle policies and implement automated archiving and compression.

Database Monitoring

Monitoring provides visibility into how the database is performing.  Monitoring can be proactive to look for tuning opportunities to improve performance.  It can also be reactive to identify and troubleshoot database issues that may arise. If your database is not hosted centrally, where this monitoring would be included, the following should be considered as appropriate:

  • Performance monitoring.
  • Track locking and blocking issues.
  • Monitor replication and backups.
  • Set up alerts for critical issues (e.g. high CPU utilization).
  • Perform regular database health checks.

Disaster / Recovery Planning

Incident Response and Recovery

  • Incident Response Plan:
    • Define a process for identifying, reporting, and resolving security incidents.
  • Regular Security Assessments:
    • Perform penetration testing and vulnerability scans.
  •  Reporting Obligations:
    • Ensure you have a process to notify stakeholders and regulatory bodies in case of a breach.
  • Develop and maintain disaster recovery plans to ensure data integrity and availability in case of system failures:
    • Regular backups.
    • Testing recovery procedures.
    • Ensure that data can be restored quickly and accurately.

Continuous Integration (CI) / Continuous Deployment (CD)

CI/CD refers to a set of practices aimed at delivering code changes more frequently and reliably.

Continuous Integration (CI) is the practice of developers frequently (often several times a day) merging their code changes into a shared repository. Every change triggers an automated build and test process to ensure that:

  • The code integrates well with the existing codebase.
  • Bugs are detected early.
  • The application remains in a deployable state.

Continuous Delivery (CD) means that the application can be released to production at any time. Code changes pass through automated tests and build processes and are delivered to a staging or pre-production environment. Manual approval is usually required before deploying to production.

Contact Information

Related Information