This website uses cookies for analytics and to improve provided services. By choosing I Accept, you consent to our use of them and other tracking technologies according to our Privacy Policy
How to decode what developers say blog post featured image

How to Decode What Developers Say? A Guide for Non-tech Project Managers to Mitigate Risks

As much as we all love our developers, sometimes it’s hard to understand what they really mean when they talk about work. 

Deciphering all of the abbreviations they use and the jargon they throw around during daily stand-ups can be difficult, especially when you’re doing everything in your power to make sure that the project runs smoothly. After all, what does “A feature needs refactoring” really mean to the average person? Is it something bad? Will it have considerable impact on the scope or will it require just a minor change?

This post is powered by our Head of Technology—Tomasz Kania-Orzeł.

Sometimes, we tend to shrug off issues or terms that aren’t exactly clear to us or get brought up at every stand-up by default. Left unchecked, however, problems like that tend to blow up in the most unexpected moments.

The consequences can be numerous, and none of them pretty. You might end up with a severely overengineered product or miss your delivery deadline. The product may end up failing to reflect business requirements. Multiple bugs may “suddenly show up” in the production code. Finally, the client might not want to pay for a delayed or buggy product or developers may want to drop out of the malfunctioning project.

And so, we compiled this brief guide to help you avoid consequences like these and to improve the communication between your PMs and developers. It will help you understand what developers really talk about and decide whether you should be taking action to mitigate the risks ahead.

With our guide in hand, you will be able to tell when they’re overengineering a task or when they lack the necessary knowledge. To make use easier, we’ve split the contents into three categories of risk in terms of severity, which will let you know how fast you should be moving in order to neutralize the potential threat.

Yellow Light

Let’s start things off easy. A yellow light means you may run into a small delay in the project's timeframe or problems in feature delivery. However, you still have enough time to take action and deliver the sprint without major hiccups.

You will know a yellow light has flashed when you hear or see the following:

  1. A library/plugin is incompatible: means that the pieces don’t match. The task that the developer is working on will take longer than planned.
  2. A developer needs to reconsider their strategy for a feature: well, this usually means that you will have to scratch all of the progress for this task and that the time spent on it so far failed to yield any results. If a developer raises this issue early, there’s still time to cut the feature out of a sprint or change its scope.
  3. No information about the architecture of third-party APIs: means that your team feels lost, like babies in the woods. Developers can start working, but they won’t be able to complete some tasks. Often enough, issues like that stem from lack of documentation that should be delivered by the client.
  4. Developers are not reusing the code from other projects: means that your team is probably reinventing the wheel. Instead of drawing on past projects for a specific, reusable piece of code, the devs, for one reason or another, intend instead to write it from scratch (more often than not, that reason is lack of communication between projects).
  5. Junior developers are working without supervision: the car is picking up speed, the driver’s asleep at the wheel, and nobody’s wearing seatbelts. In all likelihood, the code you end up shipping will be buggy and need additional work.
  6. Developers finish working on features too soon: miracles every once in a while are nice and all, but two weeks of uninterrupted successes should raise eyebrows. Either tasks lack key information or developers don’t read the requirements carefully. Either way, most probably the delivered features won’t cover all the use cases they should.
  7. Developers create tasks without the necessary business knowledge: means that your team, rather than the client, is deciding what features the application should have. That’s a big no-no.

Orange Light

Usually means that things are getting serious. If you encounter any of the situations described below, you probably won’t be able to deliver the features without any hindrances. The developers will be able to do some work, but blockers will prevent them from delivering the full planned scope.

You will know a orange light has flashed when you hear or see the following:

  1. A feature needs refactoring: means “We did it! Well, almost.” Although a portion of the product was delivered, it still needs work.
  2. The staging/test environment is not ready: means that you won’t be able to either see or demonstrate the results of work already completed.
  3. Developers don’t know how to set up the production build/release environment: “Well, we created this thing for our client but we’re keeping it in our basement.” This means that there’s no strategy in place for delivering the product to the client. This can also mean additional costs if, for example, you need to suddenly set up a cloud environment.
  4. Frontend waiting for backend: means that some developers are sitting idle, so the sprint/tasks need to be adjusted. Solutions? Frontend developers can instead run through tasks that don’t require backend to be ready, or the backend parts can be delivered iteratively so that the frontend devs have something to work with.
  5. Developers are not preparing tests or omit them completely: although developers should strive to always deliver top-quality code, no one can do so 100% of the time. Consequently, not having a testing framework in place can blow up in your face later, in the form of bugs or performance issues. If time is short, tests should be performed at a later stage.
  6. A junior developer is making decisions about architecture and technology: means that you have a rookie on your team with live ammo in their weapon. Even if all the regulars or seniors on your project are on sick leave, a junior should never be allowed to make decisions of that caliber. Often enough, junior developers simply don’t even know what knowledge they lack.
  7. Lack of DoD (Definition of Done): “We’re completing our tasks, but who knows if we’re getting the job really done?” That means that there likely is some crucial part of the delivery process missing and you need to work on defining it.

Red Light

This is when you know your ship is really starting to take in water. There are some major holes in the project and, while you can still fix them, considerable delays in the delivery schedule are probably going to be unavoidable. Problems like these can occur in projects both big and small, and there’s no particular set of circumstances that would always precede their emergence.

Fortunately, the situations listed below are rare, because in most cases the Project Manager would have to be completely delinquent in their duties to precipitate their appearance. However, if you see them in someone else’s project, you’ll know they need help.

You will know a red light has flashed when you hear or see the following:

  1. Sprints are passing, but no features are coming: means that the client is paying for nothing. It’s a major issue that usually means delayed costs and potentially more grave consequences.
  2. We don’t know how many bugs the application has: means that no one is checking where the pipes are leaking. You should always know your bug count and your test coverage.
  3. Releases are very rare (lack of routing production/staging deployment): when releases are rare, they tend to become major events—balloons, popcorn, and confetti celebration style—that stifle productive work. A healthy setup allows developers to release their work without turning it into an event.
  4. The Quality Assurance specialist doesn’t have time or is behind in the testing schedule: means that QA is overburdened, causing a major bottleneck in the process. The most common solutions involve rearranging the tasking schedule and adding more QAs to the project.
  5. The developers don’t have time for Code Review: means “We’re going so fast that we’re past caring for quality.”
  6. Switching technologies during a project (changing framework/language): means that we started building a house with the wrong materials. Usually, the reason why developers would want to change technologies is poorly planned architecture.
  7. One of the developers refuses to listen to the experts: means that you have a lone ranger on your hands. If someone refuses to comply with the decisions of Subject Matter Experts, not only will it cause unwanted disruption in your team, it may also result in the final product being suboptimal.

The Main Take-Away

Understanding developers can be hard at times, but we have to learn to communicate effectively, otherwise it’s the work we do together that suffers. When we’re not exactly sure what we’re hearing, it’s easy to dismiss that misunderstood piece of information as unimportant.

I hope this post will help you develop a common language with your fellow teammates. While you don’t have to start speaking in acronyms yourself, it’s good to know the meaning behind most of them.

And here's a handy glossary of technical terms for dessert. Enjoy! (Simply download it by clicking the image below)

 

What's the Future of Proptech Development?
10+ Ways to Optimize Your App Development Cost
jitsi illustration Jitsi, a Video Conferencing Alternative to Zoom and Google Hangouts