Decoding the Black Box of Developer-Speak
“We need to refactor the API gateway to leverage dynamic polymorphism for optimised container orchestration in the cloud-native microservices architecture, ensuring seamless CI/CD pipeline integration with idempotent operations.”
Yeah. Ok.
As non-technical executives responsible for complex projects, we have all faced situations where an expert responsible for implementation has been asked a question (usually regarding the status of their work against the estimated timeline) and been hit in the face with an answer like the above. Are they testing me to see if I know what they just said? Are they intentionally trying to obfuscate the work that they’ve done or make it sound more difficult than it is to justify the time taken? Is it (as in the case of the given example) just nonsense?
It becomes even more challenging when a single developer or a small group, are working on a feature or unit that is difficult to decompose any smaller but still requires dedicated time and effort. You may find yourself staring at a black box, where you have fed business requirements + developers in, and you’re just waiting for the right outcomes to pop out of the other end.
Of course, if you’ve done your discovery work, setup & preparation and hired the right personnel then the chances are, you’ll be ok. But who wants to run a business like that? In the likely event that things don’t go 100% to plan for the whole project, you want to be able to quickly identify where things have gone wrong, ideally before they affect any other parts of the project, the budget or the timeline. You need to be able to make responsive course corrections. You need to be able to mitigate the risks but within a reasonable margin of error so as to not waste resources. But you can’t do that blind. You need to be able to see inside that “black box”. And developer-speak is not going to help you get that much-needed visibility.
developer-speak /ˈdɛvələpə spiːk/
noun
The specialized language used by software developers, characterised by technical terms, abbreviations, and jargon that is often incomprehensible to those outside the field.
“The meeting was filled with developer-speak, making it difficult for the marketing team to follow along.”
How to Solve for Developer-Speak
Aside from becoming conversant in “developer-speak” there are a few techniques that I have found work well for cracking open that black box and maintaining a healthy level of oversight when working on technically complex features or projects.
1. Decompose, decompose, decompose
The first step is always to attempt to break everything down into the smallest units possible. Project management training would teach you to get this into discrete user actions but this isn’t always feasible. However, utilise the technical expertise you have in your team to work out the smallest task units that are able to be “completed”. In practice that might mean:
- What can be finished within 1–2 days?
- What can be tested independently from anything else?
- What would be a good stopping point if you needed someone else to take over from your work?
It doesn’t need to be all of these, but it could be more than one. Even if you’re not able to understand the intricacies of what those individual tasks involve, you will be able to get a straight answer to “Has it been done?”
2. Track Everything
Once you have the granular tasks from the overall feature, make sure that you have a workflow that allows every aspect to be tracked. You don’t want to be unnecessarily onerous to the people working on the tasks, otherwise, they simply won’t update the statuses and you’ll spend all your time asking them to do so which is counterproductive. But you need to make it simple for them to be able to give an update on the small, incremental progress that they make each day or two. Not only do you want to track what has been done, but you want to track retrospective effort. That is, how long did this take vs how long you thought it was going to take? In the spirit of continuous improvement, you’ll be able to use these revised estimates for future work and it allows the development team to benchmark against this work. It also allows them to expect the unexpected that caused the original estimate to change. Keeping track of time/effort, both beforehand and after the status has been updated, as well as a lesson-learned log, forces things to be explained in plain terms, and tracked sufficiently so that you can intervene if anything doesn’t go to plan.
3. Focus on End-User Benefits and Outcomes
When communicating with the team, the end-user benefits should be clear to everyone. Yes, the decomposition and tracking matter but the most important thing is what happens at the end. Once it’s all said and done, can the end user do what the acceptance criteria says they should be able to do? Of course, the reason we are in this developer-speak black box is that there are many technical requirements that don’t have a direct user impact in isolation. But even when focusing on these nuanced and highly complex technical requirements, the focus should always go back to whether this will benefit the end-user in this function. Whether that is done by always keeping the functionality in mind without getting caught in the weeds or by not introducing anything superfluous to requirements, all of the effort must remain aligned to the main outcomes for the user benefit.
4. Ensure Items are Delivered and Tested Frequently
I have had bad experiences with this. Everything seems like it is going smoothly. The tasks are broken down into the smallest reasonable increments. The whole team is on board with what needs to be done and why it should be done. The statuses are being updated daily. But there seems to be a bottleneck and the testing team aren’t receiving anything for weeks. It’s not even on the testing environment. What had been demonstrated was on the local environment and actually, no code has been pushed for a while now. Whether this is the result of a bad actor or a systemic failure on behalf of the management, the lesson remains the same. Ensure that frequently, daily if possible, new commits are being made and that they are making their way through the workflow alongside the status changes so that the testing team can test these small increments independently and frequently. This way, no one can hide.
Conclusion
Overall, most developers I have worked with have been honest, hardworking and forthright with everything we have done. Sometimes, objectives may not be clear, or the client can be frustrating but rarely have I worked with lazy, dishonest or incompetent teams. However, the tendency to explain things in the language that we speak is natural and if something is technically complex, it is likely to be difficult to simplify for non-technical people. This isn’t an indictment of developers, but rather a way to align two sets of understanding to reach a common goal.
