Tuesday November 16th 2021 by SocraticDev
Software is driving every aspects of the economy. At the bottom of the industry are the software developers. Developers are software artisans. That's great and not so great at the same time. Not so great because they are often victims of pressure and friction from colleagues and the business they are serving.
At an online lunch & learn organized by Parasoft, three experienced software specialists discussed topics such as developer advocacy, focus on security and DORA metrics. The title of the webinar was 'Why Developer Advocacy is the Key to Transforming Your DevOps Environment'
Developer advocacy is a movement led by techleads and enlightened managers. They hold the belief that great software is only possible when developers are properly valued by the business. Developers advocacy is about:
- psychological safety
- continuous education on the job
- mindful onboarding of new developers
- inclusion in the shared vision of the products developed
non negotiable business needs
All businesses who bet on software need speed of execution and quality software. Their main goal is getting to market the fastest. Are they really gonna attain this target by managing projects with deadlines and putting pressure on developers? Tracy Bannon (MITRE), Bryan Finster (Defense Unicorns), and Kevin E. Greene (Parasoft) are against this.
For Bryan Finster "you get speed if you do it the right way". He highlights DORA's deployment frequency as often being wrongly taken as a metric of speed. For him, speed is the outcome of a healthy process. For example, excellence in deployment frequency is not about coding faster but in deploying smaller batches of code frequently.
Tracy Bannon notes that deployment frequency is not a silver bullet. Certain domains like governement's agencies, embedded softwares and aeronautics would not benefit from multiple daily deployment to production. Instead of deploying once every 2 years, being able to deploy every 6 months would be a great improvement in those fields.
She also stresses that a key to healthy development flow is a fast feedback loop : fail fast - fail cheap. For example, developing software for a fighter jet like the F-35 can require deploying to a simulator and making those deployments count as deployment to production.
build product teams not project teams
Tracy Bannon recalls a famous saying in the contracting world : code, load and hit the road. Unfortunately developing software as a project promotes developers' disengagement. They are being pressured to deliver a list of features and once it's done, they are moving on to a different project.
Healthy software products cannot get built as a project. Unfortunately large organizations and governement's agencies ways of solliciting bids on contracts encourage such software failures.
Consulting firms should promote developer advocacy by educating their clients about the fondamentals of good software.
Good software is built by teams with a shared vision. Developers who care about the product. Developers who care about the end users.
promoting developers' education
Bryan Finster bluntly states that "colleges and bootcamps do not output good developers". Hiring junior developers entail the need to educate them to fullfill the business needs. Tracy Bannon talks about a recalibration of their skills. She uses the term 'influence forward' by putting forward the need, for the software industry, to go to colleges to discuss about what skills are needed for future developers. She underlines that some large tech organization had already form bonds with certain institutions. But such initiatives are still scarce.
According to the panel, developers are not deliberate enough about their purpose and their careers. They often use their own free time to level up their skills. With no long term target in mind.
Bryan Finster declares that it is not acceptable for developers to have to learn about software quality or software security as a side project. The best developers spend their own time to better themselves ; in a non formal way of learning.
In job interviews, when asked how they stay current and improve in technology most developers talk about personal projects and learnings done on their own time ; not during work hours.
Until developers are considered code monkeys we will need developer advocacy to improve the software industry.
