Charge for bad code?

So let’s throw out a quick idea that we have batted around a bit internally. What if Mighty Moose were to be free? What if we were only to charge you for two features inside of the software that are not needed if you are maintaining a decent code base?

The basic idea is if you write good code, you will never need these features and thus Mighty Moose will be free for you (We will even throw in support!). If however you need these two areas you will pay for them.

The two areas in question are the minimizer (the thing that figures out which tests to run) and the cascading + incremental compilation build providers. If your tests are fast and your builds small, mighty moose is painless to use without these features. You would still get graphs, sequence diagrams, all the unit testing frameworks, gary etc. Its just it would build your solution and run “all” your tests (you could still use ignore + ignore categories etc)

We could look at this as being similar to a cigarette tax (cost shifting). We provide people with good code the tool for free by charging people who need the features that help them in bad situations. There is also a large support cost difference we have measured (quite similar to smokers using up more medical resources). We would be helping push you towards doing the right thing. We would of course also provide you guidance about how to fix these issues in your system. If however you choose to take the easy way out and have the tool alleviate your pain, there would be a cost associated with that decision.

From a managerial perspective we are also giving you a bit of ammunition. I can make the case very easily as to why these two problems are very expensive within an organization. This would provide setting a cost to one solution that can then be used in further decision making. From an options pricing model perspective we are pricing the option of not resolving the issues now.

I understand that this is a fairly innovative idea and may seem odd to some people at first so I wanted to drop it up here as a RFC to get some feedback.


  1. Posted March 27, 2012 at 5:30 am | Permalink | Reply

    Smokers already get taxed heaps. Why should we pay more for cigarettes? ๐Ÿ™‚

  2. Posted March 27, 2012 at 5:47 am | Permalink | Reply

    I think it’s a fair deal. Promoting good practices and giving an extra incentive to get better for those who are not there yet. I’d personally accept such a deal.

    Too bad it’s not for Java world ๐Ÿ˜‰

  3. Posted March 27, 2012 at 7:23 am | Permalink | Reply

    My immediate reaction is that people who are so interested in testing they want to do it continuously are probably not going to be writing “bad” code. And if they are, say for historical reasons, stuck with bad code, then they will most likely be highly motivated to fix it.

    Sort of like charging people who run marathons extra for a gym membership so that you can offer a discount to people with full service cable packages and an ez-boy recliner with built in ashtray and beer holder. To stretch the analogy beyond breaking point ๐Ÿ™‚

  4. Posted March 27, 2012 at 8:04 am | Permalink | Reply

    But aren’t you worried that this will make everyone start writing good code and no-one would need to bu….pfftaaahhahahahahha.. sorry, couldn’t resist..

    I think it’s a very interesting idea. The possible problem I see is that you need to make it very clear that the paid version would solve those issues. Otherwise you’ll have a free version that just feels like it is too slow, and no-one will want to buy that. Perhaps free version + a 30 day trial of paid?

    • Posted March 27, 2012 at 8:07 am | Permalink | Reply

      I would be ecstatic if nobody had need for those features. Our main goal with mm is to enforce good practice and change how people work.

  5. larsicus
    Posted March 27, 2012 at 8:23 am | Permalink | Reply

    I tried running even small projects with AutoTest.Net which does more or less that. Granted it was half a year ago, so performance may have improved, but even with smaller projects I’d appreciate running just one or a few test(s). That was without integration, only small unit-tests.
    We usually have multiple projects in a solution, and some might have references to assemblies on the network, or check nuget for updates. That makes build times slower. So a crutial feature would be “build just this assembly and the one without loads of references that I’m testing, and then just run the affected tests”.
    I’d preorder to get a beta key and use that feature today. ๐Ÿ˜‰

  6. Posted March 27, 2012 at 11:04 am | Permalink | Reply

    Can MM be friend and I pay for Code Line Coverage. ๐Ÿ˜€

    (no I don’t think I’ll let this debate die) haha

  7. Posted March 27, 2012 at 11:05 am | Permalink | Reply

    Wow I should proof read before hitting submit.

    That was meant to be:

    “Can MM be free and I pay for Code Line Coverage.”

  8. multifariousguy
    Posted March 27, 2012 at 1:34 pm | Permalink | Reply

    I love the idea that the free version of the tool could be used as ammunition to support an argument to the brass that it really will pay in the long run to let us take the time to go back and fix the (GOBS) of poorly built legacy code that we are currently stuck with but not given time to properly refactor. I also like the idea that if I start to get lazy on any new code/refactorings that MM will never let me forget it by getting slower and slower. Knowing I’m lazy, I appreciate tools that cattle-prod me into motion again.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: