1 Million Dollars to Succeed

Let me ask you a question.

How would you develop your next software project if I told you that if you “succeeded” you would be given $1 million dollars, but if you failed you would get nothing?


Success of course is a very fuzzy term, but let’s assume that success means:

  1. You built a working functional product
  2. Your customers are happy with it, content enough to call it done
  3. You delivered it on time
  4. You delivered it within budget
  5. It can be fairly easily modified and maintained with its current design for the next 5 years.

This is an all or nothing proposition.  Everything is on the line.  If you were to succeed, you would be rewarded handsomely, but if you fail, your effort would be entirely wasted.

Oh, also, you can’t work more than 8 hours a day 5 days a week—no winning by heroics alone.

Why ask this question?

Simple, because after thinking about “how to build software” for the last 10 or so years, (in my beginning years, I didn’t really ponder this question) I have decided the answer to this question is the way that software should be built.

I don’t mean that developers should be given an all or nothing proposition.  What I mean is that we should be building and designing software as if I proposed the above situation.

This might sound a bit crazy, but think about it for a bit.

Most developers today are paid a salary.  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.  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.

Losing all the time we put into the project and losing out on an opportunity to make a million dollars would be some consequence.

We’d think about software development quite differently


It’s really hard for me to answer the question of whether or not practices like TDD are worth it.  I mean sure, I tell my manager it is.  I emphasize quality over speed.  I say we need to do this or that, but honestly I don’t really know.

I’ve never been put to the test.

No one has ever said to me, “succeed or die.”

No one has ever put the consequences of my choices directly in my own hands.

Never have I actually had to weigh the weight of extra time spent refactoring code, writing unit tests or using an ORM instead of writing SQL directly in my source code.

I choose technologies because they seem good to me or it seems like they’ll help me get things done faster, but I am never really staking much on that choice.

Sure, I may be staking my reputation, or I might lose my job, but chances are I’ll just blame some failure on some other reason or worse yet, I won’t even recognize my failure, because it will be disguised by “good enough.”

“Man, John, you are a big fraudulent a-hole!  I can’t believe you go around touting to know stuff, leading people down paths that you yourself don’t even know are correct.  Burning up other people’s money in your test lab of software development.”

Maybe it’s true.  Maybe I am a big ignorant and arrogant jerk, but somehow I feel that I am not alone.

I’m not saying we don’t or shouldn’t have strong convictions.

I’m not saying that we don’t have good reason to believe the development methodologies and practices we suggest and follow are correct.

What I am saying is…

Our beliefs about software development are mostly theoretical


8 years ago I would have told you that you needed to create UML diagrams before you write any code.

5 years ago I would have probably emphasized the importance of always having an XML schema.  I would have told you data without schema is meaningless.

I don’t hold either of those views today.

Perhaps you’ve changed your views in the past few years as well?

The 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’t, we are basing the results on OUR motivations not the motivations of our customers or our employers.

So, we may eventually get good at making things easier for ourselves, but unless your feet are held to the fire, you’ll never really optimize for building the best software as efficiently as possible.

If 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’t 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.

What about startups or open source projects?

You might be tempted to think that working for yourself or not for money at all would change things, but I’m really not sure that is the case.

I’ve worked on plenty of my own software projects where my fate was directly in my hands.

I’ve built applications like PaceMaker where my financial success with the endeavor was directly tied my own efforts and my efforts alone.

But, do I think I built PaceMaker as efficiently as possible?

No, definitely not!

The problem with PaceMaker and other projects where there is a big potential upside, is that the upside potential is not guaranteed.

I 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.

I’m 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.

What 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.

What can we do about this?

Now I can’t tell you how I would have built PaceMaker had I been given the million dollar challenge.

There is no way that I could objectively put myself into that situation and give you an answer.

Would I have bothered with unit tests?  Would I have have created backlogs and written UATs to make sure they pass?  Would I have used an IoC container?

The plain and honest answer is, I don’t know.  All I know is that I would have done things differently and on any software project you’ve worked on, you probably would also.

