Targeting Quick Wins And Sustaining Momentum

September 7, 2014

Systematic reuse initiatives don’t have to be big-bang events preceded by a lot of noise. It can be done quietly – project by project with a resolute focus on getting targeted wins. As I’ve blogged before, the key is discipline – not technology. The most fundamental question to ask your teams – do they have the basics in place? Specifically:

  1. How do they go from requirements to design – is there a set of known patterns and frameworks that will anchor the design? If so, ensure every project is aware of these and when appropriate leverages them in the design.
  2. Are there trust issues with the software being produced by the sister teams? Before you dismiss this as a ‘soft’ issue – remember, your developers and development leads are human and need healthy social relationships at work before they let others influence them. Influence translates to systematic reuse – not occasional but project after project. 
  3. What happens in cases where a project develops a lot of potentially reusable code – who knows about their existence outside the immediate development team? who is going to be accountable for appropriate teams to leverage this work? If you don’t know the answers – don’t be surprised that your software solutions are siloed. No getting around Conway’s Law
  4. Do you send project updates and accomplishments like many development teams? Most of the time, the target audience is management and the intended message is to gloat how successful the delivery was. Celebrate and reward your teams but also take the time to reflect on two additional themes: did we best utilize the organization’s existing software assets – that includes prior requirements, component libraries, frameworks, services, and patterns? and did we contribute back to the organization’s repository of shared software assets? These aren’t tough questions to ask but you will be surprised by the answers!
  5. What are the biggest roadblocks to sharing software assets? Don’t assume it’s communication or organization structure or code quality or learning curve or integration ease (or all of them!). Go to the scene of action – spend time pair programming with developers to empathize their circumstances. Watch them struggle to get something to play well in their IDE or plain compile or execute with a myriad tweaks. Don’t assume – collect evidence and focus your improvement efforts on making their lives better.

Think Hard About Conway’s Law

August 24, 2014

Was reading Adrian Cockcroft’s interview on InfoQ recently – where he talks about MicroServices and DevOps, and whole range of topics. A particular point about changing the team’s culture directly applies to reuse. 

I quote from one of his answers: “…is it Conways law?… what’s the organization…? Basically the law that says the communication structure of an organization will be reflected in the code. So you set up the … you decide what structure you want your code to have and you make the organization look like that;”

I am sure you have been in situations where you wish: the code for a reuse candidate was in a common shared source control repository, the components were adopting compatible technologies, that there was clear separation of concerns, and most important, there was a true culture of sharing and systematic reuse across projects. 

This is so true that it got me thinking – how often do we want something to happen – be it collaboration, co-creation, systematic reuse – and yet we run into organizational roadblocks? Lack of core competencies – too many people solving the same problem in a sub-standard fashion, conflicting priorities, inadequate knowledge sharing of not just code but more fundamentally: key requirements, lack of human / monetary / infrastructure resources, etc.

Instead of negotiating constantly across multiple teams – all looking to meet several success criteria – have you thought of organizing them by the outcomes you seek? If you want shared software assets, you need to foster sharing organically, through the organizational interactions that happen every single day. Who reports to who, who is held accountable for what, – the nuts and bolts of responsibility and accountability have to be thought through for the shared software assets you aspire to create and reuse. 

It’s easy to get a single flash in the pan reuse success story – it’s much harder to institutionalize it across teams and projects. Have you got the responsibilities in the team defined in terms of the shared software assets you envision? More often than not – we tend to look for magic bullets in terms of tools, technologies, trends, fads, and yet – systematic reuse is fundamentally about the delicate dance of interactions, trade-offs, and decisions that development teams have to make in the midst of competitive pressures and harsh deadlines. Focus on the form and structure and reuse will follow. If you aren’t getting reuse, think hard about Conway’s Law – the state of your software won’t lie – it won’t hesitate to show up the healthy or not so healthy nature of team interactions, incentives, and priorities that are alive and thrive on the ground. 

 


Tips for Identifying Reusable Candidates from Existing Code

July 6, 2014

