We stick to standard usages and best practices because they work and communicate intent well, but without trying new things we can't really grow. Have you ever tried something that seemed absurd but worked out really well? When it works, how do you avoid confusing other developers with non-standard usages? And what do you do when things go horribly wrong - refactor, start over, or just go with it?
|
|
Yes, but with simplicity wrappers. Most users will only need to access through the simplicity wrappers. The system would be very familiar to them, because the simplicity wrappers are designed to be very similar to the older systems. However, advanced users who need extra power, and developers on the new system team, will need to become fluent in the new pattern. If things go horribly wrong, the entire project has to be thrown away. This is why early feedback (integration) is important, so that you can stop loss earlier. Also, put some effort on educating your fellows about the inside, and any special precautions needed. Put a lot of effort on testing. |
|||
|
|
|
All the time. I avoid confusing other developers by only expierementing on personal projects. Id say some of the best and most of the worst code I have ever written has been for personal projects- when trying out new things. When things go horribly wrong, since its usually just a small part I throw it away or refactor it until it is useable. |
|||
|
|