Experiments are for scientists. You’re not a scientist — you’re an architect and an engineer. You’ve designed your architecture so just go and build it. Trying out different approaches to a problem will litter your codebase with the technical debt of failed experiments. Stick to the architecture, the code, the design doc you already have.
7 Ways To Avoid Technical Debt
Ian McKellar
2313

Experiments are for learners. And programmers, software architects, software craftsmen or whatever you call the guys and girls producing superb code should definitely be learners. I personally agree with what you said on https://medium.com/@ian/the-real-value-of-side-projects-4d30c1ea4283#.eynkkgk7w, that a fair share of this should be done in your own time, but I find it invaluable to allow experiments on business hours, too — but absolutely not in a way that failed experiments find their way into your code base! Experiment in small, implement successful experiments into your product. That’s IMHO better than designing something in your head and on paper only without having tried it out.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.