May 13, 2013
Here are five questions to ask your teams to increase reuse effectiveness when evaluating a functional requirement:
- Is a requirement already met within the application or platform or is this the first time?
- If the capability already exists, does the current implementation provide the right extensibility? Often, existing code would need refactoring to meet a slightly varying set of requirements when compared to the original one. Take this as an opportunity to tease apart the abstractions necessary to capture the variations. What’s common and what’s truly different is the key aspect to figure out.
- Which other team or application has encountered this functional requirement before and how did they solve it? If you aren’t sure, ask around!
- Do we truly believe we are the first ones to stumble upon this need in the team/department/division/the firm? Try “laddering up” – as the Heath brothers call it in their latest book Decisive - incrementally and deliberately extract the key aspects of the problem you are trying to solve and look for places where solutions already exist.
- If you find existing code to meet your need – evaluate it with a critical eye towards non-functional needs. Is it performant enough to meet the needs of your use case? does it provide adequate extension points / hooks to integrate with the rest of your application? is it a library or a hosted service? If hosted, what is the resiliency and availability strategy?
Too often, there is a bias towards implementing from the ground up due to either lack of time (don’t want to find out if other implementations or existing solutions exist and if they do, would they fit) or lack of trust (don’t want to use this team’s software or codebase or don’t trust that the quality of the implementation).
These aren’t exhaustive – what other questions come to mind?
Leave a Comment » | 
Collaboration, General, Reuse | Tagged: Collaboration, software reuse, systematic software reuse | 
Permalink
Posted by vijaynarayanan
February 17, 2013
Want to envision, design, and implement reusable software components that your development community will enthusiastically adopt? Co-create! Here are 5 tips to leverage co-creation when driving systematic reuse initiatives:
- Have an idea that applies to multiple projects? Get the project leads to co-ordinate and align resources and partner with developers from both teams to develop the design
- Share the source code of all your reusable components so every developer in the team can see under the hood how the component works and how it can be improved
- Work hands-on with developers when defining classes, external interfaces, etc. – not just via block diagrams but actual code. Pair program and show them how to think using abstractions, what aspects of the design to make extensible and the rationale for it, etc. – you’ll be surprised how effective this is and how much all parties learn from the process
- Share the big picture – every time and across every project – developers and development managers need to be convinced that their contribution aligns with the overall technical strategy. This should also highlight why a shared component’s test coverage and robustness needs to be high and continuously improved
- Use design reviews, code reviews, and retrospectives to continually look for ways to collaborate and leverage each other. See boiler plate code that can be better encapsulated, or missing tests, or a smarter algorithm – get your hands into the code and work with the concerned developer. They will appreciate why you want them to use a particular design pattern or think about a problem in a certain way. Added bonus – just like item #3 – every participant will learn from the exercise.
Finally, co-creating reusable components greatly reduces friction associated with having to implement a design that was mandated. You want passion and enthusiasm from the dev community – not compliance!
Leave a Comment » | agile, Collaboration, Reuse | Tagged: agile, code review, design review, retrospective, software reuse, systematic software reuse | Permalink
Posted by vijaynarayanan
October 25, 2010
In order to get critical mass for reusable assets, they have to be created and evolved in a collaborative manner across development teams. How can we enable co-creation? Several specific strategies can help:
- Share the source – ever wondered why open source projects succeed when in-house efforts haven’t? Sharing the source code behind reusable assets makes a world of difference. It increases transparency (with respect to capability, behavior, and quality) and provides an opportunity for the developer community to participate in the analysis, design, and implementation activities. More importantly, it enables teams to modify the source per their specific needs and allows them to submit/merge the changes with the main build.
- Provide detailed documentation for reusable assets that are both available, in-progress, and planned for the future. It can come very handy when there is a design decision to make in a project – time and time again, you will realize the greater the information on existing assets, the easier it becomes to enhance/change them and combine them in new and innovative ways.
- Explicitly seek participation and design input when creating/updating a reusable asset. This not only increases buy-in from the tech community but also provides new ideas, concepts, and problem solving techniques that the entire department (even an organization) can benefit from.
- Encourage questions, specially from new members and junior developers – welcome the most basic questions about the reusable asset inventory. Make sure an environment where open, honest exchange of ideas is taking place constantly. Good ideas come from several places and it is critical that developers don’t feel alienated or ignored due to lack of knowledge about one or more reusable assets.
- Seek out subject matter experts – several developers and business analysts are essential to increase domain relevance, and domain alignment for reusable assets. Pretending to have all the answers or feigning perfection will only reduce the quality of reusable assets and ultimately prove detrimental to reuse objectives.
Several systematic software reuse efforts fail to get off the ground – it isn’t because of inadequate domain variations or severely limiting technology constraints – due to lack of grassroots appeal among the technical community.
Co-creation addresses several issues at once: it exposes developers to high quality coding practices, increases awareness of available assets, and provides a controlled environment to experiment and evolve reusable assets.
Leave a Comment » | Collaboration, Reuse | Tagged: co-creation, Collaboration, participation, software reuse, systematic software reuse | Permalink
Posted by vijaynarayanan
November 5, 2009
If you want to kill the potential for systematic reuse, all you have to do is think only about your silo and not about anything else. This silo could be many different things and in each case it inhibits reuse as well as the effectiveness of your team as a whole. Here are some specific examples:
- At the enterprise level, silo thinking can introduce very many inefficiencies and redundancies. Silo thinking will optimize solutions for a specific project at the expense of the overall firm. For example, say you have a reusable asset for calculating taxes and a new project re-implements the tax calculation business logic all over again. Or they ignore existing software infrastructure and introduce a new vendor product. This may help a specific project but adds cost and complexity to the enterprise.
- Silo thinking specific to an application means potentially reusable assets are not created and existing reusable assets are not leveraged. Think about the application’s needs to get reference data or connect with external systems or format data per a destination’s specific needs. Is your application using reusable assets? If not, is there an opportunity to create one by building or refactoring?
- Silo thinking specific to a team typically results in lack of reuse across projects that impact multiple teams. Do other teams in your department/division/organization know what reusable capabilities exist? do they know the overall reuse roadmap and how that aligns with business objectives? can they contribute towards growing the asset base?
- Silo thinking specific to a person typically results in solutions that don’t benefit other developers in the team. Maybe you have a neat utility that makes it easier to fetch correlated data across multiple data sources. Or you wrote a neat script that validates system variables or smoke tests key functionality. If they save you time and effort, why not share them with your team? Two immediate benefits will happen: other developers will start saving time as well increasing the team’s overall productivity. You will start getting constructive ideas on making these solutions better.
Have you noticed these? how do you encourage solutions that go beyond a specific silo’s needs?
Like this post? Subscribe to RSS feed or get blog updates via email.
Leave a Comment » | Collaboration, Design, General, Reuse | Tagged: Collaboration, sharing, silo, software reuse | Permalink
Posted by vijaynarayanan
August 4, 2009
Tip #16 – Work with multiple stakeholders not just development
Systematic software reuse is a complex and challenging journey. Many of us in technology think of reuse from a developer standpoint. This is only part of the story. The success of reuse efforts often hinge on more than developers and development practices. You need to recognize the other stakeholders in this journey – they include system analysts, production support staff, information modelers, technical leads, and most importantly executives and development managers. Unless you have management support it will be tough influencing many projects in your organization. In the same vein, unless your reusable assets are supported in a production environment you cannot garner the required credibility of consumers and partners within your organization. Before you rush to buy the latest greatest silver technology silver bullet that will take you to the promised land of systematic reuse recognize that there isn’t one. It is a collaborative, incremental, and iterative effort requiring technical excellence, diplomacy and negotiation skills, and continuous communication. All these ideas apply whether your reusable asset is a library, framework, or service capabilities in a SOA context.
Like this post? Subscribe to RSS feed or get blog updates via email.
: 
: 
: 
: 
:
Leave a Comment » | Collaboration, General, Planning, Reuse | Tagged: Collaboration, software reuse, teamwork, tips | Permalink
Posted by vijaynarayanan
July 18, 2009
An often overlooked aspect of systematic reuse is integration of reusable assets with applications, processes, and services. Most teams focus on building a large inventory of reusable assets – services, objects, frameworks, domain specific language libraries. While that is necessary it is not sufficient for succeeding with systematic reuse. One essential ingredient is ease of integration. What do i mean by that? Specifically:
- Evaluating the requirement and making a determination whether an existing asset can fulfill the need (as-is or with modifications) or a new one needs to be developed.
- Address risks with integrating with a reusable asset (meeting SLAs, solution complexity, etc.)
- Sharing information on available interfaces (is there a java interface? a web service?)
- Providing code samples and integration design patterns
- Provide comprehensive list of error codes and error handling recommendations – if a service throws a particular error what should the consumer do? are there specific business errors or data validation errors that the consumer needs to be aware of?
- Ensuring the consumer doesn’t starve the reusable asset’s resources. This is essential for services based reuse where multiple consumers are invoking the same service capability.
- Assistance with testing the integration (provide test data, unit test code, as well as utilities to test response time/throughput)
You can build up a service catalog and magically hope to achieve high degree of reuse and you will most likely be disappointed. Bottom line – reach out to your consumer and help them succeed. Make it easier for them to evaluate, integrate, and test. Slowly but surely your teams will start coming to you as opposed to you trying to ‘sell’ them on the value of reuse!
Like this post? Subscribe to RSS feed or get blog updates via email.
: : : : :
3 Comments | Collaboration, General, Reuse | Tagged: documentation, integration, services, software reuse, success factor, testing | Permalink
Posted by vijaynarayanan
July 9, 2009
In the previous post on getting organized for succeeding with SOA I talked about the importance of implementation-free requirements and the overall role of business analysts. In this post, I would like to highlight specific areas where business analysts can help SOA initiatives.
- Create business models - free of technical specifications or system level details – that capture the full end-to-end view of a business process. They should use a modeling tool that can work with a standard notation (e.g. BPMN) and create as accurate a view of a business process as possible. They need to capture human steps, system steps, pauses, business rules, external activities, etc. accurately and comprehensively
- Identify candidate business capabilities - not necessarily technical services – but at a higher level of abstraction. For example, MakePayment or BookTicket are business capabilities that can be realized in a multitude of ways by technology folks. But the analysts could significantly help by pointing out capabilities that are candidates for reuse across multiple business processes, scenarios, or lines of businesses.
- Identify areas for simplification/streamlining - analysts can identify redundant manual steps where users enter data multiple times or in similar fashion. They can also identify steps that can be eliminated or made simpler. For instance, validating credit worthiness of a customer could be done systematically and the system can present options for the user based on score. Or the credit worthiness score could be driven by business rules and only in exception cases the system might require manual intervention. All these behaviors have to be driven from the context of how to make the overall user experience better.
- Provide context - analysts can help identify areas of business priority in order for technology to build services. What lines of businesses are meant to grow? which ones are going away? which business process needs maximum customization and if so, in what ways? A good analyst can provide the big picture view, the context for your SOA initiatives by helping you separate the essential from all the noise.
This list isn’t exhaustive but is meant to give a sense of the key role that an analyst plays!
Like this post? Subscribe to RSS feed or get blog updates via email.
: : : : :
Leave a Comment » | Collaboration, General, Reuse, SOA | Tagged: Business model, business process, Service-oriented architecture, software reuse, Workflow | Permalink
Posted by vijaynarayanan
July 5, 2009
Using iTunes?
A new episode is added on the
Software Reuse podcast series. This new episode explores why developers resist reusable assets (e.g. fear of needless complexity, lack of trust, timing of integration with the codebase etc.) and provides ideas on addressing the hurdles.
Like this post? Subscribe to RSS feed or get blog updates via email.
: : : : :
Leave a Comment » | Collaboration, General, Reuse | Tagged: developer cooperation, podcast, software reuse | Permalink
Posted by vijaynarayanan
June 23, 2009
Article on software reuse tips recently got published at infoq.com…
Here is the link:
http://www.infoq.com/articles/vijay-narayanan-software-reuse
Like this post? Subscribe to RSS feed or get blog updates via email.
: : : : :
Leave a Comment » | agile, Collaboration, Design, Planning, Reuse | Tagged: agile, article, iterative, software reuse | Permalink
Posted by vijaynarayanan
June 5, 2009
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 specially when you are trying to influence and persuade them 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:
- who is asking for the functionality?
- is this a one-time requirement or something that is relevant to multiple applications?
- have we solved this problem before within the team?
- 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!
Like this post? Subscribe to RSS feed or get blog updates via email.
: : : : :
1 Comment | Collaboration, Design, Reuse | Tagged: communication, software reuse | Permalink
Posted by vijaynarayanan
