- Improve the quality of the software we create through technical/organisational measures
- Good defaults for our projects
- Conscious decisions to make use of certain techniques at the start of the project (when there is still time)
- Knowledge transfer within the basysKom team and with our customers
- Provide a tools teams, developers and project managers can pick from
- The goal is NOT to construct a heavy-weight process to be applied to all projects in a one-size-fits-all manner.
In this context, a tool is a small recipe for achieving a particular goal. It gives hints on how to implement a tool and on the potential effort to do so. In which situation can a tool be usefully applied? It outlines caveats and limitations. The idea is loosely inspired by the classic book "Design Patterns".
A tool is not set in stone. We expect feedback from users of a tool about it's usefulness, effort, caveats and limitations. Please post issues about a specific tool directly on github.
An important piece of information for a given tool is the applicability. A particular tool might be very easy to implement in a greenfield project, but not in a legacy code base. Another tool might make perfect sense for developing a large application, but not for a three-week prototype.
You can create tags in the readme of your projects to list tools or principles you used during develepment like this: