I decided to summarize some of the most frequently asked questions that I’ve been receiving throughout my career as a development team leader or manager. They usually come from project managers and product owners, sometimes also from stakeholders or customers.
I believe many of us often need to respond to the below, so putting these all together might save us some time. Feel free to copy & paste the answers as needed!
1. Why is such a small change taking so long?
- What might seem as a small tweak, can sometimes require re-designing a part of a system, if we didn’t originally predict that this particular aspect might need to change. And no, it’s not possible to predict all possible changes. Even if it was, you wouldn’t be happy with the cost…
- Aside from making the code change, we have to test it, ensure it doesn’t affect anything else in the system, deploy it and verify in various environments (development, test, staging, production). No, we can’t take shortcuts if you don’t want to risk a major production failure.
- Even when making tiny changes, magic can happen and we are never able to predict the impacts with full confidence. That’s just the nature of software development.
2. Why is it so expensive?
- As developers, we have to take many aspects into account: code quality, security, performance, scalability, maintainability, usability and more. All of these require attention from the team. We have to plan for those concerns, verify them, write automated tests, etc.
- Yes, we are putting business value as our top priority. We’re just not thinking about today’s business only. What will be the business value of the software if it stops working after the database exceeds 100K records? Or when hackers bring the website down? Would you accept a huge cost of future enhancements if we take design shortcuts today?
3. Are you sure it’s bug-free?
- No, and we can never be sure. Even worse – every larger piece of software has bugs. That’s just one more thing to accept in this industry.
- There are many factors that can cause issues, code is just one of them. Some of the other ones are: network infrastructure, server and client hardware and software, system integration mechanisms, web browsers, etc.
- We are using tens or hundreds of third-party components. Each of them may contain bugs. No, we cannot get rid of them if you want the release to happen this decade.
- Even when all the other components are fine, there’s a risk that we missed some edge case that nobody ever thought of – not even the analysts or the users.
4. Why can’t you just add more resources to finish earlier?
- First, developers are not resources. They are not interchangeable, and you cannot easily add or remove them with proportional impact on the results.
- Recruiting developers can take a long time. If we hire the wrong person, the impact on the project could even be negative.
- Training developers takes time. The more complicated the system is, the longer it will take before a new person is fluent on the project. And they will make more mistakes that will need to be corrected by other developers.
- All of these require time investment from the team, which will leave less time for growing the product. That’s why you won’t usually get any short-term benefits. Oh, that next month’s release you wanted to speed up? Better move it till next quarter.
5. Why can’t you tell me when it will be done?
- We can estimate, at best. We can never predict with full certainty.
- As explained, even the smallest and simplest change can have unpredicted complications.
- Every task is a bit different. Even when building similar features for the same application, the related code areas might have been designed differently. Until we start working on them, we won’t fully know what lies beneath.
- Even if tasks were identical, people working on them can vary in skills and experience. The differences in development time between team members can sometimes be an order of magnitude.
6. Why are you less productive than that other team?
- How do you know that? How can you measure that? How do you define ‘productivity’ at all?
- Every team is different – different people, skills, experiences, distractions, additional duties, etc.
- Each team may be following a bit different set of practices, which have an impact on development time, as well as quality of the final product. For instance, some teams write unit tests, which increases development time, but also improves the system’s long-term maintainability (when applied properly).
- Every system is different. One could be based on more problematic technology stack, have poor design, less readable code, etc. Or, quite contrary – it might actually be designed in a better way, having better security or scalability, at the price of more expensive future enhancements.
Are you getting similar questions frequently? Or maybe you have other typical examples? Please share your thoughts in the comments.