Development Process, Technical Leadership

FAQ for Your Project Manager


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!

questions photo

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?

disaster photo

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.

building photo

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.

Development Process

Fighting the ‘Almost Done’ Syndrome


There’s a popular joke that 90% of software projects are 90% done, 90% of the time – and unfortunately it does have some truth behind it. But does it have to be this way? How can we, as leaders, ensure that our teams avoid this trap and deliver completed features in a predictable way? Here’s a few tips from my own experience.

We’ve all been there: your team is working on an important project (all projects are important, right?), and when the release is just around the corner you suddenly find out that there’s still a lot of work to connect all the dots: system integration does not work, performance is unacceptable for larger data volumes, edge cases in business logic are not properly handled, and so on. Your team ends up coding some last-minute patches, working late evenings or weekends in much haste, making mistakes. Once you release the software, the users experience some serious bugs and you have to spend several days or weeks before the customer can actually benefit from the application.

The client is unhappy, your employees are burned out, and your reputation suffers – not a result that anyone would want. So how can we prevent this ‘Almost Done’ syndrome, how can we ensure that we don’t get last-minute surprises calling for hasty patching again? There are multiple aspects that you need to take care of to succeed.

The Mindset

It’s natural for all of us to prefer simpler tasks over more complex ones, and developers are no exception. They will tend to put off the latter and overly focus on the former. It doesn’t mean they will avoid doing difficult work, just that they will choose to complete the parts they perceive as simpler and more clear first.

For example, when someone feels comfortable implementing complex algorithms and does that frequently, they will tend to focus on that part of a new feature, and may be putting off other important aspects – like detailed analysis of the business process, or a discussion about some integration details with another system’s developer.

What can happen without proper self-control is that developers will keep polishing one area or switch to other tasks, in order to avoid working on that least comfortable 10% of the feature. It’s natural, we all have such temptations, and the first step to fight this problem is admission. Once you and your people realize it, it’s a good ground to build your process improvements on.

Limit Work in Progress

There’s a simple yet beautiful concept in Kanban called WIP (Work in Progress) limits. It’s usually understood as the maximum number of tasks in progress for the team. When it’s reached and a new important task enters the queue, the team usually needs to focus on completing at least one of the previous tasks before they can begin it. Such approach does allow for some exceptions, but it greatly helps in making sure the team members don’t jump between tasks without control, leaving many loose ends.

You don’t actually need to follow Kanban or any other Agile practices to introduce this type of rule. You can also adjust it: sometimes you might be better off with a per-project limit (e.g. when your team is developing multiple applications) or any other variant that fits your environment best. The crucial thing is that you coach your developers to finish one task before starting another (at least in normal situations).

Definition of Done

The approach of WIP limits (or similar) will help your team avoid unnecessary multi-tasking, but a common understanding of what it means that a task is completed is also needed. Such definition should include all steps required to be performed before a feature is released as part of the new product increment (e.g. into UAT environment).

A sample Definition of Done would include steps like:

  • Code changes are checked into the repository,
  • The CI build is successful,
  • The feature is tested in DEV and all bugs are fixed,
  • Integration with other components is verified,
  • A peer review is performed,
  • and so on.

It’s usually best to write these steps down and make them visible to all team members, all the time.

Acceptance Criteria

Another aspect to work on is defining clear acceptance criteria for new features of your system. They should include both functional and non-functional requirements, so remember to clarify the expected load, frequency of the feature’s use, platforms that need to be supported etc. in discussions with your customer. Don’t forget about technical quality factors, such as maintainability, extensibility, or scalability.

You can consider including such acceptance criteria in your team’s Definition of Done too. While many of them can be difficult to describe precisely, your developers need to remember that the software won’t really be ready for a release until those requirements are met, so they need to design, code and test with all of them in mind, and not keep putting that work off till the last week of the project.

Clear Action Ownership

Many cases of loose ends occur due to miscommunication when making agreements on some side tasks (not directly related to coding), e.g. arranging some infrastructure change or confirming some edge case of business logic with the customer. I have personally run into this many times – everybody was thinking that someone else will do it, and in the end we had to rush it or just accept the risk.

