Code Renaissance is about building great teams and great software. By exploring best practices, team interactions, design, testing and related skills Code Renaissance strives to help you create the team and codebase that you've always wanted.

The Lie of Reusablity

The lie of reusability in software engineering is that modules and controls that are competently designed  are easily reused and that reuse will translate into increase productivity. Business people love this concept, which has ample examples in the physical world, because reuse should save time and time is money. So they push the expectation of reuse and increased productivity on developers who strive in vain to bring the myth to life. In practice though, reuse usually requires significant effort and the main benefit you get, at least the first couple of times something is reused, isn't increased productivity, it's increased maintainability.

Consider a simple textbox control (win-forms, asp.net, etc). It took thousands of hours of effort (adding together the planning, coding, testing and maintenance time spent on the control) to bring that level of reuse to your finger tips. It seems like a simple control, but it has lots of events and properties that make it work for everyone and behind those are a myriad of subtle and well thought out decisions that have perfected it for general reuse.

Anyone who has ever tried to do simple composite user controls for internal use can tell you that even that relatively minor level of complexity has can contain a host of hidden and unexpected problems. Ever purchase a user control from an outside vendor? Worked great didn't it... until you got past the basic cookie cutter code and tried to get it to work in you particular context with your constraints; under those conditions subtle little problems emerge and it often falls just short of what you want it to do. Now go hunt down one of those developers and ask how much blood, sweat and tears their team put into getting that control to that level of reuse.

The truth is when you build a module or control you have no way of knowing how or even if it will be reused. The best you can hope for is to follow best practices and to keep the code as clean and well commented as possible... anything else is wasted time. When you reuse it for the first time you now have a new context to code for and the code will have to be adjusted to work in that context and then refactored mercilessly to make the code clean again. In all likely hood the this work will take longer that the initial work on that item. In the next iteration if you're lucky you may get your first efficiency gain from reuse but adjustments will still need to be made.

One real danger in iteratively adjusting code for reuse is increased complexity. Each iteration will likely have new features and requirements that will have to be added to make it work in that context. The larger the code becomes the harder it will be to understand the code as a whole and the more work it will take to change it cleanly.

In some contexts ("okay now we need all but one of the fields to be read only and we also need 12 additional fields and one button added, but only here") it may be worthwhile to simply build a new control or module to handle that particular case. Yes there may be some code duplication, which you may or may not be able to refactor it our into a common module, but everything in software is a trade off. You'll have to ask yourself which hurts you more (makes things less maintainable), the code duplication or the loss of cohesion and added complexity?

Of course if you're a developer who's been around a while you've likely already been through all this, perhaps wondering what you're doing wrong that the dream of reusability isn't working for you. The truth is you're likely not doing anything wrong... reuse can be a worthwhile endeavor but in all but trivial cases it's going to be difficult.

0 - What do you think?: