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
July 13, 2010
Some software assets don’t get reused – question is – is the reason well known? if so, what is being done to ensure that it doesn’t happen too often? In agile methodology, the retrospective serves as a vehicle to reflect on the iteration. Reflecting on the experience overall – what worked, what didn’t work, how can the team improve and so on.
In the same token, consider retrospective for reusable assets – did the asset get used the way it was intended to be used? if not, are new use cases providing opportunities that weren’t considered earlier? In the rush to perfection, there is always a danger is adding too much complexity to an asset. Are consumers even using all that complexity? remember there is a cost to complexity – having the right level of complexity with multiple instances of reuse is a happier place to be.
When you work with the internal development team and asset consumers – ask them specifically why something isn’t working. Is it the lack of adequate documentation and/or code samples? does the asset fail because it didn’t have domain relevance? are there better (cheaper, faster, more maintainable) ways to achieve the asset’s functional objectives? is it too slow and doesn’t meet performance SLA needs? are there too many configuration options? doesn’t work well in a particular runtime environment?
You get the idea: there are specific reasons why your software asset isn’t being reused. Find out why – continuously refactor and resolve root causes to get a higher return on your software investments.
Leave a Comment » | agile, refactoring, Reuse | Tagged: agile, retrospective, software reuse, user needs | Permalink
Posted by vijaynarayanan
July 11, 2010
You want to build reusable assets in an agile manner – avoiding a significant design effort upfront and evolving behavior over time. Why? Because building for reuse involves several steps: the right abstractions have to be identified, appropriate variations have to be modeled and accounted for, and the asset has to be generic enough for use beyond a single project.
This is hard to get right the first time – often, business requirements aren’t clear from the early on making it tricky to identify reusable assets. More importantly, reuse adds project risk – specifically risk to the timeline. Always ask yourself if it is worth making the extra investment – if you aren’t sure delay commitment.
Capture possible enhancements to your codebase via an issue tracking tool and you can always assign those enhancements to future iterations. When you implement a story and you see the opportunity for making something reusable, consciously align classes and interfaces for reuse. Refactor, refactor, and keep refactoring – because only with multiple iterations is your asset going to be increase it’s reuse potential. Remember – very often, the asset would not be used as-is. It will need changes – patches, enhancements, major redesign even – before it can be leveraged across projects.
Leave a Comment » | refactoring, Reuse | Tagged: agile, interfaces, refactoring, software reuse | Permalink
Posted by vijaynarayanan
