Subject: RE: angry Why must have Domino developers reinvent the wheel?
I too, before I joined IBM, had noted that there were a lot of features for which the code already obviously existed, that just werenāt being exposed for developers to use.
Now that Iām a member of the Lotus development organization, I can see why that happens. Itās really a matter of cost/benefit analysis.
We have only so many developers, testers, support staff and tech writers available to turn something into a developer-usable feature. On the other hand, we have a practically unlimited supply of feature requests.
If you havenāt done it, it might not seem obvious, but implementing something as a programming language feature requires a considerable amount of time and effort, over and above the time and effort involved in doing it one time to work in a specific situation internally.
You have to plan exactly how the feature is going to work, and not make a mistake. It has to continue to work the same way going forward, to be supported in all future versions. The planning effort may be significant, because you have to hear from the sort of people who need to use the feature, consider their input, and come up with something thatāll be acceptable to as many as possible.
You have to formally spec out how the feature will work, so that the testing group ā a different set of folks ā will have a basis to create test cases.
You have to create the test cases. The test cases for a language feature must be much more thorough than for internally used code, because we can predict exactly how internal code will be used. The only thing you can be sure of when you add something to LotusScript is that developers will use it in ways you never intended nor foresaw.
The developers have to review the test cases to make sure they provide good coverage.
You have to be prepared to execute them against all future versions of the product, and to hold back release of the product if the feature breaks, until itās working, so as to avoid crunching existing applications.
You have to document the feature, which involves a third group.
You have to be prepared to support the feature forever, which may involve training support staff, writing support procedures and technotes, or even adding support staff indefinitely. You must be prepared for the increased volume of service calls that will result from people trying to use the feature for the first time, who have either not read the documentation, or have read without comprehension (or when the documentation was in error or incomplete, as very occasionally happens).
Given the amount of planning and effort that has to go into making a capability into product, the development managers have to make a tough call for any feature thatās being contemplated. They have to consider not only the cost/benefit ā are we going to make back in increased sales/customer retention what we spend on this feature ā but also the opportunity cost. If we set our people to work implementing this, what other possibly more valuable features and bug fixes will not get into the product in time for the next release? Itās not like weāre sitting around looking for something to do here.
As a developer, you have a particular perspective on the product that differs from that of our development managers. Your feedback is important, as also is the feedback of administrators, IT managers, and the business people who actually make buying decisions. In fact, customer feedback is considered more important in this regard than suggestions from IBMās developers. You guys are out there on the front lines; you know what you need better than we do. I can put in a suggestion that this be considered as a feature (or add your input to it if the feature is already in consideration), but my suggestion doesnāt carry much weight unless a customer is making the case for it. If you can make a good business case for the addition of this feature, I will put in the feature request, but you have to be the one to make the case ā I canāt speak for you. You can send me email about it if you wish.
Put yourself in the position of an IBM development manager who will make the decision, and frame your arguments in terms that are meaningful to IBM from a business standpoint. Keep in mind that these people try to put themselves in our customersā shoes to figure out what will sell. It may seem obvious to you that a particular feature is very desirable, but you have to make the case that thereās a decent-sized audience for it besides yourself personally, that would make it more important than other things we could spend our time doing.
For instance, is there a particular class of application, with at least moderate business value, that canāt be done without the feature, or that would be doable with much less effort? One of our big selling points for Domino is that the development time is less for a comparable application, than for our competitors who shall not be named. Increasing our lead in this department would probably help our sales. Or, if thereās an application that our customers are paying for now, that they could develop in Domino (or get from OpenNtf.org) if only the feature was available, that reduces TCO, another selling point. If the feature would allow the development of applications that are easier to use than is now possible, that increases end user satisfaction and productivity, which is also a selling point for our customers.
You might not get what you want ā there are a lot of people arguing for their requests, and the managers canāt go along with all of them ā but all of us Lotus developers are putting in overtime developing stuff that we hope and believe is going to be most useful to our customers.
Regards,
Andre Guirard
IBM Lotus Software
Domino Access for Microsoft Outlook team
guirard at us dot ibm dot com
