July 31, 2010
Cut and paste reuse is simple and easy – so why pursue systematic reuse? For all the seeming benefits it has significant disadvantages. For instance:
- It increases codebase size. There is nothing eliminating duplication – so the codebase starts to contain multiple instances of similar logic. Systematic reuse aims to cut down the amount of incremental code that needs to be written to address new requirements.
- Lose the benefits of enhancements and bugfixes: everytime you “fix” a problem with cut and paste code – that has to be propagated across the codebase. This isn’t trivial – every where the cut and paste code was originally placed, would now be coupled with various other classes.
- Doesn’t promote consistency in behavior – cut and paste from one part of the codebase to another might save time in the short term but will quickly lead to different behaviors for achieving a capability. Over time, this increases the size and complexity of your solutions.
- Makes it hard to refactor – related to the earlier point – when you refactor, there is extra care needed to make sure that new defects aren’t introduced and existing code is identified carefully. That being said, refactoring will help you reduce the amount of duplicate code and move towards a more reusable, more modular design.
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.
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.
July 11, 2010
New episode added to the Software Reuse Podcast Series on designing reuse-friendly XML schema definitions as part of SOA efforts. Elaborates on a core set of practices that will make your service contracts more maintainable and reusable.
Like this post? Subscribe to RSS feed or get blog updates via email.
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.
July 10, 2010
I came across these 8 key lessons on the Art of Less from the Japanese Ink and Wash painting technique Sumi-e. When I read them, I couldn’t help but think about their applicaton to reusable software. Here are some initial thoughts (Sumi-e lessons in bold):
1. More can be expressed with less– One effective way to add value with reusable assets is to enable developers to be more productive. With less code, can they implement business functionality faster? can they reuse their knowledge of one asset when using another?
2. Never use more (color) when less will do: only support known variations. Needless flexibility not only increases development time, it also adds complexity and results in speculative design.
3. Omit useless details to expose the essence: what are the key interfaces that developers need to know about? If there are obscure configuration options or edge use-cases that most developers don’t care about – do they have to be communicated in an all-or-nothing fashion? When in doubt enable developers to peel away at your asset on a need-to basis.
4. Careful use of light-dark is important for creating clarity and contrast: There is a reason why your API was created and why it abstracts away certain details while exposing others. It is important to communicate the intent behind your design keeping in mind the developer’s need to get productive quickly.
5. Use color with a clear purpose and informed intention. Reusable assets should be part of a whole. Think constantly about how one asset relates to another and how a combination of them can make it easier for new automation opportunities. The key concept is to break it down into domain-relevant concepts that are part of a larger story. The colors do paint a picture, don’t they?
6. Clear contrast, visual suggestion, and subtlety can exist harmoniously in one composition. You don’t want every reusable asset to support completely different idioms – can you make it impossible for errors? can you provide warnings with actionable, informational messages for the developer? Think about suggesting good practices to the developer while they are inside a development environment.
7. In all things: balance, clarity, harmony, simplicity. As far as possible, reusable assets should be simple to setup and use. Strive for providing flexibility but follow the 80/20 rule – what do most developers want from an asset? Support those objectives and make it very obvious to achieve.
8. What looks easy is hard (but worth it). Reusable assets should make hard things possible – making it easy should be a goal to aspire to as always without taking the route of hiding too much information. Goal is to avoid repetitive code and configuration across multiple projects. It is extremely hard but well worth it!
What do you think? Do these principles resonate with you as a software professional?
July 10, 2010
Tip #26 – Build Reusable Services
The following are useful tips when designing and implementing reusable services.
Expose only logical data attributes and “standardized” values to external consumers in the service contract. This will ensure that the data service has maximum flexibility to change physical system implementations underneath and the consumer will not be adversely impacted.
Reuse business object schemas across data service operations and while preparing WSDL documents. This will ensure logical data model alignment as well as consistent definition of business objects simplifying consumption and maintenance effort.
Expose event driven publication services for data propagation to downstream consumers using standard publication messages. This will greatly reduce (and potentially eliminate) the need for source specific messages and needless data transformations. Standard publication messages could be versioned and new consumers could be added via configuration on a messaging broker without requiring development effort.
Provide multiple flavors of services based on commonly used use cases for the data service. A light flavor of a service will be useful for clients who do not want to parse a large business object message returned by the full flavor.
Strive for abstraction of data source specific semantics in order to insulate the consumer from physical data source processing/logic. This practice applies to identifiers, data values, data structures, and data orchestration logic that could be coupled to a physical source if proper care isn’t taken.
Prefer reliable transports when invoking data services asynchronously. Although it is possible to simulate asynchronous processing using transport protocols such as HTTP it is not advisable to do so. In the event the data consumer becomes unavailable messages are lost.