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
July 1, 2012
In the zeal to create a reusable component, you should be careful not to over-engineer i.e. pursue perfection. The functional needs have to be at the core of the reusable asset’s ability to solve a particular problem. When in doubt, remember that as time goes on, the team will learn the nuances of the problem domain and will be able to make better design decisions. Explore the domain with the team rather than force a solution. How exactly do we do that? We can:
- Practice creation of simple, domain-aligned abstractions
- Continuously validate the domain with functional experts in the team
- Consciously exclude aspects of the domain that aren’t relevant / well understood when defining reusable components
It is critical for the team to discover and stumble upon reusable assets – rather than big design up front efforts lasting for months. Keep it agile and continuously evolving and improving.
Leave a Comment » | agile, General, Reuse | Tagged: agile, Design, domain driven design, software reuse | Permalink
Posted by vijaynarayanan
April 13, 2011
Wrote earlier about the importance of refactoring and continuous alignment within the context of systematic reuse effectiveness. Reducing technical debt is an integral aspect of refactoring. This post provides tips for reducing technical debt in your software assets:
- Minimize redundant definitions of key domain objects (i.e. competing, conflicting definitions of the same domain object across related applications)
- Minimize similar solutions for slightly varying business processes and instead create common process flows
- Loosen tightly coupled integration/transport logic with business logic
- Provide consistent strategies for implementing cross cutting concerns
- Replace tactical implementation for a problem that has a better open-source alternative
- Eliminate redundant approaches for managing configuration information
- Harmonize multiple, incompatible interfaces and make them more domain relevant
- Minimize excessive coupling with a particular technology/implementation stack
- last but not the least – create a comprehensive suite of automated tests
Are there similar themes in your development efforts? What steps are you taking to ensure technical debt is addressed?
Leave a Comment » | agile, General, Reuse | Tagged: agile, configuration, domain driven design, loose coupling, refactoring, software reuse, systematic software reuse, technical debt | Permalink
Posted by vijaynarayanan
March 5, 2011
Pursuing systematic reuse the agile way? This primer will cover a variety of design practices to help your development teams. It covers:
- Building reusable assets from existing applications
- Designing new reusable components and services
- Design patterns, product line practices, and more!
1 Comment | Reuse | Tagged: agile, design patterns, design practices, legacy, practical, practices, pragmatic, pragmatic reuse, refactoring, software reuse, systematic reuse | Permalink
Posted by vijaynarayanan
November 26, 2010
Domain analysis is a foundational capability required for effective systematic reuse. Why? There are a lot of applications your teams are working on and the common theme among them most likely is the fact that they are in the same problem domain. In order to truly bring down cost of new applications and services, it is critical that the domain is understood and modeled appropriately. Here are some specific strategies to make this idea operational:
- Account for domain analysis and modeling in your iteration planning. Domain analysis is necessary to understand the nuances and variation points that an application/service/process needs to realize. Discovering the right variations requires time and interactions with business stakeholders and subject matter experts.
- Aspire for a core set of business object definitions that can be shared across business processes and service interfaces. Without appropriate data governance, domain knowledge will either be inaccurate/incomplete or worse duplicated in an inconsistent fashion. As the number of customer interfaces increase for your services, the domain inconsistencies will lead to greater point-to-point integrations and complexity.
- Align overall architecture with domain variations. Your domain is rich and complex but probably varies in a known set of ways. Additionally, what varies isn’t uniform and the rate of change across these variations aren’t identical. This is significant because the variations in the domain need to be captured in your overall architecture. Products/applications in the domain need to share a common architecture – only then can components integrate and inter-operate and systematic reuse will take hold. Constantly evaluate the need for a new version of a core business entity and associated classes to manage the entity.
- Refactor constantly to get to intention revealing design and code. As Eric Evans illustrates in Domain Driven Design, intention revealing code is easier to understand and evolve. It also makes it easier to address new business requirements – as the design/implementation are closely aligned with the business domain, the quality of communication (referred to as ubiquitous language) and the ability to change it both increase significantly.
This isn’t an exhaustive list – instead, it is meant to highlight the need for placing the domain in the middle of every design, architecture, and implementation decision your teams make.
Leave a Comment » | agile, Design, refactoring, Reuse | Tagged: agile, analysis, domain, domain modeling, refactoring, software reuse, systematic reuse | Permalink
Posted by vijaynarayanan
October 1, 2010
SOA Adoption Using Agile
Part 2 of a two part Article series on SOA adoption is up on the SOA magazine. The first part is here.
Leave a Comment » | SOA | Tagged: adoption, agile, Service-oriented architecture, SOA | Permalink
Posted by vijaynarayanan
August 18, 2010
SOA Adoption Using Agile
Part 1 of a two part Article series on SOA adoption is up on the SOA magazine
1 Comment | Reuse | Tagged: adoption, agile, Service-oriented architecture, SOA | Permalink
Posted by vijaynarayanan
August 15, 2010
I have heard some variation of the following line from developers, technical leads, and architects – “we want to make things more reusable, but we don’t have the time.”
There is always a deadline (or many deadlines) to meet and technical debt to accumulate. Since we are always in a hurry, it helps to be aware of what should be reusable – even if we won’t get to it in this iteration . So here are some ideas that can help you decide whether or not a capability should be developed for reuse:
- is the capability unique to your enterprise? i.e. it captures logic and/or process variations that provide competitive differentiation.
- is the capability making something incredibly hard/defect prone simpler and/or easier?
- is there a desire for customers to have a capability across business channels? i.e. from the web, from a mobile device etc.
- is it specific to your domain and potentially relevant to multiple applications in the domain? this may or may not be obvious – if it isn’t, delay commitment.
- is the capability only available in a particular technical platform but is solving an often needed problem?
- is it automating boiler plate code generation or preventing defects?
- is there an in-house/external alternative that achieves your functional requirements? if so, seriously consider stopping investment in the asset.
This is a starter list – the idea that we keep coming back to is this – treat a reusable asset like a real investment. Every iteration and release is an opportunity to review and update the investment. When you make a decision, continuously refactor to make the capabilities less app specific and reusable.
Leave a Comment » | Reuse | Tagged: agile, Asset, code generation, refactoring, software investment, software reuse, strategy | Permalink
Posted by vijaynarayanan
August 1, 2010
Here is a free e-book on getting started with systematic software reuse. It introduces software reuse, risks with reuse and how to address them. Also includes an example roadmap that can be used as a reference. Enjoy!
Leave a Comment » | Reuse | Tagged: agile, ebook, getting started, iterative, software reuse, systematic software reuse | Permalink
Posted by vijaynarayanan
July 14, 2010
Code reviews can be extremely effective driving systematic reuse. To be sure, there are multiple objectives with code reviews (e.g. adhering to naming standards, detect defect, write consistent comments, etc.). Additionally, they can help with reuse in the following ways:
- Reviews happen prior to code being placed in production – they give you a chance to extract, build, or integrate reusable assets.
- Code reviews often identify opportunities to refactor – refactoring to reuse. Have you ever had a review where someone said, “you know what, you should talk to Joe, since he is building a similar thing…” or “…we should use the existing service for implementing this story.”
- Reviews help discover reusable assets – you might include classes and interfaces (not necessarily neatly demarcated) – in a component that can really be split up into two or more components. It may be appropriate to slice up the logic to ensure the existing component isn’t too monolithic
- Reviews are very effective in preventing defects – with reusable assets, quality is everything and the act of reviewing them is critical to their stability and production-readiness. These can be extended to unit tests and documentation as well.
- Reviews are a neat opportunity to communicate to at least a sub-set of the team what reusable assets exist and how they can be leveraged. Often times, when assets are mentioned as-is, they may not be that well received. Place them within the context of a real project, a real deliverable, and a tangible need – now the communication is much more effective.
As more developers pitch in and learn from each other, the reviews will become a critical part of how you develop and evolve reusable assets.
3 Comments | Reuse | Tagged: agile, code reviews, refactoring, software reuse, success factor, systematic reuse | Permalink
Posted by vijaynarayanan
