Fifteen years on in my career as a software engineer, I’ve seen a lot of process trends come, and almost as many go. At the macro level, we’ve seen Waterfall give way to RAD, and Agile carved down to Lean. Within those models, day-to-day practices like XP, TDD, and Scrum have shaped the way we approach our work at the tactical level.
Yet, at every step in this half-century long evolution, software was shipped. Teams finished their products, and there were successes as well as failures. Obviously, we were able to create functioning software before Agile. Not every Waterfall project failed. And not every team employing Kanban will succeed.
I’d never submit that process doesn’t matter, but I do think we sometimes miss the forest for the trees. Successful software projects, no matter the methodology with which they are built, all share one common theme: demonstrably strong technical design.
What is technical design? It’s time set aside to produce a technical blueprint that will guide an implementation. It’s injecting technical leadership, discipline and craftsmanship to a solution assembly. It’s being agnostic, and recognizing that not every problem looks like a nail. It’s building scale into the roadmap from day one, but without over-engineering. It’s the skillful application of experience, research and due diligence to the planning and execution of software development, and it goes well beyond defining an architecture.
It’s being agnostic, and recognizing that not every problem looks like a nail.
At Cantina, technical design is the backbone of our project-based work. Because we work with clients of different sizes, in different industries, some with and some without their own technical teams, flexibility when it comes to process is a must. And so while we take process very seriously, continually investing in and improving our own, reality dictates that technical design trumps process. We make this work for us by ensuring our engineering process always revolves around the pillars of strong technical design:
- Reference Architecture: The technical blueprint for any successful system implementation, a reference architecture lays the foundation for solution assembly, and serves as the proof that a technical design is valid.
- Adaptability: Predicting the future isn’t always possible, but selecting a design that can adapt to new requirements, new trends, and integrate with new technologies usually is, and it’s imperative to do so.
- Continuous Integration: CI provides system and project vitals through reporting what’s working, what isn’t, and what remains to be tested. Just like a surgeon wouldn’t operate without a battery of monitors on their patient, no project team should be developing without CI.
- Automation: From auto-scaling microservices to log file rotation, the key to an efficient and manageable system is automation. Identifying and embedding the right tools for automation during design eliminates excuses for forgoing them later.
These concepts are universally applicable, but they are only a framework for successful project execution. You still need vision, expertise and – yes, process – in order to deliver.
Do you have project that could benefit from enterprise-grade technical design? We’d love to talk to you about it. Get in touch.
