Ways of working

Development is unavoidably a conflict between doing the work well and getting something delivered. We wish to do both - this page explains how we intend to reach it!

Note. The page remains a work-in-progress, as each customer project likely teaches us something new!

Figure 1. Customer interface

Customer ask

The customer has a need, and often an idea how that need could be fulfilled. We don’t, however, sell labor. We sell prototype development that can be used as a foundation for a product. Therefore, we don’t simply start executing what the customer has drawn up. Instead, there’s a refinement period (yellow) for each project. Anything can change during this phase: the scope, the tools, the architecture. If those do not exist, we create initial drafts.

There are two ways out: that both parties agree to go further (green section), or either or both reject the idea. No hard feelings - next time, perhaps?

This refinement should be relatively fast (in calendar time; perhaps some hours or days), also because it’s free of charge.

Cycle

We make prototypes in cycles, which is also the unit of billable work.

A cycle begins with preparation, which is when we make sure the tools intended to be used fit the purpose. This may involve some learning, and experimentation. The output is a readiness document that describes our level of confidence to do the actual work. It should include a risk evaluation (SWOT diagram). The customer should study this report carefully, since its role is to try to align expectations, and generally reduce risk of the implementation stage.

Note that no customer specific code has yet been created. We may have improved some open source libraries, and that is regarded unrelated to the customer’s order. After all, we haven’t billed anything, yet.

The customer approves the go-ahead by paying the bill for the first cycle. A cycle is normally a week, and the charge is 2500 eur.

Customer work commences and a deliverable is presented to the customer.

Note that both the “preparation” and “customer work” may have extensions. This accounts for calendar time. We do not take more features for an ongoing cycle, but also don’t promise a fixed “dead line” when things would be ready. The “readiness report” likely includes a time window that we see plausible for the delivery, so the customer has some meaningful indication about when to expect things to work.

Feedback

Feedback is not (yet) part of Figure 1, but it should. We’ll collect feedback during the collaboration, and wish to publish stats about our performance online, for ourselves and others to study. The main target of this approach is to learn how to make fast but high quality deliveries, repeatedly. By being our customer, you agree to be part of this experiment!

Next cycle

Some (customer) projects might be split to multiple cycles. We treat them as individual ones, though of course parts of the readiness report are likely to be carried over from the earlier one. But it’s more like 1..N micro-projects (each cycle separately billed), than one project with multiple “sprints” - that often have their scopes blurred, unfortunately. We do clean cut.

Maintenance?

Not a fan. In his book Clean craftmanship: disciplines, standards, and ethics (Amazon; Nov 2021; 416 pages), Robert Martin (“uncle Bob”) writes how he prefers maintenance (of code) to be an ongoing effort alongside any changes to such code. This resonates well with the author’s experience, too. In practise, a need for improving quality of an existing code base would be mentioned in the readiness report, before a cycle is underway, and can be jointly discussed with the customer and the doer.

Acceptance

Figure 1 has no part for acceptance. The wishful thinking is that the acceptance criteria has been nailed already in the refinement, to a degree that there are no large ambiguities (gaps of expectation) between the doer and the customer.

One metric we can potentially start tracking is how many deliveries are needed per cycle, and how long it takes for the customer to be pleased.

The work is already paid in advance. The customer cannot hold money as ransom, to get changes done to what seems like a valid deliverable by the doer. We’ll need to try this in practise to see how it flies!

Walking away!

Things happen. If the customer wants to walk away during the cycle (which means they’ve paid the invoice), we can negotiate a refund of max. 50% based on how much of the customer specific work has been done. If a deliverable is already delivered, there is naturally no refund.

Also the doer can walk away. Sometimes things don’t work out and one needs to be able to cancel. The whole process described in Figure 1 - especially with the readiness report - tries to minimize this possibility, but it is still larger than 0.

In the case the doer cannot produce a deliverable as expected, they are to refund 50% of the invoice.

Next - see the Portfolios

You should now have an idea of:

Let’s have a look at the Portfolio of completed projects; if you were to become a customer, our sincere wish is to be able to list also your project on that page. :)