The most dangerous word in software architecture

The most dangerous word in software architecture is “yes” — especially in its qualified form (“yes, but…” — where nobody will listen to the “but…” part).

I was chatting with colleagues about our biggest failures as software architects. We’ve built the wrong thing, failed to build things, built them buggy. We’ve made a lot of mistakes over the years, but the biggest ones — the product-killing ones are usually saying “yes” to something that might as well have opened a portal to Hell in the project. These were never frivolous “yes” answers. They were often tactical wins. But, what they did is establish a new expectation in the minds of stakeholders that made success significantly harder.

I know that it is popular to say that “just” is the most dangerous word, but those are tactical errors. The product-killing strategy errors are the agreements, taking on things that aren’t really feasible without a technological investment that you can’t afford.

I have done my share of them. They come in all shapes and sizes at the time, but they tend to take the form of doing something that you’d planned to eventually do, but moved up to right away. The problem with saying “yes” to such requests is that they often appear like small things to the outside world, yet doing them properly would require the product implementation to mature significantly. What happens then is usually one of two things:

• The feature apparently working removes the pressure to make the required technological investment. Why move a mountain when “it already works” (the “but…” part in “yes, but…”). By the time the limitations are apparent, the needed investment has grown due to technical debt and the appetite to make it has passed.
• The premature availability of a niche feature completely changes the perceived intent of the project. Gone are the original intentions and vision, all that is front and center is this niche feature. Sure, there are success stories of such distractions becoming successes in their own right (e.g., Twitter) but, more often than not, the new thing is not a world-changing product — it is a shiny distraction that ultimately kills itself and its parent in an unintentional murder-suicide.

I suppose that you could also view this post as a warning about the perils of careless product roadmap management — which is true — but the momentous roadmap change doesn’t necessarily look like one. It looks like an innocent, constructive question. A question whose consequences only become apparent much later.