Do it well or don't do it at all

Earlier today, Ian Landsman shared his views about leaving features out of your product. He explains why he decided not to implement Web services support in v1.0 of his HelpSpot.

I agree with him on every point. But the point about limited integration of the feature into the product is IMO particularly important.
I am always careful about the good integration of features into appTranslator (or any other projects I've worked on) : Consistency and completeness are must-have or I'll drop the feature.

Consistency

Take Undo for instance. When I designed appTranslator, I figured users should be able to undo a translation they just typed. It happens that you select an item in a list, translate it, type then realize you did not select the right item in the first place. In such a case, Alt+Backspace (or Ctrl+Z) is welcome !
But if you can undo a translation in the string table, you expect to be able to undo in dialogs as well. And in the version info. And in the icons. And you expect to be able to undo the resizing of a dialog control. And the deletion of an executable module from the project,...

Completeness

What if you realize a little late that you're not translating the right items, say after you translated three of them ? You need to be able to undo the whole 3 of them. And you also need to redo if you incorrectly undid the last 4 translations.
And if you are in Items to be translated mode and you hit F5 (refresh) while typing translations ? These new translations are not displayed anymore. So when you undo, the item must appear again.
And if you switched to another resource, appTranslator must select the right resource again and select the item whose translation was undone !

Do it well or don't do it at all

As you can see, a small task as undoing the translation of a string quickly turns into... over a week of hard work ! There's very often a lot of sweat behind what seems an innocent little feature.

But it is necessary: Software must be comfortable. Users must feel they are in control. As much as possible, your program must behave as users expect. It must also help users do right things, which are not always the ones they want to do.

Consistency and completeness of features are must have to reach these goals. If that undo doesn't work as expected, users will get frustrated and they will quickly throw your program to the Recycle Bin, which in other words means : You LOOOSE !

You know what : You'd better not have implemented that lame undo in the first place because user simply would think : 'Oh! No undo ?'. Which is much less bad than 'I said Undo. Undo ! UNDO ! Why don't you just UNDO, you stupid program. Why can't you undo my typing HERE since you can undo it THERE !!!'

Clients requests are hard to manage

I used the Undo function to explain my thoughts because I wanted everyone to get my point, not only appTranslator users. But this 'do it well or don't do it' problem often comes as an e-mail from a client asking if I could add a little function that is so easy to do and would do a great job to help him workaround the lack of big feature X.

Of course, when it happens, you're tempted to say yes. After all, it would help many other people as well. But it would be only a part of the solution. It would work in many cases but certainly not all of them. And, more important : It wouldn't be clear to users where the limit is (I mean in which cases it works and in which cases it doesn't work). Which would mean to user frustation again.

My policy is to say no to such requests, or if applicable to say 'please wait until appTranslator has big feature X'. But I admit it's not always easy. And I sometimes wonder if it's the right choice.

A couple of days ago, I worked several hours to fix a bug that very few people would encounter (one so far) and for which I have a workaround. I fixed it because of consistency: 'appTranslator supports ActiveX controls in dialogs (an MFC feature)' does not have to read 'appTranslator supports ActiveX controls in dialogs (an MFC feature) EXCEPT if the control is first in tab order'

But of course, while I was fixing this bug (more difficult than it looks :-( ), no important feature was coded...