Here are a few quick tips to examine your existing code to identify reuse candidates:

  • Introduce Factory or Builder instead of repetitive boiler-plate code when constructing key objects. Several benefits: makes it easy to refactor and evolve how underlying objects are stitched together, makes it easy to write more intention revealing code, and very relevant / convenient when writing automated tests
  • Clarify functional behavior and tease out non-functional logic – look at how functional logic is implemented across your codebase. Do multiple projects share a common set of domain assets – objects, rules, services, and the like? if not, look for areas where functional logic is tightly bound to non-functional aspects like fine-grained metrics capture, exception handling, retry / timeout handling, etc.
  • Public API that needs to be accessed across platforms / devices are strong reuse candidates – for instance, are there functional APIs that don’t have a remote interface (e.g. a plain Java implementation without an appropriate REST-ful web service resource)? Do you need functionality to be made available across multiple devices with varying User Interface semantics? If so, look to carve the shared logic out into a service that can be accessed from multiple devices / integration points

Don’t Implement Reusable Assets Unless Necessary

July 6, 2014

Resisting the temptation to implement a story is very hard for a dev team – it is all too easy to get carried away in introducing a new idea as a reusable asset. However, these are the moments where you must pause and ask yourself a few basic questions before rushing to write code:

  • Is this a one-off requirement or part of a recurring theme? Remember – when in doubt, don’t plan for reuse but continuously align and refactor your codebase. Use before reuse!
  • Is there a confirmed consumer of this asset beyond the immediate project? If not, keep it in the originating project and promote it for reuse when you find another team or project that needs the functionality
  • What are the likely variations that aren’t captured in the existing implementation? are they all really required for day 1, day N ? Don’t implement anything unless there is a business mandate to do so. It is very easy to add code wishing someone reuses it rather than refactoring a known good piece of functionality
  •  Do you have the bandwidth to develop unit tests, capture the right domain abstractions, and write developer facing quick start documentation? If not, resist the urge to prematurely introduce new code that ends up being technical debt

Getting Developer Buy-in for Systematic Reuse

May 31, 2014

Too many systematic reuse initiatives fail because they fail to get their most important constituency. Below are a few tips to get developers to buy into reuse efforts.

Make every design and implementation artifact available for active engagement and feedback. If you say something must be used as a mandate – make sure your developers can actually use and benefit from that capability. This isn’t about functionality alone – it is about transparency, willingness to involve and incorporate a diverse set of ideas, and most importantly, inviting ongoing dialogue and feedback

Next key aspect is – Do you know the key developer pain points? Is it extensibility? Ease of integration? Testability? Performance? If you don’t really know then don’t thrust a reusable asset on them without working out candidate solutions. Get the developer community to help you be part of the overall solution- chances are, there are existing assets, already in production use. Don’t make he mistake of evangelising a mediocre solution that makes it more difficult for developers who have to work with your software day in and out.


De-risk External Integrations When Building Service Orchestrations

March 9, 2014

Complex services often involve orchestration among external providers – either for security, data enrichment, or a host of other reasons. Your service – on many occasions – won’t be able to function effectively without these external integrations or dependencies. There are a number of ways to de-risk these integrations:

  • Use timeouts explicitly – whether it is using JDBC, URL Connections, or FTP connectors – to avoid indefinitely blocking on external invocations. If it is a custom or 3rd party API that doesn’t have such a parameter, use Future task with timeouts as a workaround.
  • Introduce Circuit Brakers – if there are multiple calls timing out within a threshold for instance, subsequent invocations can fail fast and ensure valuable system resources aren’t tied up unnecessarily.
  • Provide a debug mode or a message capture mode where requests / events being sent to external integrations can be captured for both monitoring and troubleshooting purposes. These diagnostic capabilities are invaluable when your team is trying to ascertain if a problem is related to connectivity, contract, transmission, etc.
  • Monitor external connections via health checks – these checks can alert proactively in the event a connection becomes unresponsive/stale prior to your clients facing issues.
  • Smoke test deployments – with every single release and every single time prior to turning on business processing. If you find for instance the database your service depends on is unavailable or if external dependencies are not responding back, it is better to find it sooner rather than later.
  • Add robust exception handling enabling greater resiliency. If an external service provider comes back online and you can transparently replay pending messages or requests – the system doesn’t need manual support interventions enabling resiliency and reducing opportunity for manual errors. One way to implement this is via a queue – add messages and process them asynchronously (e.g. order placed via web page in an e-commerce site and you get a confirmation email a few moments later)

Improving Operational Visibility for Services

February 23, 2014

Came across the insight tools on the Netflix Tech Blog – as you build more and more services, having the right set of monitoring tools, obtaining real-time operational status, and ability to perform preventive activities will be critical so you can honor obligations to your service clients.


Follow

Get every new post delivered to your Inbox.

%d bloggers like this: