Tuesday, November 28, 2006

Optionitis can kill if left untreated...

If you've been around these parts for a while you've probably heard the above reply to common feature requests. Many times these requests are at odds between several groups of users.  So their typical solution to this impasse is the ever so simple,  “Well, then just make it an option.”  I'm sure there have been those who've scoffed at my response and put me in the “closed-minded-dolt” category ;-).  Well it seems I may have gained a little vindication.  Apparently “Joel on Softwareseems to agree.  One could certainly argue that development tools are targeted at a different level of user than Windows itself or your typical word processor or spreadsheet application.  To that I say, why?  Why do development tools have to have a million and one little options for this and that?  We already have different and keybindings, tabs on, tabs off, auto indent on/off,  code completion on/off, etc...  There are a lot of end user reasons to limit the options as Joel so deftly does in a somewhat comical fashion to that faceless team of individuals working on the “start menu.”

However, there are also a lot of practical development side reasons to limit the choices as well.  Many times, just the simple act of adding a single on/off boolean option actually can double your testing efforts!  Ok, that was probably a bit of hyperbole, but it will double a portion of your testing effort.  So now you have to test everything related to that option with it on and with it off.  Add another option, and you're quadrupling the effort.  Think binary here.  In practice there are plenty of relatively safe testing “shortcuts” and ways to minimize that impact.  My point here is that glibbly introducing an optional new feature because “those 5 people I talked with last week said it was a good idea,” is probably not the most responsible thing to do.  Sure, for smaller applications targeting smaller markets, you do have to try and cater to as many as you can.  However, I've seen many, many cases where a better and workable, non-optional solution to a problem (or more appropriately a class of problems) is born out of a whole aggregated class of similar problems.

So when you're asked to “just add this little new feature,” and are inclined to make it optional, just step back and consider whether or not there are other problems within this particular class.  Is this new option worth the extra testing burden?  Is the feature useful to a wider cross-section of your customer base, so maybe it shouldn't be optional but always enabled?  Don't use the option as a “get out of jail free card.”  Sure, if customer X says they just can't stand that feature and you can reply with a simple, “Just turn it off.”  You sure dodged that bullet... or did you?  What if there was some use-case that that customer brought to the table that you had not considered?  Adding an option should not be used as an excuse to not have to thoroughly think through a problem.  Consciously or not, many times that is what is happening.

So for now, I'll still hold that “Optionitis can kill if left untreated.”  Now... at some point we still have to add that error message, “Programmer expected...”


  1. You already suffer from that quite badly in Delphi, partly because some of the options are not well thought out. Just going CTRL-O O will dump 30-odd options into your code to give you an idea of most of the editable options that have been applied. Many of them could most kindly be described as legacy (build code for a 286 with no maths copro... when did that last matter to me?) This is useful when you have library code from other people where their options don't match yours. Common ones are "assignable constants on" and "typed pointers off". Both of which make perfect sense... for a non-typesafe language.

    Of course, the product *I* work on has no irrelevant options... all 15000 of them are critically important.

  2. Joel's rant about too many options, and this one backing it up, don't live in the real world.

    When you're fighting for contracts, and the potential customer would buy your software if it had one simple addition, it isn't at the whim of the developer to decide not to include the option simply because it looks like too much hard work to test.

    Like Word and Outlook, my company's software is full of too many options that would scare you off, but it is a large back-office application that has to deal with many different industries and these options actually make it one of the most flexible pieces of software in its class.

    Sometimes developers talk an ideal world, when the reality is very different.

  3. I do not think we suffer from that in Delphi. What about Together support and Error Insight? Only since both are optional I dare to agree that BDS 4.0 "works".

    If you get "double effort" when a single Boolean option is added, you probably should search your code for architectural flaws.

    Not options should be controlled, but a software development mood that pushes logically incomplete code into production. When being fixed, it may start looking optionitistic.

    For example, there are many color options in BDS 4.0, but it is still impossible to make it look exactly as I want. Should CG remove color options or add centralized color scheme?

    Would an option to show a dialog box with buttons labeled other then Yes and No without patching the VCL hurt?

  4. Allen, is this your way of trying to weasel out of making the Backspace Unindents work with Tabs in BRIEF mode? <gd&r>

  5. Folks,

    I never said that we're exempt or perfect in this regard. And options, do help in certain circumstances. I was merely pointing out that one should really think through a problem before concluding that an option is the only way to go.

    And, Randy, what Backspace Unindents problem? ;-o

  6. Blog from the Programmer who worked on the Vista shut-down menu.


  7. Consider this. IDE today suffers not to much from the extra or missing options but rather not being well structured to be extended.

    If you can start from the roots and make IDE (or whatever) being customizable from the root up, and not from the what is here down, then extendability and customization of it became much easier. Make it true modular space with very thin core, then start to add stuff, not remove it. Then testing became a matter of integration and not a downgrading.

    OTA itself is a great thing, but when it is not a core but rather a layer, then you are facing a problem of reshuffling of the code when it could be really a regrouping.

  8. Impatient Delphi LoyalistNovember 29, 2006 at 2:28 AM

    It has been 2 weeks since the birth of CodeGear. What I cannot comprehend is why all you have in your website is "CodeGear = TCompany.Create()". Is that the best you can come up with? Was Borland's decision to create a subsidiary a last second thought before November 14? You guys must have been given at least a few weeks notice. You could have laid out a roadmap and communicated a mission statement to your customers and investors on your website the day that happened. You don't have that much time left. JPMorgan downgraded your stock and Nasdaq sent you a delisting notice. These are bad signs. Common guys...move in Internet time!


  9. Gods forbid we actually get to use software the way WE want to use it.

    I have no problem with coarse settings available for most users, but eventually I want to be able to fine tune a few settings.

    Frankly, the more decissions you end up making for me, the less I'll let you make decissions for me at all -> The first more flexible product that comes along in the same class and awaaaay I go.

    Maybe it doesn't make sense to give grandma word class features in notepad, but there are people who NEED word class features to do their job.

    We are developers, and frankly, we NEED a lot more flexibility than you provide already. I can't rememeber how many years people screamed for the ability to just get past the basic 16 colors in the IDE... Imagine if you left out compiler switches!

    You can buy any color you like, so long as its black isn't customer empowerment any more today than when Ford made it his policy.


Please keep your comments related to the post on which you are commenting. No spam, personal attacks, or general nastiness. I will be watching and will delete comments I find irrelevant, offensive and unnecessary.