Saturday, July 26, 2008

Reusability Revisited

Reading an article just now, something sparked off a thought process. I remember talking my manager years ago about things in general and he came out with something like 'object technology never lived up to its promise of reuse'.

Apart from the fact that I disagree that object technology has anything to do with the reuse argument, his comments about reuse were (and still are) a sore point with some folk. Reuse has long since been a holy grail of software development. We long to be able to plug together components like those clever electronics engineering types do, so that we can drastically reduce the time it takes to build software.

To attempt to achieve reuse take time and investment, something most projects cannot afford. On every project I have worked, there was a targeted deliverable and on those where the IT staff lost sight of this, the results were disastrous. But even if the project was will to spend the extra time and money investing in an attempt to build reusable parts, what is the return on investment? I have no doubt it can be made to work - but when I have seen this, there has always been a price to pay - code is very often in worse shape after refactoring changes required to make it work in a second context.

So, even if we could (i.e. we have the funding and the commitment from the project) should we do it? There are only two scenarios here I can think of -
1. We build something to fulfill an expected need and try to design for all occasions
2. We build something that fulfills the needs of a real product and try to adapt it to other solutions

The problems with 1 are that we're in an endless assumption mode, we don't know when we're done because we have no sound business reason for building something and its impossible to foresee what real projects actually will need. While I favor item two because its grounded on reality and emerging needs, it's still often impossible to reuse that part on another project. The more coarse grained the component the hard it will be to reuse it - because business rules are always different across projects.

This brings me to the next point I believe that level of abstraction is key to reuse. If we build some software to manipulate lists, it is much more likely that we can reuse it than if we build a class to calculate commission for a salesman. Why should this be? There are basic building blocks in life that can be use no matter what. Bricks and mortar and other building materials can be used to build a large array of different structures, but a house or a kitchen cannot be used to build a shopping mall. The closer to a business domain software gets, the more specific to that particular solution the code becomes, because most people in business actually want to do things differently to their competitors - in the belief that they can gain advantage by doing so.

Reuse takes many forms. Software especially libraries and fine grained (typically technology oriented) APIs, tooling and platforms and skills. The single most import item from which reuse can be gained, is the brain, knowledge and learning should be foremost and everything else will fall into place.

1 comment:

kenbo said...

This post deserves more comment from me but family responsibilities beckon.

The software/IT industry has been selling the idea that the new technology will greatly reduce the need for programmers by reuse or replacement since the days of COBOL. My understanding is that COBOL (COmmon Business Oriented Language) was marketed with the idea that you wouldn't need programmers because it was so easy for managers to program. Hah! While that is certainly before my time it would explain the extreme wordiness of COBOL programs.

I've personally seen this kind of hype starting with CASE tools in the 80s. Those CASE tools were going to put all of the programmers out of a job because the managers/BA's would generate the code from the specs. Later, object oriented technology was sold as the magic bullet that would facilitate massive re-use of code and all the benefits that come from that (less programmers again!).

IMO the current overhyped technology is service oriented architectures. Like all of the overhyped technologies before there is real value for SOA in certain situations but most organizations are not going to see the benefit as it really isn't for them (think EJB's of the 90s).

Getting back to the reuse.. I think that we have tremendous reuse today compared to twenty years ago when the oo hype started. I almost never create my own data structures now becuse I don't have the memory constraints I used to have and the language libraries have most everything I need built in. Modern IOC frameworks like Spring make reuse easier by pushing developers to program to interfaces instead of implementations.

Thanks for sharing your thoughts on this.