Software projects of any significant size have architects. Architects scope the technical plan and make strategic technical decisions. A hands-on architect might build prototypes, interfaces, and mock ups.
A lead developer is sometimes wrongly considered an architect. Lead developers lead developers and make tactical technical decisions. They see a project through to its delivery.
Sometimes one person gets both roles.
Recently, I have appreciated the contracting forces of Nazi-like software rigor and the individual creative freedom – like micro-management versus macro-management.
I created a series of interfaces to build a wizard-like UI. The implementation was up to the developers. Dozens of wizard steps later, implementations varied greatly. It "got the job done" but was a cluster.
For the sake of simplicity or future maintainability by the customer, it needed to be refactored with a consistent implementation across each step.
I refactored each wizard step. The resulting code was simpler (50% less code) and consistent (since I knew the implementation pattern in advance).
But here's where my trouble started.
The customer wondered why my solution architecture was changing or was insufficient to address this 6 months prior to it occurring. What was all that "prep" work for?
Non-technical project members misunderstood refactoring as rewriting. They wondered why I didn't leave "good enough alone" as they encountered the inevitable I introduced.
My developers felt embarrassed when their implementation was not the selected pattern. They were frustrated. Their code was changed and my new bugs were appearing in their task list.
And here's where I went wrong.
As both the architect and lead developer, I didn't have the correct relationship with the developers or time on the project (a very tight timeline) to sufficiently code review.
Resting on too many assumptions with the customer, I never bothered to educate them in the subtle differences between architecture and design.
Misreading the non-technical project team's willingness to "do it right" I didn't bother educating them in the necessity and the value of refactoring code.
In the end, the code was simpler, consistent and maintainable. But the resulting team friction disenfranchised my later opportunities to refactor other ailing areas.
It's a lesson I have learned.
At the heart of the issue is the desire (as the lead) to ensure the overall excellence of the solution versus my desire to respect the creative desires of developers and maintain a cohesive team.
Which is more important?
From the bottom up, a cohesive, effective team is vital to project success. Regular turn over dilutes the vision, atrophies morale, and undermines consistency. Frustrated teams lose velocity, decrease quality, and are miserable. So, is the team the most important?
From the top down, a quality solution is vital to project success. Decreased quality increases maintenance costs, reduces shelf life, and threatens timelines and budgets. Mediocre software is more expensive, less stable, and slow. So, is software structure most important?
The answer is easy; doing it is difficult.
The customer writes the checks, but developers can leave – screwing up a project. A developer writes cool code, but customers can reject it – foiling success. Each must compromise for the other.
Instill in the customer and project team a common vision – each is the other's key to success. Good might just be "good enough" but it should never be the goal. A shared drive to excellence, simplicity, and mutual benefit – that's the real key.
What about developer independence?
There's no quick answer. Sometimes a developer is plain wrong. Sometimes a developer's idea is better than yours. You can't stifle creativity, but you have to ensure you have the time and discipline to adequately code review work. And communicate to your developers that code review and code refactoring is going to happen. Don't marry your code. But, be sure customers and non-technical team people understand this is vital and as the architect or lead developer, you must be allotted sufficient time.