Several popular frameworks have as a core design principle that “convention” is preferred over “configuration”.<\/p>\n
I’ve come to think that they’ve actually understated the case. \u00a0In fact, our development team has made significant strides in identifying not only causes of defects, but also the factors that slow development in\u00a0exchange for reducing defects in the first place.<\/p>\n
One of the top issues on the latter list is what we’ve been calling the “arbitrary decision”. \u00a0If a given technical challenge is\u00a0hard<\/em>, that can actually simplify development. \u00a0Either the\u00a0first<\/em> solution we find is a good one, since we save time by avoiding looking for additional solutions, which might not even exist. \u00a0Or there may be a clear best<\/em> solution, or even only one that will actually work.<\/p>\n This “arbitrary decision” is exactly what’s referred to as “convention”. \u00a0Every convention\u00a0that’s already been decided\u00a0both reduces defects\u00a0and<\/em> saves developer time.<\/p>\n Defects are reduced because:<\/p>\n Speed of development is increased simply because there are fewer decisions to make.<\/p>\n Here are some examples of conventions that have benefitted us:<\/p>\n Several popular frameworks have as a core design principle that “convention” is preferred over “configuration”. I’ve come to think that they’ve actually understated the case. \u00a0In fact, our development team has made significant strides in identifying not only causes of defects, but also the factors that slow development in\u00a0exchange for reducing defects in the first…<\/p>\n\n
\n