{
    "href": "/post/2017/08/29/how-terrible-code-gets-written-by-perfectly-sane-people/",
    "relId": "2017/08/29/how-terrible-code-gets-written-by-perfectly-sane-people",
    "title": "How Terrible Code Gets Written By Perfectly Sane People",
    "author": "pmjones",
    "markup": "html",
    "tags": [
        {
            "href": "/tag/legacy/",
            "relId": "legacy",
            "title": "Legacy",
            "author": null,
            "created": null,
            "updated": [],
            "markup": "markdown"
        },
        {
            "href": "/tag/php/",
            "relId": "php",
            "title": "PHP",
            "author": null,
            "created": null,
            "updated": [],
            "markup": "markdown"
        },
        {
            "href": "/tag/programming/",
            "relId": "programming",
            "title": "Programming",
            "author": null,
            "created": null,
            "updated": [],
            "markup": "markdown"
        }
    ],
    "created": "2017-08-29 12:00:39 UTC",
    "updated": [
        "2017-08-29 12:00:39 UTC"
    ],
    "html": "<p>From <a href=\"https://chrismm.com/blog/how-terrible-code-gets-written-by-perfectly-sane-people/\">Christian Maioli Mackeprang</a>, the following:</p>\n<blockquote>\n<p>Legacy code can be nasty, but I\u00e2\u0080\u0099ve been programming for 15 years and only a couple of times had I seen something like this. The authors had created their own framework, and it was a perfect storm of anti-patterns. \u2026</p>\n<p>And yet, it was not the code\u00e2\u0080\u0099s dismal quality that piqued my interest and led me to write this article. What I discovered after some months working there, was that the authors were actually an experienced group of senior developers with good technical skills. What could lead a team of competent developers to produce and actually deliver something like this?</p>\n</blockquote>\n<p>I don\u2019t necessarily buy all of these, but they\u2019re worth thinking about:</p>\n<ul>\n<li>\n<p>Giving excessive importance to estimates: \u201cYour developers might choose to over-promise instead, and then skip important work such as thinking about architectural problems, or how to automate tasks, in order to meet an unrealistic deadline.\u201d</p>\n</li>\n<li>\n<p>Giving no importance to project knowledge: \u201cIf you\u00e2\u0080\u0099re in a large project and there are modules for which you have no expert, no-one to ask about, that\u00e2\u0080\u0099s a big red flag.\u201d</p>\n</li>\n<li>\n<p>Focusing on poor metrics such as \u201cissues closed\u201d or \u00e2\u0080\u009ccommits per day\u00e2\u0080\u009d: \u201cWhen a measure becomes a target, it ceases to be a good measure. (Goodhart\u00e2\u0080\u0099s law)\u201d</p>\n</li>\n<li>\n<p>Assuming that good process fixes bad people: \u201c[Fix your hiring.] Talent makes up for any other inefficiency in your team.\u201d</p>\n</li>\n<li>\n<p>Ignoring proven practices such as code reviews and unit testing: \u201cRefraining from using tools such as modern IDEs, version control and code inspection will set you back tremendously.\u201d</p>\n</li>\n<li>\n<p>Hiring developers with no \u00e2\u0080\u009cpeople\u00e2\u0080\u009d skills: \u201cIt doesn\u00e2\u0080\u0099t matter that the other guy might be ten thousand miles away. One Skype call can turn a long coding marathon into a five-minute fix.\u201d</p>\n</li>\n</ul>\n<p>Conclusion? \u201cWhat you can\u00e2\u0080\u0099t assume is that just because you\u00e2\u0080\u0099ve signed up to apply Agile or some other tool, that nothing else matters and things will sort themselves out.\u201d</p>\n"
}