{"id":1744,"date":"2012-11-10T13:09:19","date_gmt":"2012-11-10T20:09:19","guid":{"rendered":"https:\/\/simpleprogrammer.com\/?p=1744"},"modified":"2018-02-23T11:43:05","modified_gmt":"2018-02-23T16:43:05","slug":"1-million-dollars-to-succeed","status":"publish","type":"post","link":"https:\/\/simpleprogrammer.com\/1-million-dollars-to-succeed\/","title":{"rendered":"1 Million Dollars to Succeed"},"content":{"rendered":"

Let me ask you a question.\\n\\nHow would you develop your next software project if I told you that if you \u201csucceeded\u201d you would be given $1 million dollars, but if you failed you would get nothing?\\n\\n\"money\"<\/a>\\n\\nSuccess of course is a very fuzzy term, but let\u2019s assume that success means:\\n\\n<\/p>\n

    \\n <\/p>\n
  1. You built a working functional product<\/strong><\/li>\n

    \\n <\/p>\n

  2. Your customers are happy<\/strong> with it, content enough to call it done<\/li>\n

    \\n <\/p>\n

  3. You delivered it on time<\/strong><\/li>\n

    \\n <\/p>\n

  4. You delivered it within budget<\/strong><\/li>\n

    \\n <\/p>\n

  5. It can be fairly easily modified and maintained<\/strong> with its current design for the next 5 years.<\/li>\n

    \\n<\/ol>\n

    \\n\\nThis is an all or nothing proposition.\u00a0 Everything is on the line.\u00a0 If you were to succeed, you would be rewarded handsomely, but if you fail, your effort would be entirely wasted.\\n\\nOh, also, you can\u2019t work more than 8 hours a day 5 days a week\u2014no winning by heroics alone.\\n\\n<\/p>\n

    <\/h2>\n

    \\n\\n<\/p>\n

    Why ask this question?<\/h2>\n

    \\n\\nSimple, because after thinking about \u201chow to build software\u201d for the last 10 or so years, (in my beginning years, I didn\u2019t really ponder this question) I have decided the answer to this question is the way that software should be built.\\n\\nI don\u2019t mean that developers should be given an all or nothing proposition.\u00a0 What I mean is that we should be building and designing software as if I proposed the above situation.\\n\\nThis might sound a bit crazy, but think about it for a bit.\\n\\nMost developers today are paid a salary.\u00a0 Some salaries have bonuses attached for performance, but rarely are we put in a situation where making mistakes or not being as efficient as possible results in dire consequences.\u00a0 The worst that can happen in most cases is that we would get paid for the work we did and then be looking for a new job at the end of the project.<\/strong>\\n\\nLosing all the time we put into the project and losing out on an opportunity to make a million dollars would be some consequence.\\n\\n<\/p>\n

    We\u2019d think about software development quite differently<\/h2>\n

    \\n\\n\"think\"<\/a>\\n\\nIt\u2019s really hard for me to answer the question of whether or not practices like TDD are worth it<\/a>.\u00a0 I mean sure, I tell my manager it is.\u00a0 I emphasize quality over speed.\u00a0 I say we need to do this or that, but honestly I don\u2019t really know<\/strong>.\\n\\nI\u2019ve never been put to the test.\\n\\nNo one has ever said to me, \u201csucceed or die.\u201d\\n\\nNo one has ever put the consequences of my choices directly in my own hands.<\/strong>\\n\\nNever have I actually had to weigh the weight of extra time spent refactoring code, writing unit tests or using an ORM<\/a> instead of writing SQL directly in my source code.\\n\\nI choose technologies because they seem good to me or it seems like they\u2019ll help me get things done faster, but I am never really staking much on that choice.\\n\\nSure, I may be staking my reputation, or I might lose my job, but chances are I\u2019ll just blame some failure on some other reason<\/strong> or worse yet, I won\u2019t even recognize my failure, because it will be disguised by \u201cgood enough.\u201d\\n\\n<\/p>\n

    \u201cMan, John, you are a big fraudulent a-hole!\u00a0 I can\u2019t believe you go around touting to know stuff, leading people down paths that you yourself don\u2019t even know are correct.\u00a0 Burning up other people\u2019s money in your test lab of software development.\u201d<\/p><\/blockquote>\n

    \\n\\nMaybe it\u2019s true.\u00a0 Maybe I am a big ignorant and arrogant jerk, but somehow I feel that I am not alone.\\n\\nI\u2019m not saying we don\u2019t or shouldn\u2019t have strong convictions.\\n\\nI\u2019m not saying that we don\u2019t have good reason to believe the development methodologies and practices we suggest and follow are correct.\\n\\nWhat I am saying is\u2026\\n\\n<\/p>\n

    <\/h2>\n

    \\n\\n<\/p>\n

    <\/h2>\n

    \\n\\n<\/p>\n

    Our beliefs about software development are mostly theoretical<\/h2>\n

    \\n\\n\"theory\"<\/a>\\n\\n8 years ago I would have told you that you needed to create UML<\/a> diagrams before you write any code.\\n\\n5 years ago I would have probably emphasized the importance of always having an XML schema.\u00a0 I would have told you data without schema is meaningless.\\n\\nI don\u2019t hold either of those views today.\\n\\nPerhaps you\u2019ve changed your views in the past few years as well?\\n\\nThe point is that even though we may be down in the trenches doing software development and to some degree finding out what works and what doesn\u2019t, we are basing the results on OUR motivations<\/strong> not the motivations of our customers or our employers.\\n\\nSo, we may eventually get good at making things easier for ourselves, but unless your feet are held to the fire, you\u2019ll never really optimize for building the best software as efficiently as possible.\\n\\nIf you think you already are focusing on building the best software as efficiently as possible and I am just full of crap and you don\u2019t operate that way, I would strongly suggest doing a thorough self-check and also please tell me the secret of the most efficient way to build software, because I definitely want to know.\\n\\n<\/p>\n

    What about startups or open source projects?<\/h2>\n

    \\n\\nYou might be tempted to think that working for yourself or not for money at all would change things, but I\u2019m really not sure that is the case.\\n\\nI\u2019ve worked on plenty of my own software projects where my fate was directly in my hands.\\n\\nI\u2019ve built applications like PaceMaker<\/a> where my financial success with the endeavor was directly tied my own efforts and my efforts alone.\\n\\nBut, do I think I built PaceMaker as efficiently as possible?\\n\\nNo, definitely not!\\n\\nThe problem with PaceMaker and other projects where there is a big potential upside, is that the upside potential is not guaranteed.\\n\\nI can assure you that if someone said to me that I have 6 months to build PaceMaker and if I succeeded (according to the rules I stated above) that I would be given $1 million dollars, but if I failed I would be given nothing, I would have probably gone about the whole process an entirely different way.\\n\\nI\u2019m not saying I would have built it with perfect efficiency, but my motivations would have entirely matched up with the footprint of building software as perfectly as possible.\\n\\nWhat I mean by this is that I would be trying as hard as I could to do what I absolutely believed was mostly likely to benefit me, and by doing so I would be trying as hard as possible to completely optimize the process of building that software.\\n\\n<\/p>\n

    What can we do about this?<\/h2>\n

    \\n\\nNow I can\u2019t tell you how I would have built PaceMaker had I been given the million dollar challenge.\\n\\nThere is no way that I could objectively put myself into that situation and give you an answer.\\n\\nWould I have bothered with unit tests?\u00a0 Would I have have created backlogs and written UATs to make sure they pass?\u00a0 Would I have used an IoC container?\\n\\nThe plain and honest answer is, I don\u2019t know.\u00a0 All I know is that I would have done things differently and on any software project you\u2019ve worked on, you probably would also.\\n\\nThere are a few things we can gather from thinking about this hypothetical proposition.\\n\\n<\/p>\n