Published on , in #design-process
The start of a project, I've noticed, often determines the pace for the whole project. I discovered that what works well is to start with a proof of concept that is embarrassingly simple. "Embarrassingly simple" clarifies what to expect: a half-baked barely-working solution. "Embarrassingly simple" is also kind of funny when said out loud, and it sets a good mood within the team. To me, a recovering perfectionist, "embarrassingly simple" also crystalizes what to build and what to exclude.
Here's an example: We needed to integrate system A with system B by periodically calling the APIs. To make the proof of concept embarrassingly simple, we excluded tests, devops and monitoring, we ignored edge cases and unhappy paths, and we were pretty relaxed about code quality.
We ended up with a manually-triggered script that reached out to system A, extracted one field from one object, and stored the field in system B. We could have run API calls manually, but a bit of automation is a nice touch for demos. We also aimed for high impact, so we asked which object and which field have high priority.
Cutting corners where possible, the concept was delivered quickly. Clients like that, it turns out. We also learned a ton about the systems:
- we discovered the need for a sandbox environment,
- we figured out API access and ironed out surprising API errors,
- we learned the foundations of the system's data models,
- we learned how to map the models for one specific use case,
- we discovered gaps in requirements that we didn't know before.
We reached the first deliverable, we set the pace, and the client is satisfied. Now, it's about keeping this up through the middle to the end of the project.
- ← Previous post: Everyday decision making & architectural vision
- → Next post: Preparing a lemon pie: visualization
This blog is written by Marcel Krcah, an independent consultant for product-oriented software engineering. If you like what you read, sign up for my newsletter