Manifesto for Software Engineering

Architecture Awareness & Collaboration

Technology choices are not unrestricted by default. Therefore, we make every effort to ensure that the views of a wide range of individuals, and in particular software architects, are taken into account for technology choices.

We do not expect architecture to be memorized by anyone. We expect it to be re-checked (reviewed, prepared at first, then consulted) during implementation.

Engineers actively collaborate with architects and are responsible for understanding, following, and validating their implementation against approved architecture decisions, non-functional requirements, technologies, approaches, and relevant documentation.

When seeking information about technologies, a developer must follow this order: internal wiki first, then AI/assistants, then Google or Stack Overflow, then colleagues.

If rules, guidelines, best practices, principles, or coding standards are missing, developers take the initiative to present proposals to architects for approval.

AI tools may be used to assist in preparing architecture proposals or documentation, while final decisions remain with architects.

We use proper tools and formats for architectural communication.

The development team explains exactly how features will be implemented during sprint planning. Check out the Scrum Guide Sprint planning

Engineers/Developers clearly express their know-how, knowledge. Communicate what they truly understand and can implement.

Code reviews are the starting point for discussions. Code reviews are used to share and increase team know-how about architectural decisions, coding styles, and best practices.

All architectural decisions and coding practices should be made transparently and documented in advance.

Analysis Awareness & Collaboration

…

Development Awareness & Collaboration

Transparency.

In task context.

In (sprint) plan.

Promises.

…

---

End of draft.