 |
I talk with a lot of people who are new in the industry. They’re usually either just out of school or recently graduated from a boot camp and transitioning into a new career. Throughout these conversations, I ask what excites them about software, what they want to learn next or their career goals. I’m always surprised when they mention something about “architecture” or becoming an “Architect.”
That sucks. The best way to become competent at architecture is to get deep in the weeds of programming, to build experience from the ground up.
I’m guessing the rush has something to do with the title. In software, we have job titles like “Software Engineer” and “Solutions Architect,”1 but our industry isn’t regulated by a third party unlike, traditional Engineers and Architects. We don’t need a certification to build software that can scale to support 10 million users worldwide.
The definition of software architecture is loose and, unfortunately, trends grandiose. I prefer to define architectural decisions in software simply and without any bells:
Decisions that are harder to change later than they are to make now.
This definition may seem trite, but it differs significantly from others, like
…the design decisions related to overall system structure and behavior.
…important decisions regarding the software that goes on to define its overall integrity.
These definitions are vague and subjective.
What does “fundamental” mean in a system? What qualifies as “important”? Who measures system integrity, and how?
Instead, focus on the impact of the decision. Not the business impact in this case, the effect on the team if you need to change the decision in the future.
With that framework in mind, it’s not just justified to spend time deliberating decisions; it’s the wisest thing to do. It also gives a good framework for deciding which decisions to spend the most time on.
Tabs vs. spaces or other code-style decisions? Probably not worth as much time because if you want to change them in the future, there are tools to help wrangle your codebase in a short period.
An identity provider? Definitely worth some deliberation. Changing this decision down the road is expensive regarding hard costs and team hours.
What about the bundler you use for your front-end application? Like Webpack vs. Vite vs. Parcel? Changing this decision later isn’t as significant as migrating to a new IDP. Still, a hard switching cost associated with changing your build process has a ripple effect impacting engineering, DevOps, and QA. I’d bucket this as an architectural decision, even if it’s minor.
Making these decisions requires2 knowing which questions to ask and identifying and articulating tradeoffs between decisions. These things are complicated to do well without being bitten a few times in implementing solutions yourself.
Don’t rush through the first few years of your career in software with the hopes of someday becoming an Architect just for the sake of it. You can practice good software architecture daily by investigating options and evaluating the tradeoffs between decisions. It will help your team and set you up for long-term success.
Rushing it won’t make you better at making hard decisions.
Footnotes
- Aspirational job titles in software are intentionally provocative. In 1968 NATO hosted a Science Committee, attempting to bring some consistency and rigor to the field. “The phrase ‘software engineering’ was deliberately chosen as being provocative, in implying the need for software manufacture to be based on the types of theoretical foundations and practical disciplines, that are traditional in the established branches of engineering.”
- These don’t even account for the even more challenging parts of being an Architect, like gaining consensus and owning accountability.