There are a few things we can gather from thinking about this hypothetical proposition.

  • Don’t think you know the answer, but at the same time have convictions about what you currently believe.  Just hold on to those convictions loosely.
  • Even though you can’t realistically be completely objective and build software as if someone was going to pay you 1 million dollars (just like you can’t tickle yourself) you can still try to think as much as possible with this mindset.  It is a worthwhile exercise to imagine as if the decisions you are making and the convictions you are holding onto are based on idealism or reality.  We could also all examine and at least understand our own motivations.
  • Recognize others are in the exact same boat you are.  Don’t believe everything an expert says or even believe there are experts.  Experience and wisdom count for something, but no one has anywhere close to all the answers.

I’d love to see this experiment actually played out.  I’d really be curious to see what the outcome was, especially in a team situation.

Perhaps someday, someone will actually conduct this experiment and share the results.

What about you?  How do you think being given the million dollar challenge would change the way you develop software?

About the author

John Sonmez

John Sonmez is the founder of Simple Programmer and a life coach for software developers. He is the best selling author of the book "Soft Skills: The Software Developer's Life Manual."

  • http://gravatar.com/franjobrekalo FrenkyB

    “you can’t work more than 8 hours a day 5 days a week—no winning by heroics alone.” – for me, this seems quite hard demand. Very often I’ve found myself that I’ve come to something what I was doing in the work and fix that thing when I come home. Or before I go to work. Or during weekeng. Development is a hard thing to do only when you are on your work place.

  • http://about.me/tedmyoung Ted M. Young

    This is a great thought experiment, but, alas, is untestable because of the huge number of variables involved. However, it would be great if there was more testing (scientific experiments) of some of the variables, e.g., TDD, or ORM. They’d also have to be longitudinal studies, because you’d need to evaluate the maintainability of the code over time.

  • Brandon Blais

    If I were given a million dollar challenge like this I’d try to focus like a laser beam on functional requirements from the business’ perspective. I think Agile is particularly well suited for that task.

    I’d probably start with mockups and work my way front end to back end, following some variant of MVC with unit tests and dependency injection.

    I probably wouldn’t invest in an ORM. I’m not sure it’d be worth the learning curve.

    Am I 100% sure that I’m using the best methods possible? No. No one has perfect knowledge. I wouldn’t even try to get to the perfect solution, because then I probably wouldn’t get anything done. I’d be stuck in analysis paralysis. Perfect is the enemy of good.

    For me it all comes down to heuristics and anecdotal evidence. A large body of my peers has concluded that there are certain “best practices”. The ones that I’ve tried and I like, I use. I can’t say for sure that they always yield the best results, but my experience has been they’ve seemed helpful given the types of projects I work on.

    Once again you raise an interesting issue. From time to time I do think it’s helpful to step back, look around and ask: Am I doing this all wrong?

  • http://gravatar.com/cirellolaranjo cirellolaranjo

    Oh thank you. Last week I was talking about the “old new things”, like UML, XML schemas, RUP, and all others “fantastic” things that nobody remember.

    You are not alone. The problem is: The “church” will burn you because you are going against the “bible”. TDD? MVC? If you say you don’t like them you are the worst person in the world.

    Your career is at risk if you don’t “love the church”.

  • Pingback: Software Development Life Blog Carnival 11-14-2012 | Sisco1.com()

  • Pingback: The More I Know, the Less I Know « Making the Complex Simple()

  • Buddy

    Why not look at scientific data? Effectiveness of TDD http://www.people.vcu.edu/~bmurrill/courses/csc625/erdogmus05.pdf

    • http://simpleprogrammer.com jsonmez

      Awesome! Thanks for that link. I have not seen that study.

  • Richard Garand

    The downside of this approach is that it says nothing about the day after the project is done. Sure, we’ve all done a lot of things inefficiently in the past. But where would be today if we hadn’t taken a chance and tried something new (with the potential of failure) to see whether it was good?

    • jsonmez

      Yeah, definitely true.

  • http://www.theproactiveprogrammer.com/ Ronnie Mukherjee

    I love this idea. I think the two keys to my approach would be regularly meeting with customers for demonstrations and feedback, and having the technical design and architecture, along with the low-level code, reviewed regularly by the best people at my disposal. And if there really were a million dollars at stake, although I could only work for eight hours a day, I doubt I would be able to think about much else and I might not be able to sleep!