{"id":1290,"date":"2024-12-12T17:15:55","date_gmt":"2024-12-12T11:45:55","guid":{"rendered":"https:\/\/nocturnalknight.co\/?p=1290"},"modified":"2024-12-12T17:15:55","modified_gmt":"2024-12-12T11:45:55","slug":"how-to-measure-real-success-in-software-engineering","status":"publish","type":"post","link":"https:\/\/nocturnalknight.com\/?p=1290","title":{"rendered":"How To Measure Real Success In Software Engineering"},"content":{"rendered":"\n

Recently, while attending The Business Show<\/a><\/em> in London, I engaged in a conversation with a CXO of an upcoming Fintech company. The discussion began with cybersecurity implementation\u2014a topic close to my heart\u2014but quickly veered into the realm of engineering throughput. What followed was an incoherent rant by the CXO, a frustrating narrative about firing their Delivery Director for refusing to scale the engineering team to meet deadlines for the company\u2019s next shiny event. Despite my best efforts to pull this gentleman out of his rabbit hole, my time and reasoning seemed to fall on deaf ears.<\/p>\n\n\n\n

Reflecting on this interaction over the past month, I\u2019ve realized this episode was emblematic of a larger issue: the prevalent fallacy among CXOs<\/em> that more engineers equals faster and better output<\/strong>. Surprisingly, this misconception thrives in part because of the silence of engineering leaders<\/strong>\u2014CTOs, VPs, and Directors of Engineering\u2014who often fail to push back against flawed assumptions at the executive level.<\/p>\n\n\n\n

Inspired by my recent association with the Information Security Group (ISG)<\/a><\/em> at the Royal Holloway University of London<\/a><\/em>, I decided to don my “academic specs” and examine this fallacy more critically. The result is a deeper dive into the myths of scaling engineering teams, the science behind team efficiency, and a call for a cultural shift in how organizations measure productivity.<\/p>\n\n\n\n

The Scaling Myth: Why More Isn\u2019t Always Better<\/h2>\n\n\n\n

At the heart of this fallacy is a simplistic assumption: more engineers means more features, delivered faster<\/strong>. While this notion seems logical, it is disproven by Price’s Law<\/strong>, a principle that exposes the diminishing returns of team scaling.<\/p>\n\n\n\n

Rediscovering Derek J. de Solla Price: From Antikythera to Engineering Efficiency<\/h2>\n\n\n\n

My journey to understanding Price’s Law<\/strong> began with a fascination for the Antikythera Mechanism<\/strong><\/a> \u2014an ancient Greek marvel of engineering and astronomy. It was through this mechanism that I first encountered the work of Prof. Derek J. de Solla Price<\/strong><\/a>, a British physicist and historian whose curiosity and intellect extended far beyond antiquities. Inspired by the ingenuity of the Antikythera Mechanism, I was drawn to explore the origins of Damascus and Wootz steel<\/strong><\/a>, and its roots in the south-western peninsula of India<\/strong><\/a> (as detailed in Aayutha Desam<\/em> by R. Mannar Mannan<\/a>). (More about that in another post!)<\/p>\n\n\n\n

But it was Price’s insight into the uneven distribution of productivity in groups<\/strong> that struck a chord with my work in software engineering. His principle, now widely known as Price’s Law<\/strong>, asserts that in any team, 50% of the work is accomplished by the square root of the total number of participants<\/strong>.<\/p>\n\n\n\n