Mar 26, 2025

The Two Sides of the Code: Thoughts on Architects and Experimenters

10 min read

I've read online discussions about two kinds of software engineers: those who write detailed design document and plan, and those who jump right into creating working prototypes.

Although this is a very simplified model, the reality is that most engineers utilize elements of both.

In this post, I'd like to share my thoughts on these approaches in their extremes, understanding that both are valuable and necessary in the business. The idea is not to portray one as better than the other, but to understand the advantages and disadvantages of each.

Architects

Engineers who focus on detailed planning invest significant time in technical documentation and system architecture design. They anticipate potential problems, vulnerabilities, weaknesses and bottlenecks.

This creates a shared team vision and prevents early errors. While it may initially delay implementation, it eventually ensures greater quality and accelerates development. Architects focus on building solid, reliable, scalable foundations designed for longevity and change.

One of their most significant strengths is that they build robust systems that minimize future issues and ensure easy maintainability.

Architect-driven projects benefit from predictable evolution, maintaining stability thanks to a well-planned design. Their structured approach reduces risk in complex projects.

So, where are Architects most valuable? They excel when building critical or core infrastructure, systems requiring high reliability, and projects with strict compliance requirements. Their detailed planning minimizes risks and ensures long-term stability. And sometimes it also simplifies the onboarding of new engineers to the project.

Experimenters

Engineers who embrace prototyping quickly begin coding and gather feedback from end-users. They prioritize creating functional prototypes for rapid testing and iteration.

This approach excels when project requirements are unclear or when hypotheses need quick validation. While initial code quality and speed might be lower, each iteration improves based on real-world feedback.

One of the major benefits is being able to quickly examine different solutions and adjust to changing user needs.

Experimenter-led projects welcome change, with initial prototypes often being rewritten or discarded as the team learns and adapts.

This provides exceptional flexibility and rapid response, crucial in dynamic environments. This iterative process allows for rapid innovation and the discovery of unforeseen opportunities.

Experimenters shine where innovation matters the most, the requirements are evolving, and the speed of iteration is crucial. They're ideal for startups, research projects, and rapidly evolving markets.

Both approaches – planning and rapid prototyping – are valuable and effective in various scenarios. The optimal choice depends on project type, budget, risk tolerance, and team goals. Ideally, engineers should cultivate skills in both areas to adapt effectively. Recognizing the strengths of each allows for a more balanced and successful development process. The best engineers can seamlessly toggle between these styles when necessary.

Personal Projects and Solo Development

For personal projects or solo development, the experimenter approach can work extremely well due to limited resources and the need for rapid validation. Embrace experimentation, diverse approaches, and code rewrites to discover what truly works.

However, integrating planning, even on a smaller scale, can prevent future problems, particularly without strict time constraints. Finding a personal balance that aligns with your risk tolerance and pace is essential.

Keep in mind that even in your own projects, you should consider to plan for potential problems and vulnerabilities. Take advantage of tools available to you and ignore irrelevant criticism. The Architect style can help you save time and avoid stress in the long run, even in personal projects.

Factors Influencing the Choice of Approach

The architectural approach is often required or preferred when:

Established company processes dictate it (e.g., Waterfall)
The project's criticality demands minimal errors (e.g., life support systems)
Minimizing technical debt and future issues is paramount
A structured, predictable development process is needed due to project complexity or long-term maintenance requirements

Architects excel in situations demanding reliability, security, and long-term stability.

The prototyping-oriented approach is often favored:

In startups or companies prioritizing speed and flexibility
When using Agile methodologies (e.g., Scrum, Kanban)
When rapid hypothesis testing and user feedback are crucial
When a dynamic, iterative development process is preferred
To get hands-on experience with the product and identify bottlenecks and business needs

Experimenters thrive in environments that reward innovation, adaptability, and rapid learning.

Although individual programmers have autonomy, altering processes in large, well-established companies is challenging. So, the top engineers are those who can adapt and apply both approaches effectively.

Examples from Other Fields

Consider these analogies: When choosing an accountant or lawyer, most prefer a detail-oriented specialist providing verified solutions over quick, risky fixes.

Conversely, marketing and advertising often value experimenters who readily adapt to changing conditions.

In software engineering, both designing and prototyping are essential for success.

Collaboration

Collaboration Integrating engineers with differing styles is a fine art. Dominance by one style can cause conflict and stagnation.

However, a team with members from both styles, respecting and working together, can work more efficiently and accomplish more. A possible collaboration model involves architects designing the system's foundation, with experimenters creating prototypes and testing hypotheses on top of that foundation. Successful collaboration hinges on mutual respect and valuing each other's strengths.

An open and trustful environment is important. Consider separating responsibilities where architects create a stable base that allows experimenters to safely test different options without breaking everything.

Conclusion

To wrap up, I think both architects and experimenters both play a critical role in software development. The choice depends on the situation and goals.

Engineers should develop skills in both planning and prototyping, as neither approach is inherently superior. Finding a company or project that aligns with your preferences is key.

Finally, success depends on being flexible and taking the best of each style. Both types of engineers are necessary, and the best teams find ways to integrate both Architect and Experimenter styles.

If you favor structure and predictability, a large corporation may be a good fit. If you prefer experimentation and rapid adaptation, a startup or Agile-focused company may be ideal.