Size is the best predictor of code quality (2011)
I&#x27;ve come to realise that the size of a code base measured by it&#x27;s features and components is very different to the kind of &quot;size&quot; which you might measure by line numbers.<p>It&#x27;s generally a good thing to write code which takes up more space if it&#x27;s clearer to understand what&#x27;s going on. However the size of a codebase in terms of its features and components is almost always directly correlated to the numbers of bugs you&#x27;re likely to find and the difficulty you&#x27;ll have maintaining it.<p>A problem I have at my current place is that the dev team in my opinion is far too happy to add new features whenever they&#x27;re requested. You know those kinds of requests that go something like, &quot;I basically want something that does exactly the same as [x] expect with this one small difference&quot;. When that happens few times it&#x27;s fine, but when it happens 100 times suddenly you&#x27;re managing a code base which is many times more complex than it needs to be with very marginal benefits.<p>And you might argue, &quot;well why don&#x27;t you abstract more&quot;. And that&#x27;s a lesson that took me about a decade of software engineering to learn - if you can avoid abstraction you should. Writing, $a = 2 + 2; is far easier to understand than, $a = math.sum($num1, $config-&gt;get(&#x27;num2&#x27;)); The need for abstraction should be seen as a code smell. That&#x27;s not to say you shouldn&#x27;t abstract when it&#x27;s the right thing to do, but if you find yourself needing to create abstraction on top of abstraction your feature set is probably needless complex.<p>A good engineer in my opinion isn&#x27;t one who can build things well, but one who is willing to say, &quot;no I&#x27;m not building that at all&quot; and even remove features that are being used if the cost of maintaining those feature are not worth the benefits they provide.