Surfing The Innovation Wave – Talk by Sharad Sharma

December 7, 2012

Heard a very interesting talk by Mr Sharad Sharma titled “Surfing The Innovation Waves” that puts in context the nature of innovation happening in the marketplace and the contextual forces behind the changes. He talks about adopting the
“hobbyist temperament” and gave several examples of people in the edges of industries disrupting the establishment. The key behavioral traits he mentioned are as follows:

  • Stepping outside one’s comfort zone
  • Having an internal compass – “i got to excel.” Don’t rely on external cues and rely on self-mastery instead.
  • Get comfortable to stand out and be an underdog.
  • Persisting in face of adversity. Even if you are right, it doesn’t matter till you are able to go past the criticisms that will keep coming

He then expanded on a New Age Code of Conduct  - keeping in line with the idea of the hobbyists and people who are innovating at the margins. He talked about volunteers, poeple are doing it for others like themselves and participating in creating and growing “Creation Nets”. The Creation Nets are going to be the wave of the future where many people sharing a common cause will come together and contribute to innovation via rapid and effective collaboration. Community activity is key because the world is much too complex and you have to collaborate with others for innovation to happen both within and outside the organizational boundaries.

This new code of conduct has particular behaviours that he recommends:

  • Setting others up for success. Form of servant leadership – make it your job to help others around you get to their goals. Evolving shared aspirations is very important
  • Make sure you give more than what you take – effect of the commons. Amplification of co-operation is key and if you don’t invest in public good, collaboration isn’t sustainable. Academic institutions take an active role to play in public good creation.
  • Say what you mean, do what you say. Allow for trust bonds to be formed – cannot allow duplicity. Without trust, no creation nets are possible and effective collaboration isn’t an option.
  • Make mistakes. Make them fast and recover quickly
  • Don’t wait for instructions – just make it happen. Pick the challenge that catches your fancy and start working to happen. Pull based model and not a push based model. I will do this with the best of my ability. Focus on excellence.

The talk is definitely worth the time in full – do see it online here: http://www.iimb.ernet.in/node/3164

1 Comment | General, open source | Tagged: , | Permalink
Posted by vijaynarayanan

Software Reuse Quick Tip #30

September 16, 2012

Tip #30 – Enforce Consistent Dependencies via Maven Parent POM

Maven parent POM can be used as a consistent mechanism to define dependencies and dependency versions. The module that defines common set of entries can then be used in any arbitrary module – it doesn’t have to be restricted to a child module in a multi-module build. This is very useful when you want to enforce consistent set of dependencies across multiple projects that share either a core set of reusable libraries including 3rd party dependencies.

Leave a Comment » | Reuse | Tagged: , , | Permalink
Posted by vijaynarayanan

5 Tips to Ease Reusable Asset Integration

September 9, 2012

Resuable software assets need to be created and evolved with two perspectives – functional value and ease of integration. A library that offers little functional value and is difficult to integrate into an application is unlikely to get wide adoption.  Are there tips to balance these two perspectives? I think so and here are some pointers:

  1. Minimize the number of 3rd party transitive dependencies – if reusing a module means bringing in 100 JARs, there are lots of opportunities for conflicting libraries build time and unanticipated runtime exceptions. I will elaborate specific strategies for this aspect in a separate post.
  2. Carefully assess integration points in your environment – does your company already have a widely adopted library for concurrency, logging, alerting, or messaging? Then your reusable asset needs to facilitate or ease out of box integration. Most importantly, it shouldn’t attempt to provide the same capabilities
  3. When providing overlapping capabilities you will have to convince the right set of folks that another API is necessary and there is a rationale for application teams to switch. Remember that the learning curve, integration effort, regression testing effort, and ongoing maintenance need to be factored into this decision
  4. When you are not sure how an existing library in your organization works, descope integration and instead focus on the core value that is unique in your reusable asset. It is much simpler to bolt that on rather than invest in an integration mechanism that you cannot support well.
  5. Boost developer productivity via IDE plugins, quick start project setup via Maven archetypes, or through code examples and automated tests. Regardless of what strategies you adopt the key is to demonstrate how easy it is to integrate your reusable asset with the rest of your enterprise.

