DMC Development Ethos
In my next post I’ll be outlining the features that I want to see in the fleshed-out DMC suite but before I do that, it’s important to talk about the general ethos behind our development. This is more bullet points than a coherent argument:
- First-up, we’re dogfooding, which requires that we keep things reasonably usable at all times but it also means that we are going to focus on those areas that we use most internally, at least during the initial development period.
- We intend to release early and to release often, especially during the development and beta process. Once we have production-ready code, we anticipate forking development into stable and head branches, with stable only receiving bug-fixes and a much more predictable feature upgrade path.
- During the early phase, we are very heavily focussing on getting things working in broad strokes and will almost certainly go down technological dead ends. In these cases we will attempt to provide a migration path but watch for announcements that we consider the suite ready for testing and that we will be supporting migration issues.
- We value working code over theories. Although my 5 pillars may be a good basis for the ongoing development of the project, if we have to make a choice between code that works right now and missing the feature, in early versions we will probably include the feature, document the implications and work to resolve them in the drive toward V1.
- It’s collaborative; we are creating a package that helps us to create culture, so we hope to encourage a culture that helps us create good code. Please give feedback, patches and suggestions as we go.
This topic deserves more than this quick visit but I needed to get that off my chest quickly so that we could move on to the features!