To avoid such cases, make sure every action – even the smallest one – has a clear next step and an owner assigned. Coach your team members to finalize every discussion with a short summary of who-does-what, so that it doesn’t require your personal control.

Releasable Increments

Probably the best way to ensure your product will be ready for a release on the big day is to keep it always ready for a release. That can be achieved by employing a process of Continuous Delivery, where you can actually push the software to target environment at any time you want, with minor cost (‘one click’, ideally), and verify its completeness then.

However, as this technique is not very common yet and may take a long time to implement, in the short term you can at least ensure the ability to release a product increment that is created at the end of every iteration (sprint, milestone or whatever that is in your methodology). You may not be able to verify releasing it into the Production environment, but even running it on staging or UAT machines should help polish the system. It should allow you to spot and eliminate most, if not all, of possible issues with configuration, infrastructure and integration with other components.

So keep your product releasable during its whole lifecycle. Leaving that for the last week or month can often cause serious problems.

Realistic Test Data

One big source of surprises in the final phase of a project is the lack of proper test data during all stages of development. In many cases your team won’t be able to use real data and you will need to rely on fake, auto-generated sets. In such case, make sure the sets are large enough and allow to verify the system’s state not only at day one (when the database could be almost empty), but also after 3 or 5 years of its continuous use. Also, ensure that the data contains a wide range of values and includes edge cases.

The problems coming from data itself could go from simple too-long-to-display types of defects, to large performance/scalability issues that require a part of the system to be redesigned. It’s much easier to design and code for the expected volume and some data anomalies from the start, so ensure that this information is provided to your team and make the development environment reflect that.


The above advices won’t guarantee you a successful finish, but they should lower the risk vastly and allow your team to focus on other things in the last few weeks before the release. Of course there are many other aspects to take care of, like the estimation process or integration with other systems, but I hope this article motivates you to think through the topic and select items to focus on in your team’s context.


Development Process, Technical Leadership

3 Simple Code Review Guidelines


I have recently expressed my aversion to code review platforms. Assuming I managed to convince you, the next valid discussion point would be: if we’re not using a tool, how can we ensure the code reviews are effective and efficient? We could spend all night discussing the details of various approaches. While they always need to be aligned to a particular team and project, here is a shortlist of the main guidelines that proved to be beneficial in multiple projects for my teams.

Do it together. I’m a strong supporter of performing your code reviews in pairs. I believe you can get the most value with the least effort when both developers (code author and the reviewer) are looking at the same screen, talking to each other: asking questions, explaining, advising. The pairs should not be fixed, otherwise you will limit knowledge sharing and increase the risk of conflicts in the team.

Do it early. ‘Early’ meaning: as soon as your current task is coded, or even during its implementation (if it’s complex). The earlier you get a second opinion, the easier it is to change the code. While it might sound ‘unfair’ to ask an ‘innocent’ person to drop their work and review your code, my experience is that it actually improves the flow within the team. Try it and see for yourself.

Do it often. Daily code reviews can be very helpful in case of fast-moving teams that are building new systems. For maintenance-oriented teams you can adjust the period to fit the need. My preference is to keep the sessions under half an hour, so if they tend to overrun often, it may be a sign that they are not performed frequently enough.


How can we ensure that code reviews are not missed in this approach?

Make them a part of your Definition of Done. If it’s enforced properly, developers will have to perform them before moving on to another task (the concept of Kanban WIP limits can be helpful here). A development task without a code review should never really be considered ‘Done’, as some reviews can result in significant changes to their implementation.

What if all code reviews are performed by the manager/ lead in our team?

If you’re that manager – stop it. You won’t keep up with doing it properly, and you’re taking other benefits off your team members. Coach your developers in reviewing each other’s code and offer your help whenever needed. Leading an inexperienced team can be more challenging of course and requires exploring additional techniques, but avoid putting yourself as the only reviewer – your goal should be to have a self-driven team, and that’s an important part of it.

What to do in case of distributed teams?

That’s simple nowadays – use a phone and screen sharing (yes, both audio and visuals – that’s very important). If your team is distributed, you should already have this figured out anyway. As with many other practices, avoid separate locations to be an excuse for limiting communication within the team. It’s not the same as with face to face reviews, but try getting as close to that as you can.

But we’re already doing pair programming…

