Solid
Engineering
Solutions
Since 2016 we worked on a multitude of compiler and tools projects with companies from different industries. The invariant observation is that projects are all very different. There is no way to know in advance what the dominating complexity will be next time. Our answer to it is an approach that we call Sprints and Breaks.

Nice to e-meet you!

When a client reaches out, we usually ask to arrange a 30 to 60 minutes intro call. In order to be effective, a technically versed person from the client side must attend the meeting. In part 1 we introduce each other and our roles and responsibilities. The goal of part 2 is to answer a number of questions essential for planning the first sprint. The below check-lists may give some inspirition. The more of these questions we can answer the better we can plan the first sprint.
Check-list Bugs
  • Do we know what exactly the problem is?
  • Can we reproduce the problem in a deterministic way?
  • Are there any workarounds that we know about?
  • Can we identify the part of the code base that causes the problem?
  • Can we break down the problem and define a first step?
  • Can we make an effort estimation for the first step?
  • Or otherwise: How long do we think it takes to understand the problem good enough to estimate the first step?
Check-list Features
  • Do we know what exactly the goal is?
  • Can we write a test that covers the feature?
  • Is there a way to emulate the functionality without code modifications?
  • Can we identify the parts of the code base that need to be extended?
  • Can we break down the feature and define a first step?
  • Can we make an effort estimation for the first step?
  • Or otherwise: How long do we think it takes to understand the context good enough to estimate the first step?

Sprints and Breaks

Sprint One

Break One

Repeat