Do these resonate with reuse practices you follow or have seen in your team? What other practices can help achieve adoption objectives?

Leave a Comment » | Reuse | Tagged: , , , , | Permalink
Posted by vijaynarayanan

Systematic Reuse Success Factor #12 – Empower Tech Architects

August 26, 2012

They key word in the phrase “systematic software reuse” is “systematic” – that is what distinguished ad-hoc reuse from continuous, iterative, investment-oriented reuse that provides benefits across projects. Anyone that has driven change within an organization will attest that one of the key enabling factors is political will and top-management sponsorship. Similarly, systematic reuse efforts need intervention and influence across every project – it needs your architects to have a say in the design and the implementation. Technical architects cannot be passive and standing back whining and complaining that the development teams aren’t listening and they aren’t reusing existing assets or investing in creating new ones. In addition to hiring competent architects, management needs to empower them. They need to be given authority and made accountable for systematic reuse efforts – want architecture convergence? faster time to market? lesser cost of maintenance? All of these are possible with systematic reuse but only with proper investment and ongoing guidance and care.

Empowered architects should be able to alter/change the technical strategy, design, and implementation approaches to ensure that it is inline with the overarching technical strategy for reusing capabilities within the teams. Of course, this doesn’t mean they stop everything without delivering value to clients on a continuous basis. On the contrary, architects need to be focused on both alignment with reuse and business delivery. They need commitment from teams that pursue tactical measures that they will get out of technical debt and align completely with the technical strategy.  They should and be able to intervene throughout the development process – during requirements analysis, design, implementation and review by working with the development teams in a hands-on fashion. If the architect carries no decision making authority to stop releases, change approaches, or extract commitments – the technical debt will stay where it is and reuse will be an elusive goal.

Leave a Comment » | Reuse | Tagged: , , , , | Permalink
Posted by vijaynarayanan

Tools and Software Infrastructure for Systematic Reuse

August 24, 2012

A lot of readers have asked me to provide details on what tools and software infrastructure is needed to enable systematic reuse. That is a very good question and it is a critical enabler for building on early wins with reuse.  At a minimum you need to setup the following as your asset base grows:

Module Structure: how are the reusable components organized in your codebase? For starters, setup a separate multi-module build for segregating resuable components from application (or consumer) code. The reusable components should be versioned, managed, and governed separately using a proper release cycle outside of the application code. Each component will also need a comprehensive set of automated tests.

Dependency Management: Use ant/ivy or maven if you are using java for building reusable assets. Each module should have the absolute minimum list of internal and 3rd party library dependencies. Each module should make sure that dependency scope is marked appropriately – take care to mark dependencies in test, runtime, and provided scope as required. Finally, ensure the build is using a clean set of dependencies – remove conflicting/redundant dependencies, and remove dependencies that will conflict with consumer code if possible as well.

Code Quality: Reusable components have robust code quality tooling in place. Use checkstyle, FindBugs, and clover/cobertura etc. with the build script. If you are using maven, you can declare these as plugins and generate code quality reports alongside your build. If you want an integrated code quality dashboard and web based reporting, setup Sonar!

Continuous Integration: Automated tests and continuous integration are extremely critical to continuously refactor, enhance, and deploy resuable components. Setup a continuous integration server that kicks of automated builds on commits as well as when dependencies get updated. Setup a CI server such as Hudson to run unit, integration, and regression tests

Asset Repository: Once you build components, there needs to be a binary repository to host them and integrate them into other builds. Artifactory repo (provides open source and commerical versions) and can be used to house your reusable components (in fact any component really). Once the web GUI is setup, you can browse and search for artifacts as well as refer to them from internal build configurations.

