Understanding software optimization techniques

Eng. Effectiveness, Dev. Experience, Dev. Productivity Engineering.... oh my.

If you’re an engineering leader, then you are most likely looking to improve the overall output and predictability of your organization. Why wouldn’t you? Budgets just seem to be getting tighter and tighter these days without lower expectations on delivery.

So what do you do? You start with looking around at what some of the “elite” engineering companies are doing or maybe go to a few conferences. After that, its still hard to identify the best ways to optimize. As with a lot of things these days, there isn’t a lot of consensus in the market.

There are a few concepts that seem to come up a lot, Engineering Effectiveness or Excellence, Developer Experience, Developer Productivity Engineering or just Developer Productivity.

They are a tangled mess of concepts and techniques that get used interchangeably in a lot of organizations. Are they all really the same thing? Do they have a different focus? Let’s start by digging into what each of these actually mean.

Developer Productivity

We have to start with this one… as I see this having the most damage. I am sure there are a lot of people using this as a bucket term, but I really don’t like it. This term, to me, really seems to put the blame for organizational and experience inefficiencies at the feet of the developers.

The term Developer Productivity leads me to believe the problem is that developer are not typing fast enough. You can see this with the major push for tools like Copilot, which in my opinion is just a typing accelerator. Valuable, yes. Is it the major problem inside of an organization, no.

There have been numerous studies and surveys that show developers only spend about 25-30% of their time actually typing code. Most of the work has to do with finding information, defining the problem, understanding business logic, and solutioning.

If you think about the problems that come up in these activities, is it really a typing accelerator that is going to solve them? No its not. This is why so many companies are struggling to get real value from these types tools and not really understanding what the problem is.

Everyone has to work within the system that has been defined for them. If you don’t optimize the development ecosystem, then how are people going to work efficiently in it? Are there bad developers that don’t put in a lot of effort… sure there are… but there are lazy people everywhere.

It is almost always a bigger systems level problem that causes “productivity” issues.

That said, so where do you being then? This is where you need to figure out the right level of impact? Do you have the ability to impact the organization? Or is this a bit of a grass roots effort?

Engineering Effectiveness/Excellence (EE)

This is the broadest, top down effort that can be taken on but comes with the biggest returns. if you ready for a journey with the most impact, then this is the place to start.

This is like architecting the highways and roads that connect different parts of your organization. Get it right and get massive gains but get it wrong and you will have another mess on your hands. This is why having good plan is so critical.

The impact of organizational decisions can’t be understated.

Check it a deeper dive article at the link above!

Enough of the nonsense, so what are we really talking about here? Lets look at a few examples.

• Agile Planning & Funding

• Architecture

• Cloud Strategy

• Enterprise Testing

• Governance & Security

• Knowledge Management

These are the biggest decisions that need to be made in an engineering organization and will involve decision makers up to the CIO/CTO/CEO.

“The system that people work in and the interaction with people may account for 90 or 95 percent of performance.” 

- W. Edwards Deming

This can feel like a daunting set of tasks that is too much to take on. It doesn’t have to be, if you take a more tactical approach to this problem. First off, you would rarely want to tackle many of these at the same time.

That said, then how would you know where to start? Very rarely do people in an organization not know where the major bottlenecks are… they just need a safe way to be able to express that. The details are out of the scope of this article but I do dig a little deeper into ways to start to tack this problem in this article.

This top down approach can have a significant impact on overall culture, improve moral, and can be the catalyst for future improvements. Just showing that there is progress being made, even if slow, can have a significant impact on an organization.

Engineering Effectiveness doesn’t stop at organizational problem though, using quantitative and qualitative analysis will help to identify lower level problems. These problems are key inputs into optimizing the development process. They are a good indicator of where to start digging into lower level areas for optimization.

Developer Workflow Optimization

This is where things can start to get a little bit confusing. To keep it simpler, I am going to wrap up these concepts into development focused optimization. There are many ways to drive optimization across an engineering organization, including:

• Platform Engineering

• Developer Productivity Engineering

• Developer Experience

They do have overlapping and complementary features. But before we get too far, let’s do a quick (and probably wrong) definition for each of these terms.

Platform Engineering (PE)

PE is the focus on building out a cohesive platform that provides essential infrastructure, services, and tooling to the development community in a self-service manner. Their goal is to abstract away complexity, standardize common workflows and reduce the operational burden on development teams.

Think about PE as optimizing the Ops side of DevOps

Developer Productivity Engineering (DPE)

DPE is focused around the optimization of the development process itself. This could be streamlining work workflows to reduce overall toil, bottlenecks and friction. Their goal is identify and address these pain points across the SDLC and help to automate repetitive tasks, reduce steps, and provide guides to help improve quality and security.

Think about DPE as optimizing the Dev side of DevOps. This is similar to how SREs help with overall resiliency.

Developer Experience (DevEx)

DevEx is all about the overall quality of the developer’s interactions with the technology, processes, and their work environment. Their goal is to create intuitive tools and interfaces, reduce cognitive load, and improve overall developer satisfaction

DevEx is is like applying a better user experience/design to to an application UI. They are not changing the functionality, per se, but they are making it easier to get things done. They are providing the right information, at the right time, for the right persona and job to be done.

It’s easy to get lost in definitions… but in the end its all about efficiency not term definition.

I know what you’re thinking… do I really need all three of these? Are they separate teams? Seems like an awful lot to do. Before we get to some of these questions, lets go through a couple of quick examples. I think this will help to clear things up a bit.

The first for any of these techniques is to identify the problem. If you started with an EE approach then you might have already identified some of the areas. If you are starting from the developer perspective, this would be a great time to do a DevEx survey to help identify areas across the SDLC to focus.

That said, on the examples.

Slow Build Times

The problem identified is that developers are frustrated with long build times, increasing work in progress, impeding quick feedback cycles, and is causing teams to deploy less often.

In this scenario, here is some of the work each area might focus on.

Platform Engineering

• Implement a distributed build system to parallelize tasks

• Introduce more powerful build machines

• Optimize the build configuration and identify unnecessary dependencies

Developer Productivity Engineering

• Analyze build data to identify the slowest stages

• Work with developers to identify areas where code can be modularized to reduce build dependencies

• Work with the PE team to identify and remediate pipeline tooling or library causing the slowdowns.

Developer Experience

• Survey developers to understand the specific frustrations and time wasted due to slow builds.

• Ensure clear and informative feedback during build process. This could be done though a developer portal with dashboards or other widgets.

• Identify metrics to help track build times, their improvement over time, and the associated costs to the organization.

Long Cycle Testing

The problem identified is that developers spend excessive time on manual testing, taking them away from feature development and introducing a sense of repetitive, unfulfilling work.

Platform Engineering

• Integrate robust testing frameworks into the developer platform

• Set up automated CI/CD pipelines with comprehensive test coverage

• Provide tools for test data generation and management

Developer Productivity Engineering

• Identify types of tests that are most time-consuming for manual execution

• Work closely with dev teams to adopt automated testing practices

• Work with developers to design effective testing strategies, promoting a shift-left mindset for testing.

Developer Experience

• Design intuitive testing UIs and workflows.

• Provide actionable feedback and insights during automated test runs.

• Help to identify architectural standards that track testing cycles, ensure standards are being met, and give feedback against the standards. This could be through the building of scorecard mechanisms and also be used by the PE team as part of a gate keeping mechanism.

Onboarding Friction

The problem identified is that new developers face a steep learning curve when joining a team. Complex toolchains, fragmented documentation, and unspoken tribal knowledge lead to frustration and delayed productivity.

Platform Engineering

• Consolidate and streamline development tools into the internal developer platform.

• Standardize project setup procedures.

• Provide templates and boilerplate code to kick-start new projects.

Developer Productivity Engineering

• Identify specific bottlenecks experienced by new hires. For example, code complexity, architecture, a really stubborn tech lead.

• Track success rates of completing initial onboarding tasks.

• Automate the creation of sandboxed development environments where newcomers can experiment safely.

Developer Experience

• Measure onboarding time and time to 10th commit.

• Create a well-maintained internal knowledge base with clear documentation and tutorials.

• Design a structured onboarding process with checkpoints and mentorship opportunities.

Need help trying to get all of this figured out? We are here to help!

Learn more at thinkbigcodesmall.co

Where do I begin?

It really depends… spoken like a true consultant… I know and I’m sorry :-). But to give the longer answer, it really does depend on the size and maturity level of your organization.

If you are just getting started on your journey I would start with the following questions.

How much control do I have over the organization? What are the problems that I am trying to solve? How much risk/time and I willing to commit to this

If I am a CIO/CTO looking to get find major productivity improvements, then start with Engineering Effectiveness and work your down the stack. In parallel, I would also start understanding the Developer Experience and work your way up the stack. The top down and bottom up approach will quickly identify areas where Platform and Productivity Engineering can step in and help.

This is a sizeable transformation project that takes a lot of time, energy, and resources but it will have, by far, the most meaningful impact. I have seen upwards of 50% gain in throughput and business impact through these types of engagements.

That said, not everyone has this type of control, time, or appetite for risk. There are much smaller ways to start to optimize software delivery. Instead of the top down approach, mentioned above, go from the bottom up approach.

This is starting with Developer Experience and working your way up to Platform and Productivity Engineering. By mapping out and measuring the impact of the developers experience through the SDLC, you can easily come up with areas of waste and friction. Start to improve these systematically over time, your developers will thank you.

The best time to plant a tree was 20 years ago. The second best time is today.

Optimizing software development doesn’t need to be this big complicated thing, you just have to get stared to see the value. So think of these titles as mindsets.

This could be one small team that is focused around making improvements, showing value, and then expanding only when necessary. Or it could be a bigger transformation project. Do what’s right for your situation but don’t ignore the glaring problems that might be staring you in the face.

So go out there and get started.

So what do you think? Are you doing any of these? All of them? What did I get wrong?