#project management
8 posts

A theorem of software engineering

Brook's law claims that adding people to a late project delays it further. This law is taken to be canon and is treated as fundamental by many engineering teams and managers.
Read more

A theorem of software engineering

Brook's law claims that adding people to a late project delays it further. This law is taken to be canon and is treated as fundamental by many engineering teams and managers. While this is some-what true, it's a nuanced statement and shouldn't be called a "law". This article confronts and examines this "law".

  • Brook's law is only applicable to projects that are only delayed. It doesn't apply to projects that are in progress and/or early in their lifecycle.
  • As a team leader, if you can recruit more people on your team, you should consider this as yet another tool in your war against project timelines.* The Shortest Possible Schedule (SPS) theorem on the other hand provides a more realistic view into project management.
  • The SPS theorem states that adding people to a project can bring down the delivery timelines but only by 25%. You cannot go lower than that.
  • While weighing the cost of project timeline against cost, there is no pattern or consensus of what smaller teams can achieve in a larger timeline v/s larger teams in a compressed timeline.


As the old African proverb claims "If you want to go quickly, go alone. If you want to go far, go together". As high performing teams, some need to do each more often than the other.

Full post here, 7 mins read.

Software development speed vs. quality: a tech shop conundrum

Achieving both speed and quality together is nearly impossible. Startups and smaller companies often lean towards speed, since they need to be disruptive to succeed.
Read more

Software development speed vs. quality: a tech shop conundrum

  • Achieving both speed and quality together is nearly impossible. A tech shop can operate in speed mode, or quality mode, or somewhere in the middle.
  • Developers, quality engineers, and quality assurance folks, who define their success in terms of quality, are the advocates for it.
  • Executives, product managers, sales & marketing people who are driven by deadlines that impact growth and revenues push for speed.
  • Startups and smaller companies often lean towards speed, since they need to be disruptive to succeed.
  • Within a single product release schedule, there can be a shift from quality mode early on in development to speed as there is more pressure to deliver.
  • Towards the end of the release cycle, you may need to sacrifice scope to hot deadlines while maintaining quality.

Full post here, 5 mins read

Why I love trunk-based development (or pushing straight to master)

Earlier & better feedback, collective code ownership, fewer issues with merge conflicts, preservation of whole commit history,
Read more

Why I love trunk-based development (or pushing straight to master)

  • Earlier and better feedback, while the code is being written, from your pair partner.
  • Collective code ownership by the team and strong team style, since it is no one’s sole responsibility or brainchild.
  • You can have actual continuous integration with small changes locally tested and then pushed out, without problem ignored till later.
  • Fewer issues with merge conflicts since your whole team is up to date on small changes every time.
  • High visibility of team members’ work so you can easily (and early) spot where a teammate needs help.
  • You can preserve the whole commit history, which is an advantage for future developers working on the same codebase.

Full post here, 15 mins read

Yes, you should estimate software projects

Good communication is more important than perfect estimation. Be ready to discuss tradeoffs and prioritization if complexity is affecting the timeline.
Read more

Yes, you should estimate software projects

  • It is obvious, but aim to deliver according to or ahead of your proposed timeline.
  • Good communication is more important than perfect estimation.
  • If you see a delay coming, communicate well ahead and work with the business to decide whether it is worth cutting features, risk pulling in people off other projects, or push out the date.
  • Be ready to discuss tradeoffs and prioritization if complexity is affecting the timeline.
  • Use missed estimates to build toolsets to deal with overlooked (or misunderstood) risks.
  • Offer time-based measurements of tech debt to save time later.

Full post here, 8 mins read

How to define and spend your tech debt budget

Define a technical debt budget - the maximum debt you can take on without affecting the business bottom line or your customers.
Read more

How to define and spend your tech debt budget

  • Define a technical debt budget - the maximum debt you can take on without affecting the business bottom line or your customers. If your tech debt balance sheet is in the red, take the time to pay back some of it; if it is in the green, take more risks to try and beat competitors.
  • Identify areas in the codebase where you will want to pay back your tech debt immediately - usually where debt gets in the way of the company’s current objectives. Examples are weak file ownerships and those with low cohesion and high coupling. Prioritize files that check all three boxes.
  • If it is not critical or is too complicated or does not need to be improved in the next few months, acknowledge it as debt and let it be.
  • Decide what you will work on this sprint, month or quarter and see what part of your tech debt overlaps with that roadmap.
  • From the list of files, thus, see which files are going to be needed for the roadmap ahead. Target these for refactoring.

Full post here, 6 mins read