Issue Tracking: Setup bugzilla or your favorite bug and issue tracking software so teams within your organization can submit bug fixes and enhancement requests. You will also need to publish and manage a release calendar to provide transparency into which reusable components are getting released when and how are they getting delivered in the context of real business deliverables.

What additional tools and practices do your teams follow?

Leave a Comment » | Planning, Reuse | Tagged: , , , , , , , | Permalink
Posted by vijaynarayanan

Getting Started With Reuse By Harvesting Existing Code

August 23, 2012

Many teams want to incrementally build a portfolio of reusable components so multiple projects can leverage them. This post will provide a list of potential areas to look for achieving systematic reuse – chances are that you have a few components in these areas already. Assembling them into a standard set and making it available for easy consumption will dramatically increase adoption rates across projects. Here are the areas to invest and/or harvest existing code:

  • Configuration – specifically properties that vary across environments (e.g. DEV, QA, PROD). How are teams defining and managing this information today? If you are using Maven,  teams may be employing multiple strategies – profiles, assemblies, custom scripts, naming conventions, etc.  Why not consolidate practices?
  • Transformation APIs – many projects require data transformation between objects to JSON or objects to XML and vice versa. Teams might be using different transformation libraries, may be wiring them with Spring or other dependency injection frameworks in a bespoke manner. Why not adopt a consistent API that provides transformations via a common set of classes with pluggable format-specific providers?
  • Flexible Query Construction – lookup methods that require one or more parameters will end up having common boiler plate code that binds parameters using boolean conditions – why not provide a reusable API that allows the developer to wire parameters using a common API?
  • Integration with internal and/or external systems – retrying, alerting, message construction, metrics, and proactive monitoring are all cross cutting concerns that are common across projects. Teams must be realizing these capabilities using multiple APIs, injection hooks, and response loops – again a consistent and reusable API will not only cut development costs but also make application support simpler

Existing code and components do however carry several risks that have to be addressed to realize reuse potential. For example:

  1. How domain agnostic are the components? Does it have a well defined interface and ability to adapt to a family of use cases?
  2. What is the learning curve for developer adoption? Does it have well defined adoption patterns that are easy to learn and intuitive?
  3. How testable is the component? Does it have interfaces that capture and model varying behavior ?
  4. What is the support model for the component? How to submit bug fix or enhancement requests? is there enough expertise in the developer community?
  5. What will be the release cycle for reusable components ? This becomes critical as more projects start to leverage a common suite of components for a varying set of capabilities

Leave a Comment » | Planning, Reuse | Tagged: , , , , | Permalink
Posted by vijaynarayanan

Using Spring & Java Annotations to Inject Reusable Capabilities – Part II

August 15, 2012

In an earlier post, I wrote about using the Spring BeanPostProcessor to inject cross-cutting concerns. That can easily be extended to inject a proxy more transparently across all beans in the application context. The key is to use the BeanFactoryPostProcessor in conjunction with the post-processor.  Define a custom class that implements the factory post processor like the following:

package learn;

public class ExampleBeanPostProcessorFactory implements BeanPostProcessorFactory {

	@Override
	void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) {

		beanFactory.addBeanPostProcessor(new ExampleBeanPostProcessor());
	}

}

Define this bean alongside the the rest of your declarations. For instance:

<bean class="learn.ExampleBeanPostProcessorFactory" />

The post processor can be injected with required dependencies per your needs – this could be a bean that wraps all annotated objects with instrumentation via the Java Dynamic proxy. The key benefit is that the beans in your context can all be transparently examined and proxied – how to decide which beans need to be proxied can be determined by annotations or beans implementing certain interfaces or custom decision logic using a class.

Leave a Comment » | Reuse | Tagged: , , , , , , | Permalink
Posted by vijaynarayanan

« Previous Entries
Next Entries »
Follow

Get every new post delivered to your Inbox.