What Slows Down Software Development

Delays in delivery is so common in the software development world, that it has become a common practice to include a ‘buffer’ time when giving commitments. And the sad thing is, we face delays even after including such a buffer. There are two sides to this problem – either the task has not been sized correctly, or the developers were slow in delivering. I thought of things that causes slow development and could find these major factors slowing down development for me –

  1. Starting Without Clarity
  2. Not Asking Questions
  3. Lack of Knowledge and Skills
  4. Not Getting it Right the First Time
  5. Not Considering All Activities
Photo by Braden Collum on Unsplash

Starting Without Clarity

Developers just break out their editors and start coding right away when they get a task. Almost always the task definitions will have gaps in them. It was probably written by a product manager or a technical architect. Only the developer will be aware of all the little questions that will arise while carrying out the task. So after taking a look at this task, ask questions that help you clear out any vagueness about the task.

Questions like ‘What errors must be returned?’, ‘Are there specific expectations on code quality?’, ‘Does the architect prefer using a certain design pattern?’, ‘Has the task considered its side effects?’ and so on, must be thought of by the developer when they start. Simply put, start with a clear end in sight.

Another thing that helps to achieve this, is to do test-driven development (TDD), where your tester first writes tests that are supposed to pass after the task is done. When you have actual tests, you have so much clarity on what needs to be done and can minimise the number of doubts that will rise later.

Not Asking Questions

There seems to be a lot of hesitation in today’s developers to ask questions. It mainly comes from either being an introvert, or by the doubt that your question might be stupid. Remember – Asking questions doesn’t make us stupid – making assumptions does.

And it also has a spiralling effect. The first time you might feel a little stupid to ask a question and carry on with your own assumptions, ignoring the fact that you are creating a gap in your own understanding. As time goes on and you avoid asking for clarity more and more, the gap keeps widening. At one point, you just can’t bring yourself to take a step back and ask your question for the fear of coming across as ignorant.

Stop worrying that your question might make you look less intelligent, or that you might be disturbing people if you raise questions. Software development is a lot about collaboration. People who don’t collaborate inevitably end up failing in their job.

Lack of Knowledge and Skills

As bitter as this factor may be, it is definitely a fact that lack of knowledge and skills in the developer is one of the top causes of slow delivery. There doesn’t even seem to be a motivation to learn for many developers. Even if the developer is dropped into a project where a new skills are required, often they don’t sit down and learn those skills.

Thanks to the wealth of snippets and quick-fixes available on Google and StackOverflow, it’s very easy to become a copy-paste developer. Just learn the basics of your programming language, and then use the internet for anything that’s required right? – Wrong. Even if every solution you find on the internet is suitable for you and you can finish most of your tasks by searching for answers on the internet, it’s going to make you a slow developer. A terribly slow developer.

You need to be able to do most of your work by yourself without searching for answers. The internet helps in situations when you are stuck. But if you need to search for almost everything you are doing, it means you are stuck all the time. It’s like repeatedly stopping to tie your laces while you are running a race. You will eventually finish, but your progress will be slow and rocky.

Invest time and effort to actually learn the tools you are using. Your language, the core libraries and frameworks you use, your IDE, your build system – these are the things that you should sit down and learn. There is a big difference in quality, speed and smoothness when a developer actually knows how to do their task rather than searching on the internet for every basic thing.

Not Getting It Right First Time

When you complete your development and merge it with the main codebase, you should be sure of what you have done. Have you thought about all error scenarios? All possible exceptions? What assumptions have you made? Have you communicated those assumptions and ensured they are correct? Have you thoroughly tested it? (Yes, a developer is supposed to test their development before sending it off to a tester)

Ensure that the tester won’t send it back to you. Or worse, it won’t end up as a user-reported bug. Or even worse, it won’t break the production system.

Making sure that your code doesn’t have mistakes and bugs are very easy when you are still writing it on your computer. Once your code passes on to the next phase, your mistakes become more expensive in terms of time to fix it. Think about finding a typo on your computer before you commit. Versus, the time to deploy it, have the user find the issue, reporting it back, it landing as a bug on your plate, then you fix and deploy again. Carefulness on your part would have saved that much time.

Time for doing bug fixes is usually not planned into project timelines. So whenever you introduce a bug and it has to be fixed later, it will take away time from something else. Imagine you are already assigned a task and suddenly a critical bug lands on your plate. You spend a couple days fixing the bug, and your original task now has two days lesser to complete.

The timeless proverb ‘a stitch in time, saves nine’ is one of the most important things you should keep in mind. When you work on completing a task, always remember, that you should get it right the first time. Don’t depend on the tester, or the user, to discover a bug. Consider it your responsibility and comb your work thoroughly to ensure you have covered everything – code bugs, user misuse, changes in integrated systems, unit tests, error messages, breaking compatibility – everything. Only then commit.

Not Considering All Activities

When you have a task and a target date, you need to consider what the target date means. Most of the time, when an execution team gets a target date, it means the task is supposed to be completed and available in production on that date. But in developer’s mind, it often gets registered as the date on which they should complete coding. Even when the developer is told specifically that the target date is when the task should be on production, it doesn’t create a concrete realisation in the developer’s mind.

You need to think about –

  1. The time required for your code to be reviewed and merged
  2. The time required for deployment on a QA stack
  3. The time required for the tester to run tests
  4. The time required for the tester to write new tests for your code
  5. The time required for you to fix any errors discovered by the tester
  6. The time required for your code to go to a pre-production environment
  7. The time you need to wait (for safety) on the pre-production environment before going to production
  8. The time required for documentation changes
  9. The time you need to deploy on production

Those are just a few things that come to my mind. You might have more than that (or less), but the takeaway is that you must think about how many things need to be done to call your task ‘completed’. You might think there is a lot of time for you to finish your task, but it’s simply wrong to take all the time to write your code and your tester gets two hours to test before it gets deployed to production. For example, when I get 10 days to complete a task, I usually find that I have 2 – 3 days to finish development and hand over for testing.


Of course those are just a measly 5 factors among several others that contribute to delays in software development, but in my experience, when intentions are good and the project is still delayed, those are usually the main culprits. More importantly, as a developer, those are the 5 points that are actually in your control. Fix them and you’ll stand apart from mediocrity. Be awesome.

Author: heppydepe

I'm Heppy Depe. (Read "Heppy" like "Peppy" and "Depe" like "DayPay"). Writing under a pseudonym because .. I dunno I just felt like writing under a pseudonym. I'm still trying to find the perfect picture of a fish to set as my profile photo.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: