Software Reuse Quick Tip #1

Tip#1 – Focus on reusable business (or domain-specific) software assets

Business assets are what makes your application or product line unique, your organization special, and ultimately differentiate you from the competition. The faster you can develop, release, and iteratively improve your domain assets the faster you will meet changing business needs and delight your customers

It is that simple

Too often, developers in their zeal to create a technical masterpiece, focus on building reusable components and services for problems that either have solutions inside your firm or from the open-source community. Now, if you have to, you have to – but try to avoid building stuff for which solutions already exist. Now, isn’t that what software reuse is all about?

Like this post? Subscribe to RSS feed or get blog updates via email.

4 Responses to Software Reuse Quick Tip #1

  1. Girish Pandit says:

    Exactly, most of the time we start doing designing as soon as we come out of the meeting room and not giving enough time to ourself to understand the need and look around what we have and whether we can use it not.

    The concept is pretty straight forward just that we need to understand and make it as part of our daily activity.

  2. vijaynarayanan says:

    You are right Girish. It is important to take a pause and examine whether something really needs to be created. Chances are high that someone within your firm has an existing solution for your problem

  3. Abrar Adeel says:

    As you mentioned in your post above, In a software product line A environment, a particular component that is deemed as a systematic reuse candidate, it is hard to get the road map rolling quickly as you are developing another product line B which needs this reuse candidate.
    In this scenario what happens is that the reuse candidate A gets dropped and then that feature or functionality is redeveloped in product line B.

    Its been my observation that in order to have a systematic reuse you need an organization that does development using a common development method across its enterprise because then you will have a clear idea of road maps,feature delivery etc..

    Would like to see what others have to say regarding this from their respective expereinces.

  4. vijaynarayanan says:

    Abrar – I think, like you have mentioned, if there is at least a short term road map of features it will be easier to recognize overlaps across projects and put in a reusable asset in place that can be shared. That being said, i think refactoring and realigning components and services is the daily reality that I see when trying to juggle priorities across projects.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: