Sibelius Seraphini, co-founder of Woovi, discusses their unconventional software development practices, emphasizing simplicity and cost reduction, moving away from traditional object-oriented programming, unrestricted technology choices, and overly complex architectural patterns.
Eduardo Matos (left) and Sibelius Seraphini (right) discussing software development practices.
[
00:30:18
]
Woovi largely eschews object-oriented programming (OOP) in favor of a functional paradigm, citing issues with inheritance, mutability, and a preference for simpler functions.
They restrict technology choices primarily to JavaScript/TypeScript within monorepos, minimizing complexity and making team mobility easier, with other languages reserved for highly specific needs.
Dependency injection is largely avoided, especially in JavaScript/TypeScript, due to the language's ability to mock modules at runtime for testing, reducing unnecessary indirection and "magic."
Clean Code, Design Patterns, and Clean Architecture are viewed critically, as their rigid application often leads to over-engineering and increased complexity rather than genuine simplification.
Woovi prioritizes automated integration testing over unit testing for business logic, finding it provides a better cost-benefit by testing the system closer to the end-user's experience, thus increasing confidence for rapid delivery.
The core philosophy is that restrictions lead to faster development and higher quality, enabling efficient growth and reducing long-term maintenance costs.
Eduardo Matos (left) and Sibelius Seraphini (right) discussing software development practices.
[
00:30:18
]
Sibelius Seraphini, co-founder at Woovi, shares the company's unique software development practices.
The discussion is rooted in a controversial LinkedIn post by Serafini regarding practices abolished at Woovi, which generated significant online debate.
Problems of Object-Oriented Programming (OOP) [00:28]
Shift from OOP to Functional Programming:
Serafini's early experience included Java with MVC for object-orientation.
He later transitioned to a more functional paradigm, influenced by React and its emphasis on immutability.
Critique of OOP Complexities:
Inheritance: Identified as problematic due to difficulty in debugging, leading to large stack traces and complexities from virtual methods and access modifiers (protected, private).
State Mutability: OOP's focus on mutability makes code harder to reason about, contrasting with React's clear state management (e.g., setState).
Early Angular versions, with two-way data binding, allowed variables to change everywhere, leading to performance issues once applications scaled.
Preference for Simplicity and Functional Concepts:
Serafini values simple constructs like variables and functions, considering them the most basic building blocks.
Functions are seen as clear mappings of input to output (domain and codomain), aligning with a mathematical background.
Combining type systems with functions in languages like TypeScript leads to robust and clean code.
Objects as Closures: Objects and classes can be viewed and simulated as closures in some functional contexts, simplifying understanding.
Core Philosophy: Avoidance of inheritance and excessive class-based abstractions, instead focusing on data and functions that process it in an immutable manner.
The Problem of Total Freedom in Technology Choices [06:07]
Detrimental Effect of Unrestricted Freedom:
Unrestricted technology choices for individual teams lead to diverse and fragmented tech stacks within a company.
This fragmentation increases complexity and makes it challenging to move developers between teams.
Woovi's Approach: Restricted Technology Stack:
Woovi primarily uses JavaScript and TypeScript, managing almost 100% of their codebase in these languages.
They utilize a monorepo structure (separate monorepos for backend and frontend initially, now selectively splitting) to enhance control and convergence of practices.
Other languages (Kotlin, Java for specific XML signing, Go for real-time POS authorization, C for custom Pix hardware) are used only for highly specific, unavoidable requirements.
Cost Implications of Complexity:
Adding more languages and technologies introduces complexity, which significantly increases maintenance costs.
In the current economic climate, maintaining positive cash flow is critical, and high complexity hinders this.
The aim is to make systems so simple that dedicated "DevOps" teams are not always necessary, leveraging standard, easy-to-manage tools like Docker and Kubernetes.
Dependency Injection is Not Always Necessary [10:39]
Language Capabilities and Mocking:
In JavaScript/Node.js environments, tools like Jest and Vitest allow mocking external modules at a low level.
This capability means developers can mock HTTP requests or other dependencies during testing without altering the production code, thereby reducing the need for explicit dependency injection frameworks.
Critique of "Magical" Dependency Injection:
Serafini criticizes "magical" dependency injection where it's unclear where an implementation comes from, requiring developers to traverse numerous files (abstract classes, interfaces) to find it.
This indirection increases complexity, makes debugging harder, and can impact runtime performance.
Over-Engineering Simple CRUD Operations:
A common anti-pattern is applying complex architectural layers (service, controller, repository) to simple CRUD operations, resulting in excessive file creation for trivial tasks.
This is often attributed to "full syndrome" (mid-level developers applying complex patterns without understanding their necessity) versus seniors who prioritize simplicity.
Postponing Structure and Bureaucracy:
It is crucial to postpone adding complex structures, governance, or processes until the organization's scale genuinely necessitates them.
Prematurely adopting "Bigtech" complexities without corresponding revenue or scale is detrimental to startups.
Examples include early-stage MVPs with multiple programming languages or excessive microservices.
Making Software Easy to Change, But Without Exaggeration [18:43]
Designing for Future Flexibility:
The goal is to structure code (even within a monolith) to allow for relatively easy separation into microservices if needed in the future.
This involves organizing code by feature rather than by type (e.g., placing user controller, service, etc., in a single "user" folder).
Avoiding Premature Optimization/Abstraction:
Creating complex abstractions (e.g., repository patterns to facilitate database changes) for highly improbable future scenarios often introduces more daily maintenance difficulty than it provides value.
API Design Philosophy:
Good API design provides fewer options to the end-user, offering well-chosen defaults and minimal customization.
This reduces complexity and the likelihood of bugs, a principle applicable beyond just code (e.g., product features, internal systems).
Complexity is Universal: The principle that complexity degrades performance and increases costs applies to all aspects of a system, from codebase to DevOps and external services.
The issue with classic design patterns (e.g., Gang of Four) is not their inherent value but their misapplication or over-application by developers who don't fully understand their purpose.
Blindly implementing many patterns in a codebase without a clear need leads to unnecessary complexity.
Functional Equivalents:
Many object-oriented design patterns have analogous concepts or simpler implementations in functional programming (e.g., using higher-order functions).
Interfaces are preferred over abstract classes for defining contracts without introducing unnecessary complexity.
"Silver Bullet" Syndrome:
When any concept, including design patterns, is treated as a universal "silver bullet," it often becomes an anti-pattern due to its indiscriminate use.
Developers should engage in critical thinking, learning from various sources, and evaluating context before applying patterns.
Strategy Pattern Example:
The strategy pattern (or "type classes" in functional programming) is valuable for scenarios where different implementations are needed based on the environment (e.g., using Redis vs. in-memory for caching, SQS vs. in-memory queues).
This allows for flexible dependency swapping without altering core logic.
Real-world Application at Woovi: Woovi uses interfaces for components like email or banking providers, allowing for multiple implementations without coupling the client code to specific providers. This approach simplifies integration and changing providers.
The problem isn't "clean code" principles themselves (e.g., small functions) but the dogmatic adherence to specific frameworks or patterns without critical evaluation.
Frameworks like Django or Rails offer opinionated structures, which can be useful, but relying on them without personal judgment can be detrimental.
Lack of Opinion in Development:
Many developers and companies lack a strong opinion on how to build their codebases or are unwilling to take the risk of forming their own practices.
They tend to copy existing practices (e.g., Clean Code, "enterprise-ready" frameworks) even if they don't fit the specific context, such as a small startup with zero users.
Over-complication (e.g., NestJS):
Frameworks like NestJS are criticized for being overly complex, introducing numerous patterns and dependencies that are often unnecessary for simple web applications.
This leads to bloated projects, difficult debugging, and unnecessary development time spent on boilerplate code.
Outsourcing Decisions: Developers often outsource their architectural and design decisions to popular frameworks or the opinions of large tech companies (e.g., choosing Angular because it's from Google) instead of evaluating actual needs.
"What if it scales?" Trap: Designing for hypothetical massive scale from day one, especially for simple CRUD operations or apps with no users, leads to wasted effort on unnecessary complexity.
Clean Architecture is seen as another example of a prescriptive approach that can lead to excessive boilerplate and complexity when applied without a deep understanding of its necessity.
It often encourages layers and dependency management that are over-engineered for many common problems.
Front-End Application: Attempts to apply Clean Architecture principles to frontend development can further complicate front-end frameworks (like React or Angular), which already provide their own simpler structures for managing code.
Frameworks for Structure: Modern frontend frameworks (React, Angular, Vue) actually help structure and simplify frontend code compared to older DOM manipulation libraries like JQuery. They enable better decoupling of backend and frontend and easier testing.
Balancing Logic Placement: The decision of whether to place more logic on the frontend or backend depends on the specific application's needs and interaction complexity.
Simplification and Boilerplate Reduction: Good abstractions are crucial for simplifying development, reducing boilerplate, and improving productivity.
Examples: Databases abstract complex data storage details, and declarative programming paradigms (e.g., GraphQL Relay) abstract data fetching logic.
Long-Term Cost Reduction: Prioritizing abstractions that reduce development and maintenance costs in the long run is a key focus for engineering leaders.
This often involves a higher initial investment for long-term gains (e.g., automated tests, DevOps automation, design systems).
Initial vs. Marginal Cost: Automated tests, robust CI/CD, and design systems might have a high initial setup cost, but they drastically lower the marginal cost of adding new features or maintaining existing ones.
Restriction as a Benefit: Design systems impose restrictions on UI components and styling, ensuring consistency across the application and preventing developers from writing custom CSS daily.
Focus on Business Rules: Developers should spend most of their time writing business rules and solving core business problems, rather than low-level configuration or repetitive styling.
Planning Over Coding: The first step is always planning:
Draft RFCs (Request for Comments).
Understand the product requirements.
Sketch out designs and data models.
Analyze query patterns, expected load, and capacity requirements.
Iterative and Simultaneous Development:
Serafini advocates for an interactive development process where backend and frontend are developed concurrently.
Developing one in isolation before integrating is inefficient and almost always leads to rework.
Embrace Modern Approaches:
Continuously update development practices and leverage the latest language features (e.g., running TypeScript directly with Node.js without bundlers/compilers).
Leverage Existing Codebase:
The best way to start new features or projects is often by copying and pasting existing, well-functioning code from within the company's codebase. This maintains consistency and reduces complexity.
Avoid AI-generated code that lacks context of the specific codebase, as it can introduce random, inconsistent patterns and increase complexity.
Deploy on Day One:
Highly recommended to deploy an "empty" application to production on the first day.
This forces the setup of the entire CI/CD pipeline (initial project structure, CI/CD configuration, production provisioning).
Ensures that future deliveries can be made frequently and easily, bridging the gap between development and production.
For unreleased features, continuous deployment to production (e.g., via main branch commits) can be beneficial until users are involved, at which point staging environments can be used.
Testing for Speed and Confidence: Automated testing is crucial for moving quickly, building confidence, and preventing regressions. It is not a slowing factor.
Cost-Benefit Approach:
Woovi prioritizes tests with the best cost-benefit ratio.
Integration Testing (Preferred): This is the primary testing strategy for both backend and frontend.
Backend: Tests simulate end-user interactions (e.g., HTTP requests, GraphQL mutations, event processing), validating responses and database changes with an in-memory database. This inherently covers unit-level logic without dedicated unit tests.
Frontend: Renders the DOM (using testing libraries) and simulates user interactions (e.g., typing, clicking), asserting that correct requests are made to the backend. The frontend tests do not hit the actual backend; they mock its responses.
Integration tests are reliable because they test behavior closer to how the end-user experiences the system.
Limitations of End-to-End (E2E) Tests: E2E tests are also valuable but are more expensive and prone to flakiness, so they are used more sparingly (e.g., once a day, or before major releases). These might only validate return schemas, not specific data.
Critique of Unit Testing:
Redundancy: For business logic, unit tests often become redundant if already covered by integration tests.
Testing Implementation, Not Behavior: Unit tests tend to test internal implementation details rather than the desired behavior of the system. This means refactoring internal code often requires changing unit tests, undermining their value as a safety net.
False Positives: Unit tests can give a false sense of security (tests pass, but production breaks) if they don't accurately reflect how units interact in a real system.
When Unit Tests are Appropriate: Unit tests are valuable for isolated, pure functions that are not tied to specific business rules (e.g., a function to calculate time differences from a given date).
Necessity for Fintech: For critical applications like fintech, where financial integrity is paramount, extensive automated testing is non-negotiable to prevent costly errors.
Developer Resistance to Banished Practices [54:06]
Embrace of Simplicity: Over time, developers at Woovi tend to appreciate the simplicity of the codebase, despite initial intimidation by its size.
Learning Through Feedback: The comprehensive integration test suite provides immediate feedback when developers introduce breaking changes, serving as a powerful learning tool and reinforcing the benefits of the chosen practices.
Continuous Improvement through Abstraction: Woovi actively seeks to identify and implement new abstractions that simplify challenging parts of the codebase, reducing future friction.
Importance of Written Documentation:
Written documentation is critical for scaling a remote company, centralizing knowledge, and reducing reliance on synchronous communication (calls).
Serafini believes a remote company without extensive written documentation is not truly modernized.
Modern, Distributed Management:
Woovi practices a highly autonomous and distributed management style for developers.
Engineers are encouraged to identify problems (technical and product-related), interact with customers, and propose solutions, rather than just executing predefined tasks.
This contrasts with traditional, more bureaucratic management styles (e.g., strict adherence to processes like Git Flow without understanding the "why").
Learn from Different Opinions: Actively seek to understand perspectives different from your own; it is an opportunity for learning and personal growth.
Modernize Management: Encourage shifts from:
Face-to-face to remote work.
Synchronous to asynchronous communication.
Speaking to writing (for documentation and knowledge sharing).
Empower Teams: Foster a distributed management approach where teams are empowered to contribute, innovate, and solve problems independently, rather than just implementing dictated tasks.
Explore Functional Programming: Recommend exploring functional programming concepts (e.g., immutability, advanced abstractions like "fantasy land") for their potential benefits in simplifying code.
Productivity through Writing: Emphasize writing articles and documentation to efficiently share knowledge and avoid repetitive explanations.
Restrictions Enable Speed: Paradoxically, imposing sensible restrictions on technology choices and development practices can lead to faster development cycles and higher quality outcomes, as demonstrated by Woovi's rapid product development (e.g., building a bank in 4 months).
Engineering's Core Goal: The ultimate objective for engineering leaders is to ensure teams can deliver high-quality software at an appropriate and sustainable speed.
