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.

This entry was posted in Uncategorized and tagged , . Bookmark the permalink. Follow any comments here with the RSS feed for this post.

21 Responses to Charge for bad code?

  1. gregyoung says:

    @Chris

    You could still filter by category/assembly/etc

    Greg

  2. “Not sure I agree that it means I have no acceptance or integration tests. I may just be making the decision that developers don’t run them as they are changing code (unless they are working on them). We can still for instance run them on the CI server”

    If the differentiation for freemium vs pro version is it only runs affected tests as opposed to all tests in the solution, if every time I hit save in my IDE it would run my behavior tests and start spawning chrome windows I’d run away from this in terror. (I sure hope this wouldn’t be the experience you present to users initially)

  3. Dylan Lacey says:

    I love the idea. I think that’s a great way of doing it… And I still wouldn’t implement it.

    People have a habit of thinking they’re “Special”, businesses are especially prone to it. So they’ll hear that they have to pay for things because they have bad code, and they’ll rationalize it away because “We have to have a big build with extensive tests because otherwise we can’t finangle the reversed finnigan dohickey! That’s our core business strength!” and then will be pissed at YOU for charging them and claiming there’s something wrong with their business model.

    Totally irrational, and annoyingly common.

  4. gregyoung says:

    Not sure I agree that it means I have no acceptance or integration tests. I may just be making the decision that developers don’t run them as they are changing code (unless they are working on them). We can still for instance run them on the CI server

  5. If those are the features you want to make the pricing about between the freemium vs pro versions that is fine and all. However I would strongly recommend never marketing it along those cigarette tax lines. That just seems to be a sure fire way to reach minimal commercial adoption.

    One of your key premises in this post “If your tests are fast”, this is just a pretty invalid argument. If your tests are fast it clearly means you have zero/minimal integration and/or automated acceptance tests. So opening the premise that organizations that are doing full stack testing somehow need to pay your “cigarette tax” seems like something that will rub many people the wrong way. It did to me personally but I take very little serious except my work so something like this in no way truly impacts me, but I feel others could be put off by these remarks.

  6. Dathan says:

    It’s an interesting idea… It’s risky, though, and here’s why. It’s still the same ol’ freemium model, and your paid customer demographic is conceptually the same — i.e., customers that need premium eatures — but the demographic is *functionally* different. It’s “developers who aren’t disciplined enough to write well-factored, quickly-testable, fast-building code,” instead of “power users who want the marginal value added by premium features enough to pay for it.” Because of that, you’ve sort of inverted the freemium model, by rewarding already-productive developers with a free productivity tool. And, since I think of myself as a good developer, I like that. However, nobody wants to admit that their codebase is ugly, and I think you’ll get fewer paid customers this way. You basically convert purchasing your software from an act that you can almost be proud of (“I’m a good developer; I need *premium* features”), to a walk of shame. i.e., however awesome and genuinely useful your product is, purchasing it under those terms is tantamount to a confession of professional mediocrity — and that doesn’t strike me as a good business model.

  7. Ruben Steins says:

    Sounds like an awesome way to promote both your product and writing good code. You’ve got my vote!

  8. Matt says:

    Short version: I like it.

    Long Version: It sounds like a reasonable idea to me. It doesn’t really sound much different than the “free” and “pro” app versions you see on various mobile platforms, except you’re approaching the decision to go that route from a different angle. It sounds like your angle tries to make the cost of technical debt real right now instead of just through compounding opportunity cost. The former forces you to make a decision now while the latter simply keeps growing until it consumes you and you have to make harder choices.

  9. I think an important point is: how much will the full version cost? (I was unable to find that on the site.) I would love it if there was a free version, of course, but I’d still like to know how much you’re thinking of charging.

    In any case, +1 for a “lite” version.

  10. Jacques says:

    I love the innovative model. I think this might have the potential of promoting MM adoption significantly.

  11. flukus says:

    How will that play out from a business perspective? I’d have thought this that need it most would be the least likely to pay.

  12. Lars Mæhlum says:

    This sounds really good.
    Any excuse to punish bad code is a good thing in my book :)

  13. This is a great idea! I wish more developer tools did just that! Go for it.

  14. Mike Murray says:

    Guys, you have a problem with comments. After I posted the comment and got message that it’s awaiting moderation, the form was populated with Mike Murray’s data, including email.

    Iaroslav

  15. Iaroslav says:

    I like the idea a lot. This looks like Visual Studio Express edition, but better.

  16. Mike Murray says:

    Do it! Absolutely brilliant.

  17. Josh says:

    While I would love to see this as a pricing model, mainly because I think Mighty Moose looks fantastic, I think you are making an erroneous assumption.

    In my experience the people who want to use a product like Mighty Moose are already practicing TDD… and therefore wouldn’t really have need of those features anyway. People who aren’t actively applying TDD to their work don’t even see the value in Mighty Moose to begin with.

    It’s a novel idea… I just think your target market probably doesn’t even know Mighty Moose exists.

  18. Andrew Benz says:

    I think it’s an interesting idea; however, I think that the people that would need it most may be the people that are actually least likely to pay for it. Or they’re working for companies that wouldn’t see value in it, as evidenced by the fact that they don’t seem to see value in writing better code.

  19. Nate Taylor says:

    My main concern with this model is the perception of Mighty Moose for the people writing bad code. What I mean is, if someone downloads MM and writes bad code, will their first impression of MM be positive or negative? If it take a long time to run because their code is bad, which is more likely that they take ownership of the issue or that they say “I tried Mighty Moose, it sucked. Increased my build times by 2 minutes.”

    That said, I like the idea of innovative pricing. I hope that I’m writing good enough code that I don’t need the extra features (haven’t needed them yet.)

    Just wanted to throw out the observation that you guys might get blamed for slow execution, even when it’s not your fault.

  20. Mike Wilson says:

    One issue to consider with the “ideal” here is many non technical managers still think they can buy their way out of trouble – more tools, more inexperienced developers. So while the grunts using MM would clearly see the benefit in using it properly with or without the cost savings, in many cases it would be out of their hands.

    In the longer term it might wprk put as team leads who are runnong a toght ship have a lower barrier to entry, can learn the tool, and later transplant it to a newer team as part of an improvement program.

  21. Khalid Abuhakmeh says:

    I would probably just call it the pro version rather than the “you totally suck at the coding” version. You might not want to insult the people you are trying to sell to.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>