Art of Software Reuse
  • About
  • Introduction
  • Why Do Reuse Efforts Fail?
    • Common Pitfalls
    • Conway's Law
    • Care About Risks
    • Pursuing Perfection
    • Lack of Domain Focus
    • Entropy
  • Tenets
  • Success Factors
    • Revisit Assumptions
    • Communicate, Constantly
    • Collaborate
    • Review Code
    • Be Domain Driven
    • Target Quick Wins
    • Reduce Friction
    • Document
    • Build for Immediate Use
    • Address Support Needs
    • Managing Complexity
  • Practices
    • Minimise Jargon
    • Leverage Interception Points
    • Delay Commitment
    • Never Waste A Production Incident
    • Be Disciplined
    • Be Demand Driven
    • Continuous Alignment
    • Iterate, Iterate, Iterate
    • Build a Product Line
    • Understand Lack of Reuse
  • Design
    • Wrap Legacy APIs
    • Think Products, Not Applications
    • Identify Common Needs
    • Create Common Connectivity Components
    • Consistent APIs
    • Manage Domain Variations
    • Evolve Functionality Iteratively
    • Offer Reusable Assets with Multiple Interfaces
    • Leverage Services Across Functional Flows
    • Mediate Service Requests & Responses
    • Refactoring
    • Abstract Utility Functions
    • Reduce Technical Debt
    • Facilitate Extensibility
    • Encapsulate Variations Using Patterns
    • Understand Adoption Barriers
    • Ease Testability
    • Supportability
  • Tips
  • Resources
Powered by GitBook
On this page

Was this helpful?

  1. Practices

Minimise Jargon

How many times have you talked to a technologist who uses a lot of jargon? MDA, SSO, SAAS, BPELWS . As a technologist I am guilty of using jargon as well.

However, if you want to turn people off there is no better way than to use excessive jargon!

Software reuse is a hard problem mainly because a lot of us get buried in the technical aspects and ignore everything else. If you want to successfully communicate with developers and development leads minimize the jargon and refrain from showing off your technical superiority. Instead, focus on relevance.

If you understand the problem and can truly add value by pointing them towards a reuse friendly solution more power to you. Too often I see just the opposite – anxious to force solutions technologists decide on the approach using a favorite technology (they freely sprinkle arcane terms and acronyms to intimidate coworkers) and then wonder why people resist.

When you encounter a problem pause and reflect – strive to understand the bigger picture:

  1. who is asking for the functionality?

  2. is this a one-time requirement or something that is relevant to multiple applications?

  3. have we solved this problem before within the team?

  4. do we have something that could work with some refactoring?

These are the questions that will get you closer to success with reuse. Focus less on the technology and more on the problem and relevance. Watch your developers become more adept at recognizing which functions need to be reusable and which ones aren’t.

I am not for a second saying technology is irrelevant or unimportant. Far from that. Before the how you have to figure out the what and technology is good with the latter. Framing reuse within the problem at hand will make it easier for you to convince folks within and outside your team. Try it and surprise yourself!

PreviousPracticesNextLeverage Interception Points

Last updated 5 years ago

Was this helpful?