Software engineering can’t be reduced to a set of rules. Rather, it’s about understanding the problems we’re trying to solve, and making trade-offs among competing priorities. It’s nuanced work that requires experience and lots of clear communication.
That said, there are some things we think are true across the board — some principles that apply broadly to all of the decisions we make. Here we lay out 10 principles that we encourage our software architects to embody and aspire to, not because it is easy, but because it is hard (a la JFK’s 1962 speech about going to the moon), and not because they are rules but because they guide our software toward more success down the road.
So, to the principles:
- Speak for Trust: This is not surprising if you’ve been around Salesforce at all. Trust is our number one value. When making decisions, we often think about delivering new features to our customers quickly, which is important! But we also need voices pushing for building lasting trust with those customers. That’s one important consideration for our senior individual contributors (ICs) like architects — to think about building software the right way, from the outset, even in the face of product deadlines.
- Technology Serves Customers: There are usually many layers between us and customers, and while sometimes necessary at our scale, it has downsides. Figuring out what’s going on with real customers when they use our software can feel like a game of telephone. We ask our architects to be aware of customer pain and frustration, even through all of these layers.
- Champion Long-term Value: The software architect is sometimes the only one in the room with the knowledge of the consequences our actions might have in 5 or 10 years. Lean into that! Avoid getting caught up in the pressure to ship something for the short term and instead think about the long term impact of decisions being made right now.
- Complexity is Debt: Our systems are complicated (duh), even more so on the inside than from the outside. Treat every bit of complexity added to our system as highly suspect.
- Make Architecture An Equal Partner: Too often, individual contributors (ICs) think they’re not really allowed in the room when important decisions are being made, instead leaving that to management and product. We’re here to tell you that this is wrong and unhelpful; as we’ve laid out in the previous few principles, architects bring a really unique perspective here: thinking long term and factoring in technical ideas. Work to make your presence known.
- Communicate the “Why”: e.g. write it down! Software tends to last a lot longer than you think it will. Once you realize that a large part of successful software engineering is actually more like archaeology, you’ll be more inclined to leave better records of your thinking for posterity. Your future self, not to mention the rest of the team, will thank you. (Listen to more on this topic in our podcast episode, “Why Writing Matters for Engineers.”)
- Overcome Silos: Big companies don’t always have the right incentive structures for building shared value. But it’s the architect’s job to push back against this. That often involves trading in favor of global good rather than what’s locally optimal, and doing the work to build relationships and reuse across organizational silos.
- Design Still Matters: Sure, modern software delivery is agile. But that’s not an excuse for skipping planning and design! You still need to answer the major questions, and lay out the theory of a system. If you constantly wobble the underlying architecture of a system, you get an emergent pile of mismatched metaphors, partially implemented abstractions, and half baked solutions. Don’t spend months coding to save hours of planning.
- Everything Evolves: Building systems isn’t just about envisioning perfection. You have to move from here to there, and that’s often the most difficult, awkward part of any project. Don’t just think about end states, think about decomposability, flexibility, staging, and paths from one place to another.
- Don’t Be a Jerk: Human understanding keeps things running smoothly in software engineering. If nobody likes working with you, everything is going to be harder. The “human” side of software engineering is just as important, if not more important, than the technical side.
Changing personal behaviors is hard, and changing company culture is even harder. We hope these 10 principles offer ways of thinking about software engineering that help move the needle on both.
Like what you just read? Join our Talent Network to scope out open software engineering roles at Salesforce and come join the conversation!