In that case you should already be getting most of the benefits described here – assuming you’re applying the practice properly (I may write about it one day, too). I would still recommend to occasionally bring in a 3rd developer to have a fresh look at the critical pieces of the code, but in general your team is in a much better situation already.


At the end of the day, it’s important that you promote a culture of close collaboration and open discussion in the team, and the way code reviews are performed can have a significant impact on this matter. If people avoid discussing with each other and hide behind a tool, that’s going to cause more and more problems in the long-term. Instead, follow a light but strict approach of frequent, short reviews performed in pairs, giving an early and direct feedback about the code changes.

Please feel free to describe your approach to code reviews in the comments.

Development Process, Technical Leadership

Code Review Systems Are Harming Your Team


Code reviews should be an essential practice in every software development team. As an industry, we are long past the discussions about whether to perform them at all, focusing on implementing them in the most effective way instead. As with many popular practices, some companies offer tooling that promises to lower or even eliminate the hard parts of it. You can tell from the title that I’m not a huge fan of those.

Problems with Code Review Systems

To be clear, I am writing here about systems that support offline (or ‘asynchronous’) code reviews. You send the code changes to another team member through the system and get their approval or suggestions back after some time. They are meant to save time by eliminating the need to meet and chase people, but they actually harm your development process in multiple ways.

Decreased knowledge sharing. Besides identifying code issues, another benefit of code reviews is an opportunity to share knowledge and experience between team members. And it works in both ways – the reviewer and the code author can give each other additional insight into a specific part of the system, technology, business domain, and more. It’s not something that would normally be entered in code review comments, many such things come up during a conversation between developers.

Communication issues. Teach your people to avoid talking to each other and you’re asking for big trouble. Giving ‘code advice’ is a very delicate matter, it’s easy to offend someone just by using the wrong tone of voice, and it’s even more difficult to control such effects in writing. Developers usually approach this in one of two ways: some avoid the possible confrontation by giving ‘standard’ comments, and others just directly write their opinion, not caring about how it will be interpreted. As you can guess, both ways cause problems.

fight photo

Lower job satisfaction. Many developers actually enjoy showcasing their work when they feel it was done really well – it’s like showing our precious baby to friends. Having it reviewed by someone offline is not really the same thing. You don’t hear the reaction or see the look on their faces while you guide them through your brilliant solution…

Less pressure for quality. I believe that most people (not just developers) do a better job when they actually have to show and explain the results to someone else. We all want to appear smart (or at least avoid humiliation), and we are often willing to give extra effort for that. Again, it’s a stronger effect when you do that in person.

Interruptions. Do you think you’re limiting the interruptions in your team by queuing the code reviews in a tool? Think again. What you are actually doing is replacing a small interruption with a larger one. In most cases, it’s just more difficult to shift your mind from one coding task to another, than from coding to reviewing (and back).

For instance, imagine a developer finishing a coding assignment. He puts the task into Pending Review status in the system and starts development of another feature, shifting his focus to a different problem. Then, after a few hours (or even days), he receives a list of required fixes from the reviewer. He goes back to the previous feature, possibly interrupting the new task. How much time will he lose to switch back to the original context? How many little details has he already forgotten about? How many issues it will cause? What is his motivation to change a feature he has already (mentally) closed?

The Good Kind of Tools

Having stated the above, I definitely support and encourage utilization of static code analysis tools, like FxCop and StyleCop for .NET developers. I believe such tools should be an important step in every mature build process. They give you multiple benefits without any significant drawbacks, and require only constant (i.e. independent of project size) time to set up.

Another scenario is audit documentation, e.g. PCI. It’s easier to keep code review evidence for such purpose in a system rather than on separate forms, but it should only be used as a means to document code reviews that were performed, rather than as a replacement for them.


For every automation opportunity you need to carefully review both sides of the picture. While ‘offline’ code review systems can save you some time in the short term, the long term results will vary from some missed opportunities at best, to significant communication and quality issues at worst. I’m not saying ‘don’t use them at all’, but if you decide to utilize such platform then make sure it’s not used for all reviews, and it’s not an excuse to avoid direct communication and important discussions within the team.

At this point, a valid question would be: if we avoid using code review systems, how can we make our review sessions effective? That’s going to be the topic of my next article.