3 ms·
I don't think this is an argument for requiring plans, though: you can always encourage them, but in the end it should be up to the person doing the design. Ot
by panic 9y ago
I don't think this is an argument for requiring plans, though: you can always encourage them, but in the end it should be up to the person doing the design. Otherwise you end up with the absurdity of having to write a detailed plan and wait a month for approval just to change the positioning of a button slightly.
- sidlls 9y agoIf the implementation outlives the implementer it most certainly shouldn't be up to him whether he does the design or not.
- panic 9y agoWhat I'm saying is that depends on the nature of the code that's being written. Many small improvements can be made with a simple code change that has clear meaning on its own -- a long approval process would just make these changes less likely to happen.
- sidlls 9y agoThe point of having an approval process of any length or complexity is precisely to make changes less likely to happen ad hoc. That's a Good Thing (tm)! Sometimes "small improvements" have ramifications outside of the context of the change (potentially significant ones). The person implementing these improvements has to understand the scope of the change (including side effects on external systems, if any), and that effort should be documented somewhere or at the very least reviewed by peers for correctness, especially for truly mission-critical or sensitive systems. It doesn't have to be a "fill out these forms in triplicate and don't forget the new cover on your TPS report mmmkay" kind of documented effort: it's not one extreme or another.