This is part 1 of a 3-part series on key questions to ask before taking on a development assignment as a consultant.

If you're a software development consultant, you know how vital it is to quickly understand whether a potential assignment is technically sound, stimulating, and sustainable. The technical foundation of a project often determines whether you'll spend your time building innovative solutions or fighting fires.

In this first part, we'll focus on evaluating the codebase and technical practices – the foundation that will shape your daily work experience.

1. What's the state of the current codebase – modern, legacy, or somewhere in between?

This is perhaps the most critical question. The codebase quality directly impacts your productivity, learning opportunities, and daily satisfaction.

Follow-up questions:

• When was the codebase initiated, and how often has it undergone major refactoring?

  • A 10-year-old codebase with regular refactoring can be healthier than a 2-year-old mess
  • Look for evidence of continuous improvement vs. stagnation

• What architecture is in place (monolith, microservices, serverless, etc.)?

  • Each has its merits, but what matters is whether it fits the problem domain
  • Beware of trend-driven architecture without clear business justification

• How comprehensive is the automated test coverage?

  • Low coverage often means you'll spend more time debugging than developing
  • Ask for specific numbers and types of tests (unit, integration, e2e)

• Is the code modular and reusable, or does it resemble spaghetti?

  • Check if SOLID principles are followed
  • Look for clear separation of concerns

• How often do you inherit undocumented, unfamiliar code?

  • This reveals both code quality and team practices
  • Frequent occurrences suggest poor knowledge management

• What's the team's own perception of the code – proud or frustrated?

  • Team morale around the codebase is telling
  • Frustration often leads to shortcuts that compound problems

2. How do you handle technical debt?

Every codebase has technical debt. What matters is whether it's acknowledged, tracked, and systematically addressed.

Follow-up questions:

• Is there a clear backlog or board tracking technical debt?

  • Visibility is the first step to resolution
  • Look for categorization by impact and effort

• Is debt prioritized by both developers and product owners?

  • Technical debt needs business buy-in to get addressed
  • Pure developer-driven initiatives often fail

• Has technical debt ever blocked the release of new features?

  • This shows if debt is allowed to reach critical levels
  • Regular blockers indicate poor debt management

• Do you allocate specific time for addressing it (e.g., every sprint)?

  • Systematic allocation (like 20% of sprint capacity) works best
  • Ad-hoc approaches usually mean debt never gets addressed

• How does leadership view investment in "invisible work"?

  • Leadership understanding is crucial for sustainable development
  • Look for appreciation of long-term thinking

• Can developers suggest improvements that actually get implemented?

  • This shows if the team has agency over code quality
  • Empowered teams maintain better codebases

3. Do you have an established code review process?

Code reviews are where quality standards are enforced and knowledge is shared. A healthy review process is essential for maintaining code quality.

Follow-up questions:

• Do you use pull requests, pair programming, mob programming, or something else?

  • Different approaches suit different teams
  • What matters is consistency and effectiveness

• How fast do PRs typically get reviewed?

  • Long review times kill momentum
  • Same-day reviews should be the norm

• What's the focus of code reviews – style, tests, logic, security?

  • Reviews should cover all aspects, not just formatting
  • Automated tools should handle style checks

• Are there clear guidelines for what counts as "acceptable code"?

  • Written standards prevent subjective debates
  • Look for living documentation that evolves

• Is feedback respectful, educational, and consistent?

  • Review culture impacts team dynamics
  • Harsh reviews discourage contribution

• Is review responsibility shared across the team or siloed?

  • Everyone should be able to review
  • Siloed reviews create bottlenecks and knowledge gaps

4. What development methodology do you follow – Agile, Scrum, Kanban, or something else?

Methodology matters less than how it's implemented. Look for pragmatic adaptation rather than dogmatic adherence.

Follow-up questions:

• What does a typical sprint or iteration look like?

  • Look for sustainable pace and realistic planning
  • Constant crunch indicates poor planning

• Is the methodology practiced sincerely or only in theory?

  • "Agile theater" is worse than no methodology
  • Check if ceremonies add value or just eat time

• How often do you run retrospectives – and do they lead to real change?

  • Retrospectives without action items are pointless
  • Look for evidence of continuous improvement

• Are requirements and user stories clear when work begins?

  • Unclear requirements waste enormous time
  • Good teams refine stories before committing

• How are blockers and unforeseen issues handled during sprints?

  • Flexibility in handling surprises is crucial
  • Rigid adherence to plans despite reality is a red flag

• Does the team have influence over the way it works?

  • Teams should own their process
  • Top-down methodology rarely succeeds

Key Takeaways

When evaluating the technical foundation of a potential assignment, you're looking for:

1. A codebase that's actively maintained, not just patched
2. Technical debt that's managed, not ignored
3. Code review processes that build quality, not just check boxes
4. Methodologies that serve the team, not constrain it

Remember: Perfect conditions rarely exist. What you're looking for is self-awareness about problems and active efforts to improve. A team that acknowledges its challenges and works to address them is often better than one that claims everything is perfect.

In the next post, we'll explore development practices and team dynamics – how work actually gets done and who you'll be working with.