Note: This is far from an exhaustive list, and will be updated occasionally to reflect that.
Design First
Always design first. Even if it is an agile project with an aggressive timeline, a clear understanding of what your solution will look like and the steps to get there will make the path easier to get to. Designing first is the opportunity to think through what you will be doing and recognize potential issues in advance. Often when design issues show up late they are dealt with as code flaws rather than design flaws, taking longer to correct and often leaving the design issue in the “fixed” result.
When I can recall the exact wording and attribution I will update this post…meanwhile, not defining an architecture is an architecture. Some refer to it as a Big Ball of Mud. I particularly like Gregor Hohpe’s many takes on this choice. Here is a link to an older-but-still-accurate blog post of his.
Developers need to Design, too
Your design can be as simple as stubbing out all of your classes before developing them. This way, issues that were missed during the design phase are more likely to be discovered earlier, before they become harder to fix.
Test-Driven Development is another approach to catch issues early on.
Insist on Design Review
Have a technical lead or peer review your design. The additional perspective is always helpful, either by validating that your approach is sound or questioning choices and reviewing options found by a fresh set of eyes.
Environment Variables
Environment variables should be maintained in the environment. Placing these variables in components where they must be updated between environments reduces the value of such variables and increases the chance of errors when migrating deployments between environments.
Balance Early Adoption with Out-of-Date
Going first in a presentation is brave. Being first to apply a new technology in an enterprise is always risky, and those risks must be seriously weighed beyond the “cool factor” of being an early adopter. Once you have committed to early adoption, mitigate risk with thorough testing and following any active communities taking the same journey.
Because of the frequent and rapid changes in technology, the familiar approach is not always the safest. Libraries, functions, features and patterns currently in use at your enterprise may be heading toward deprecation and retirement. With vendor products, especially cloud platforms, a newer, better approach could be available that is solid and well-tested (depending on the vendor, YMMV). Always check for newer alternatives before committing to a solution, and weigh the alternatives for fit both from a functional perspective and maintenance implications. And…
Don’t Trust, Verify
Vendor claims are written by the marketing team, not the development or support teams. If a vendor states that Product X provides feature Y, validate that it does and that it does it in a way that supports your design before committing to it.
DevOps
Yes, DevOps is a category unto itself, and it also needs to be considered during the design phase. Retrofitting DevOps practices is often difficult. For greenfield projects, prepare a detailed recommendation on the benefits of DevOps for the application and the steps necessary to implement and maintain. For enhancement projects, review the technology landscape for potential and recommend accordingly.
Test Automation Design
Not all applications are the same, so using the same tools and patterns for all applications won’t work. That isn’t to say they can’t be reused across applications. What is important is not to assume fit for purpose. At a minimum, review the current state of the are for the tools you are familiar with, who their competitors are, and then try things yourself before believing any hype. This review should be repeated regularly once the test stack is designed to maintain relevance.
© Scott S. Nelson