Sponsored Link •
Bill Venners: My last question is about reuse. You have talked a lot about reuse, and seem to value reuse. I find that I reuse classes all the time in standard APIs, but that in the context of everyday programming tasks, it's often a better approach in my experience to solve the specific problem. In their everyday programming tasks, how much should programmers worry about reuse of the components or pieces of software they are building?
Bertrand Meyer: That's a very good point. I think it's really not a problem for the programmers. It's really a problem for the businesses, for the corporations. That is to say, if you are a programmer working in the usual conditions of typically a lot of stress, pressure, and deadlines, then it can actually be detrimental to focus too much on making your software reusable. You may even be accused of not doing your work properly, and that accusation might be in part at least justified. Your job is to produce is a set of products by a certain time at a certain price with certain functionality. That's what you have to do, and reuse can wait. Reuse is usually not part of the specification.
Of course, you should be a good programmer. You should do things carefully. Contrary to what I think the XP people are saying—I may be misinterpreting here, but I think it is a major point of disagreement I have with XP—if you have a way to do something more generally and another way to do it more specifically, at roughly equal cost, you should always try to do the more general solution. So you should always think about reuse, but really it would be improper in many cases to make something reusable. You would not be fulfilling your duty to the group and to the corporation if you were spending too much time on generalizing for future benefit as opposed to the immediate benefit of the project.
It's really in the end a question for the corporation. Does the corporation want to spend a little more money and time on generalization once the product has been delivered or the milestone achieved? I think I understood only recently the difference between this and the idea of refactoring. A few years ago I published a book called Object Success, a presentation of object technology for management, in which I talked a lot about reuse. In particular, I pushed this idea that the software lifecycle should allow for an explicit step of generalization. The idea I think is very simple: put management in front of its responsibilities. Many companies that will say, we don't have the time to do this. We just want to deliver a product, and we don't have time for any extra effort to generalize the software. It's not part of our charter. And I would say, that's fine. It has the advantage of being completely open and frank and conscious, as opposed to the unconscious decisions that are far too often made in software environments.
On the other hand, I think that a more progressive and forward looking software environment would say, yes, we are going to devote a small but reasonable part of our project, five to ten percent, to make sure that after the project is delivered we not only clean up the code but perform some generalization to prepare for the next project, to prepare for reuse. I think in the end that will be more effective than constant refactoring. First you meet your deadlines, and then you have a period of your work that is officially devoted to making things better. Then you do the refactoring, but with a specific focus on reuse. That refactoring is an official part of your job description, not something that you do on the side, almost hiding it from your manager, pretending that you're working on some other project In the end I think it's a management decision. Are you are you not willing to spend more in order to not only deliver to your customers and users what they expect now, but also to provide for better software development in the future. It is fundamentally in a business decision.
Come back Monday, March 15 for the first installment of a conversation with Luke Hohman. If you'd like to receive a brief weekly email announcing new articles at Artima.com, please subscribe to the Artima Newsletter.
Bertrand Meyer is the author of Object-Oriented Software Construction, which
is available on Amazon.com at:
Bertrand Meyer's Home Page at ETH, the Swiss Institute of Technology:
The Grand Challenge of Trusted Components, presented by Bertrand Meyer at the International
Conference on Software Engineering, May 2003:
The Structure and Interpretation of Computer Programs, by Harold Abelson and Gerald Jay Sussman
with Julie Sussman:
Find out more about Eiffel at:
The Eiffel language FAQ:
The 2001 Interview with Programming Expert Bertrand Meyer in InformIT:
(Gratuitously long URL omitted...)
Design by Contract by Example, by Richard Mitchell and Jim McKim:
Object Success: A Manager's Guide to Object-Oriented Technology And Its Impact On the Corporation, by Bertrand Meyer: