DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
What's in store for DevOps in 2023? Hear from the experts in our "DZone 2023 Preview: DevOps Edition" on Fri, Jan 27!
Save your seat
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. Whatever Happened to Reuse?

Whatever Happened to Reuse?

Scott Westfall user avatar by
Scott Westfall
·
Mar. 26, 14 · Interview
Like (0)
Save
Tweet
Share
28.12K Views

Join the DZone community and get the full member experience.

Join For Free

A few years ago, I was in a meeting with one of my development teams, and people were discussing their recent contributions. One developer described a class he developed to do something or other, let’s call it the Foobulator. Another developer spoke up, saying, “Yeah, I wrote a Foobulator 3 months ago.” Yet another developer chimed in, ”I wrote a Bidirectional Foobulator about a year ago.” By the time we had finished, 22 of my developers described building a Foobulator with one who claimed he developed a predictive Foobulator with full transactional semantics and a priority queue back in 1943 as part of the Manhattan Project.

Now, it’s possible that this story has become exaggerated in the retelling. It does seem that there were only 10 people on the team and none of them were old enough to have worked on the Manhattan Project. Still, it’s not uncommon to find that multiple people on your team have written essentially the same functionality. Clearly this illustrates a lack of effective reuse.

In the 1990′s, reuse was one of the hot topics for developers. Object-oriented development was adopted in no small part due to the promise of greater reusability. Today, you scarcely hear anyone talk about it. Perhaps it is drowned out by the all of the buzz about agile. But what could be more agile–in a rapid development sort of way–than reuse?

I did a quick Google search for “whatever happened to reuse” and found an article by Steve Adolph on Gammasutra of the very same name from 1999. He defines what he means by reuse and the history of its pursuit. Now, 15 years later I’m asking the very same question.

I don’t feel the need to define reuse beyond saying it is the use of existing designs or code instead of writing something new. You may find articles about reusing variables, data structures, or other entities, but that is not what I’m talking about here. That’s more about code efficiency than programming efficiency.

When considering reuse, there are two key questions to ask:

  1. Why don’t people reuse existing code?
  2. Why don’t people write code in a reusable manner?

Reusing Existing Code

In some ways, reuse is more prevalent today than back in the ’90s. The Java Foundation Classes (JFC) and Microsoft Foundation Class (MFC) library provide large collections of reusable code. Along with the proliferation of 3rd party frameworks like Apache, there is more reusable code available. When I was a C++ programmer back then, there were few class libraries that we could use, and we had to write more code ourselves. Rogue Wave Software’s outstanding library, was an exception. It stands in my mind as a shining example of a well-crafted example for ease of use and clean interfaces.

But why don’t people reuse code written by their own team? Here are some common reasons:

  • Code is often not written in a reusable manner. Too often, it blends in case-specific functionality with the reusable functionality. You may find that you have to refactor existing code to make use of an existing element. That incurs a cost for retesting the refactored code and any code using it.
  • Locating reusable elements is difficult. Even if a reusable element exists, it may be named poorly or placed in the wrong package or library. Our codebases are larger than ever and not as carefully crafted as we would like. So, the number of candidates you may have to consider to find a reusable element is potentially very large.
  • Lack of documentation. Even if you can find a reusable element, it may be so poorly documented that you don’t fully understand what it’s doing and why. So, you may not want to incur the associated risks.
  • People may not feel that they have time to look for reusable code. Teams are so often under extreme milestone pressure. While it seems foolish to use more time to write something anew when an existing element already exists, time pressure forces people to keep their heads down and focus on things that are under their control, like writing the code yourself.
  • A reusable element  may require you to alter your design somewhat, which could impose a cost greater than the amount of time saved by using the element.
  • Reuse is often not as fun as writing it yourself. Coders tend to be proud and often feel disdain for other people’s code.
  • Apathy. Sometimes developers become so detached from the codebase that that they just don’t care about reuse or other architectural and design considerations.

Writing Code in a Reusable Manner

  • Writing reusable code takes effort. Whatever it takes to write something for a particular purpose, it takes more to write it in a reusable manner. Plus there is the overhead of properly documenting it. Further you have to find the right library to put it in so others can find it.
  • Time. The truth is, many developers can barely find the time to write something for their own use and have no extra time for this overhead.
  • Payback. The expected lifespan of code today is much shorter. People may not feel it’s worth the time to write reusable code when the whole thing may be rewritten or scrapped in a year or two.
  • Apathy. Again, sometimes people just don’t care.

Design Reuse

Even when there is decent code reuse, design reuse is often neglected despite the greater return on investment it offers. Within a project, you may find that screens are implemented following different patterns and often check for different conditions and errors. You’ll have one screen that works well on multiple browsers and another that only works on Chrome and Firefox. Or you may find different approaches to persistence, where code written by different developers handle different errors or make different assumptions about validation.

Not everything we want to reuse can be expressed in reusable classes or functions. Higher level reuse often requires documented patterns, code templates, and snippets. The Design Patterns book is one of the best examples of design reuse. Code templates speeds their instantiation.

At SlickEdit I participated in the creation of a code template system. With it I could instantiate a new set of classes for the Composite pattern in a matter of seconds. The C++ version of this pattern requires 6 classes. That’s a lot of typing! Without templates people often root around to find code that is close and strip out the parts they don’t need. This often leads to bugs from items that were improperly removed or mistakenly left in.

Combating These Problems

Wow! That’s an intimidating list of things blocking reuse. So, maybe we should just give up? I say, “no”! Despite these problems, reuse is important. When done right, it not only speeds our development but creates functionality that works consistently across the application. It also promotes a greater sense of ownership that makes the work much more satisfying.

To establish effective reuse, we need to take an architecture-centric approach to development. As developers, we should all have a clear understanding of the architecture. We should recognize what’s reusable and what’s not and make sure that code is placed in the appropriate place within the package hierarchy. Emphasis should be placed on effective names and clear documentation. All developers are responsible for establishing and maintaining the architecture, not just a chosen few with the coveted title of Architect!

We need to establish patterns and reusable designs. For almost everything we write, there should be an established pattern for how to implement it. If there isn’t, it’s time to define one. If there is one and it can be made better, then it’s time to refine and improve it. One of the most important jobs in our development is to document these patterns and create base classes, templates, and code snippets that help to instantiate these patterns. Ad hoc coding is the enemy of architecture.

If a company is sufficiently large, you could devote people to the collection and management of reusable assets. I see these people as librarians rather than as architects. I really take exception to the title of architect, but That’s A Topic for Another Time (TATFAT). Anyone should be able to contribute a reusable element. The librarians are responsible for making sure it meets standards, is properly tested, and put into the proper library or package so it can be easily located. They may even take the responsibility for documenting this element, which so many developers find particularly onerous. As with a book library, the librarians could also help you locate what you’re looking for.

What about motivating our people? Shouldn’t we offer some kind of bonus for writing reusable elements? No! See my article on The Truth About Money and Motivation. Instead of using money, use the real motivators of purpose and mastery. Make sure that the team knows why this is important and talk about how effective reuse is one of the core skills of great programmers. Most developers want to write good code with effective reuse. Make sure they have the time to do it.

If we’re doing things correctly, almost everything we write should make the next release or next project easier. Effective reuse taps into the passion developers feel for great code, leading to greater creativity and productivity. Besides, how many Foobulators does one company need, anyway?

dev Element agile Design

Published at DZone with permission of Scott Westfall, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • ChatGPT Prompts for Agile Practitioners
  • Better Performance and Security by Monitoring Logs, Metrics, and More
  • How to Create a Real-Time Scalable Streaming App Using Apache NiFi, Apache Pulsar, and Apache Flink SQL
  • Top 10 Secure Coding Practices Every Developer Should Know

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: