While not every member of your software delivery team needs to be an expert in code, each team member should be proficient in the basics. The ability to follow development, ask questions and do better testing helps you deliver better value.
I’m a firm believer that every member of a software delivery team should be comfortable enough with software code to sit down and have a discussion with a developer or tester. I don’t mean that every program manager, business analyst or tester should be able to write multi-threaded JSONified RESTful web services backed by NOSQL web-scale sharded databases served by ActiveRecord data access layers. I wrote that, and I don’t have the slightest clue what I said.
Non-developers on a team shouldn’t feel they’re required to pair program or write code for delivery, but they should feel comfortable sitting down to discuss the work underway or upcoming.
Getting everyone on the delivery team to be at ease discussing code can have tremendous benefits for the overall value of the system they’re delivering. Reaching this comfort level doesn’t require years of experience — it just takes a willingness to sit down and practice a bit. It also takes a supportive environment where the learner can ask basic questions and start helpful conversations.
Recently, I had the opportunity to present an all-day workshop for TestBash Netherlands 2020, an online conference hosted by the amazing people at the Ministry of Testing. I adapted my workshop, “Coding for Non-Coders,” from a Ministry of Testing online course of the same name. I based the class or workshop on a few decades’ experience helping teams get better at collaboration by helping everyone have better conversations around how the software works.
I want to talk about what I shared with the workshop attendees, so let’s look at three reasons being comfortable with code helps your team deliver better value.
1. It Provides a Better Understanding of Architecture
As you build a system, its architecture needs to evolve. Simultaneously, you need a general plan on critical aspects such as how data flows or how to handle errors and exceptions.
Understanding error and exception handling can be a massive help to productive conversations around features and user stories. I’ve often found truth tables and acceptance criteria start in a far better spot when the business analysts and testers have a clear grip on this part of development. For example, “If we have an invalid input for the number of hours worked, then the payroll module will bubble up an exception, and we’ll see this error message at this web service endpoint. The UI, in turn, will catch that and display this sanitized message on the field itself.”
2. You’ll Cut Complexity
Complexity kills software. Time and time again, we make our code and systems far more complex than necessary. Methods get far too long, IF statements get nested in numerous levels, multiple input parameters get thrown into method signatures, and so on. While these sorts of things are fairly technical, they’re also visually apparent to a curious, non-coding partner sitting down with a developer.
They can ask a simple question that will dramatically turn around the direction of a block of code, thereby improving quality. For example, “This method is getting long. You’ve told me before we generally limit blocks of code to 20 or 30 lines max. Do we need to rethink this?”
3. You’ll Improve Testability
Being comfortable reading and understanding the basics of code means team members can more easily identify areas to focus on for testing. Using tools like test automation coverage reports can help people doing testing activities drill down into parts of the codebase that might not be covered. Just as importantly, those same team members can see what does not need testing—a critical piece to avoiding wasted, duplicated effort.
Test code is far simpler than most system code. Generally speaking, there’s no multi-threading, complex algorithms or advanced programming structures such as lambdas. This means newcomers to coding can get comfortable with the fundamentals of writing clear, readable code while following patterns for maintaining simplicity.
This offers great opportunities to write automated tests across the system at the unit, API or end-to-end level. Moreover, those newcomers should be pairing up with others to help their learning effectiveness.
Ultimately, You’ll Boost Your Value
“But, I’m not technical enough to code!” I’ve heard this many times through the years, and it’s rarely the case. Many “non-coding” team members understand a bit about how databases work and can write some SQL — that’s technical. Many team members have at least rudimentary ideas of how data flows between layers of a system — that’s technical.
Helping your team build a basic competency and comfort with reading and discussing software code, perhaps occasionally helping to write some, can dramatically improve your team’s value as a whole. It’s worth investing a bit of time in providing training for yourself and your team to support each other and your clients better.
