But we said so in our DoD!!!
Whenever I work with large organizations I seem to always inadvertently stumble into a symptom of helpfulness and productivity that makes great engineering end up in cargo culting instead of effectiveness and efficiency. It usually goes like this, individual developers or even teams have created something to "bootstrap" or "launch" or "kickstart" a project or process phase. Your typical "boilerplate tooling" or "internal library". It gets advertised or hyped accidentally and all of a sudden:
It is a great example of how trying to be helpful is only really good if you don't have a warped sense of "donneness".
Yagni man, YAGNI! we are DONE!!!
Everybody wants to be helpful. For engineers probably one of the biggest accolades of helpfulness is creating artifacts that other developers can use to takes shortcuts. Developer tooling. But what does actually make a developer tool good? There is some quote out there about perfection being not a state where nothing can be productively added but the state where nothing can be removed without destroying the thing. Often, when we create something that will shape the form of more than your immediate peers, it is good to keep that principle in mind. One might think, sure its just the keep kissing thing. In actuality, it is almost its opposite.
Keep it simple is often also a call to being donne with something. To start stopping. To say "good enough". Keeping pragmatism in the room to get on with things, because improving it won't be offering any more returns before we know we really need that sort of improvement.
Corporate engineering is driven by progress and quality metrics and in order to feed those, teams often turn to implementing DoR and DoD lists. These describe what can be put into a teams work queue (DoR) and what qualities it needs to have to go out on the other side (DoD). The concept is a strong one because it allows to allow variation in the work brief and the outputs, reducing unexpected extra work post implementation. These requirements will most often be set up based on on the premise that the work item of a team is alligned with that team's value stream. If the team mostly implements business functions the DoR and DoD will be geared towards that sort of environment.
Typically teams have some sort of mechanism that ensures something that was "Done" in the past but turns out needing work being reintroduced in the pipeline. Most often this mechanism is mainly driven by business signals and less by input from engineering. We are YAGNI after all. But when it comes to the point that team members create value that is perpendicular to the teams nominal value stream things aren't as clear cut. For one, the typical provider of work is completely detached from the material and therefore cannot really be proactive. On the other side the engineers do have to climb a barrier as reopening work on that tech artifact might conflict with egos or quality assumptions.
Ensuring a thing is done may mean that you need to get back to a done thing to make it ready for reuse. And sometimes doing a cumbersome excision of non-essential features or bloat can feel not worth it but it turns out to be just the thing that good developer culture allows for. Perfection is not an enemy it is an ideal to uphold and to train towards, 80% of the time it might not be important but one in five times, one day a week you might be faced with a situation where perfection is just what needs to happen and you better be ready to chase it.
Get things done, sure. But keep an eye out for the occasions where more and done as in DoD might be required.
