BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Learnings from Discussing Developer Enablement at QCon London

Learnings from Discussing Developer Enablement at QCon London

This item in japanese

Bookmarks

Developer enablement can increase the potential we can have as individuals. It can be done in small and larger companies. Where sometimes individuals can have their own solutions, there will be things that are mandatory for all teams. Metrics can help to see what is being used or not. Be careful about supporting developer enablement for legacy systems; if it’s outdated and needs to be replaced then it might be better to not invest in it.

The QCon London 2022 conference ended the developer enabler track with a panel discussion. The panel consisted of Jake Kaufman, Suhail Patel, Soam Vasani, and Stuart Davidson.

The first question was, "What’s next for developer enablement?" Vasani mentioned that it could be bringing developer enablement to machine learning, as currently, it’s still "low tech" as he called it. Patel emphasized the need for standardization using open practices, which would further enable adoption across the industry. Kaufman said that it would be higher involvement of developers; what could help is to track their happiness with the provided tools. Davidson suggested that we should try to get product people interested in developer enablement, and focus on customizing what’s available for specific usage in your organization.

Is developer enablement only useful for big companies? Vasani mentioned that there is a point where it starts to pay off. Kaufman mentioned that the ratio is trending at about 1 in 10 for enablement. Small companies can use tools that come with some of the vendors, for instance for low code or no code, Kaufman said.

A question from the audience was if we should allow individuals to start things, or if we should insist that developers must use the tools that are provided. Kaufman said that if a team has different problems from other teams, they can have reasons to come up with their own solutions. Patel mentioned being careful with allowing that; he gave the example of security tools and measures which are normally applicable company-wide. Davidson added that some of the tools and solutions will not be negotiable; they are built in and must be used.

Should we use metrics to see what is being used? Vasani said that measurement can help, but they don’t tell you the whole story. Kaufman mentioned that we should work closely with the developers to find out what works and what isn’t used. Davidson suggested building relationships with your developers and involving them. One way to do this is by putting ideas on a roadmap and asking people to vote. Patel mentioned that sometimes developers write code that showcases ideas, and that instrumentation can help you to make better decisions.

What about legacy systems- how much should we invest in developer enablement and tools? Patel said that this is often a dilemma, but by not investing, nothing will be achieved. Kaufman argues that it depends on business needs, whereas Vasani suggested investing in enablement to the extent of how much development will be done. Davidson concluded that if it’s outdated and needs to be replaced, we should not invest in developer enablement.

There will be a track on developer enablement at the QCon Plus May 10-20, 2022 conference.

About the Author

Rate this Article

Adoption
Style

BT