Complexity cost is something everyone from managers (whether the CEO, product manager, or vp of engineering) to engineers themselves rarely consider. It's something a good product organization should implement solutions to always take them into consideration. The complexity cost of implementation, explanation and side effects are significant in many and subtle ways. For engineers, it might come in the form of implementation complexity — perhaps too clever a solution, optimizing for the wrong thing (code clarity over product clarity — though that is not to say code clarity does not matter), or optimizing for a guessed at future problem, or simply misunderstanding the feature, which brings one to product complexity. We have a thing we call "re-frames" on kinja. It's a thoroughly confusing feature in terms of how it is implemented, and the justification for calling it a re-frame (a re-frame is essentially a share with some commentary from the person sharing a link or block of content). There has been similar complexity deep into our comment features — side-effects from follows (also approve a comment), and lack of clarity on how or why a comment might appear or remain in "the grey".

Advertisement

Dig into this article from Kris Gale — it's more great insight from the former VP of Engineering at Yammer. In a nutshell, on the product side, data is your best defense. On the implementation side, focus on "understanding, communication and maintenance" and avoid clever, "future resistant", or difficult to crack implementations (documentation is not the solution). Let me know your thoughts below.

Embrace simplicity in your product and in your code. The value is in what gets used, not what gets built.