As I’ve gained experience working in a variety of company types, sizes, missions, and stages of development, I’ve come to realize that the only “right way of doing things” in terms of software development at an organization is to align the process and outcomes with the organizational objectives. And this includes both short and long-term objectives as well. As has been said before, every line of code (and really everything else) is a (business) decision. “Common sense” and best practices can be amorphous around the edges; even things appearing settled can fall apart in an unconventional environment.

A developer whose spent much of his career at larger, established companies may find himself working at an early stage company that doesn’t value documentation as much, and probably for good reason. Obsession with code structure at such an early stage might also be ill-advised if the company needs to quickly discover its market fit, even if that means code churn as a tolerable byproduct.

In a evolving business environment, software’s best practices are hyper-clarified. DRY cannot be a rigid dogma of ensuring nothing is duplicated; it becomes clear that separate pieces of logic should be DRYed only once it’s been determined they will evolve together. Premature DRYing can eventually lead to a time sink of having to rewrite logic in multiple places (and potentially bugs). This goes for any software best practice - layering, decoupling, etc. When inappropriately applying a practice, the resulting problems can magnify as the business environment changes. When I was working at a later-stage startup, I came across a Python function in a small service that was, let’s say, too long for conventional tastes. However, after time went on working there, I came to realize that 1) this function didn’t needed to be changed often and 2) when it did need to be changed, it was easier in some ways to read through the logic line-by-line after losing context from the hiatus. Still, one could argue that the function could have been broken up so that individual pieces of logic could be unit tested.

Testing is another area that could be malleable to business requirements. What if developers are tasked with one-off projects where an app is spun up only once for a short time and with very specific logic unique to that situation (the company has ongoing projects)? And let’s say the apps are strictly tested externally by a QA team. How necessary is it for developers to write their own automated tests? There’s an argument to be made that given enough budget and time constraints, it might be unnecessary. However, there is still the possibility that before release, developers will go through some code churn and will need internal testing to keep them on track. But the point is that even the scope of testing is subject to deviate from conventional wisdom in order to map unique business situtations.

Where the objective-first philosophy can break down is when an employee’s self-interest conflicts with the organizational objectives. A company decides on a rewrite of the frontend from Ember.js to React, or abandons a microservices architecture attempt in favor of a monolith. A developer may have been hoping to deepen her skillset in the status quo tech stack in order to be more marketable. If there is a lot of change anticipated, maybe the organization should consider employing generalists going forward, and tie their compensation more to solving business problems rather than applying solutions.

Another breakdown happens in an organization that holds many internal secrets or information silos. It’s very hard for people without the information to make the best automous decisions in times of ambiguity. And trust of course is fragile in this kind of environment. This one is tricky and I don’t really have an answer. At every juncture in the organization where information is withheld to another group, the people holding the secrets must always be cognizant of where and how the group without the secrets can go astray.

I think it would be wise for an organization’s leaders to delineate objectives upfront and continuously, and ruthlessly map and priotize them. Then they would communicate these objectives and properly incentivize every member of the organization so that they can carry out the mission and autonomously make the right decisions according to the objective priority. And a developer should always evaluate best practices in the context of organizational objectives.