Our customer promise is Digital Hospitality. Nowhere is that more directly felt than in the way we develop our websites. Watch this to understand what we are talking about:
Our prime directive is to meet the needs of the client as best we can. Those needs change project-by-project, but what we pitch and sell are sites that are built to last, with re-usable, flexible components so that our codebases last much longer and can withstand much more change than those of our competitors.
Development Priorities
This is the loose hierarchy of what we try to do with our development work.
- Meet or exceed the design and functional requirements
- Match or better the budget
- Optimize future development, limit technical debt
- Learn new technologies and approaches
- Generate content for our content channels
Principles
Cantilever development is distinguished by an unusual level of "give-a-crap-itude". We care deeply about the quality and integrity of our work. The greatest badge of honor we can get is when we deliver code for a client’s own team to use, and they can successfully. If we can create systems that last, we are providing value beyond the initial functionality that other firms know how to hack together.
Behaviors
Some distinguishing aspects of our development workflow are:
- Commitment to Standards. Sites that Cantilever builds or works on should be constantly compared to our development standards. Sites we build should meet at least the “Default” level both at launch and throughout its lifespan. Sites that we adopt from other developers should be pushed toward the Default standards as they’re worked on over time.
- Accessibility. We should be thinking about accessibility throughout the design and development lifecycle and ensuring that our sites met our standards: Accessibility at Cantilever
- Documentation. Every project should have comprehensive documentation outlining all you need to know about the project and its functionality, plus a README that walks you through local installation.
- Continual QA. We do not rush to get “ready for QA”, sweeping bugs under the rug. We write features in isolated merge requests and test them individually, so that each step is building on a solid, trusted foundation. Testing duty is spread among the team according to the capabilities of each member.
- Obsession. For better or worse, we always try to find the optimal solution. We may decide to use a hack or two in the end, adhering to the development priorities, but we like to at least know what the best way forward is before we decide to go a different way.
Frontend Dev Orientation Training With Ty
Done when several new people were coming on to work on our stuff