Weekly review cw 13
This week's first experience with mood tracking, a corrupted database, and the impact of very late assumption validation in projects … was a hot week.
Mood Tracking – First Experiences
After preparing a mood board in my bullet journal last week, I made notes about my mood for the first time and answered the eight daily questions. I use the time in the evening to answer the questions at the end of the day. This allows me to reflect on the days much more consciously.
The question "Are there any patterns that stand out?" is helpful and valuable – it helps me track down one or two unconscious habits. Gratitude is still tricky for me. It's not that I'm not grateful – I'm usually thankful for the same things because they're so wonderful. For example, my daughter tells me how she feels about me every day. That's an excellent source of energy. I write it down daily before I think about it for too long and enjoy the good feeling. And that's what the exercise is all about.
Convenience is not a good advisor
At the beginning of the week, we had to pull the emergency brake in the Sociabli project. A serious error caused by a software update or a syntax error in a workflow corrupted the database—the exact cause could not be determined. Only parts could be restored after hours of trying to save the content.
Why didn't we restore a backup? That's where convenience comes in. During rapid prototyping, we used an internal SQLite database within a Docker container, which we couldn't easily access. Therefore, we didn't bother to back it up or create data exports. This was a fatal error. Not a really new learning. We didn't expect such a problem for a small side-hustle project.
The solution is to leap forward: We already had an important feature in the pipeline that provides a new authentication concept. We are currently working intensively on it to have it completed early next week. We'll send a circular email to our beta testers praising the new feature and asking for their understanding that they'll need to take action to ensure smooth operations in the future.
To put a bit of humor on the topic, this well-known meme comes to mind:
Why Validating Assumptions Is So Important
This week, my client project held its monthly meeting. The focus was on presenting the wireframes for an iOS application. This time, the future users were present instead of just the client. Thanks to this, we could falsify a fundamental assumption for data modeling. At first, I was shocked because the effects extend to all aspects of the software and aren't limited to the iOS application.
Afterward, the development team addressed why we let the assumption hang in the air without being tested and didn't question it sooner. In the end, we could only conclude that the client had formulated the facts so convincingly that we had accepted them as a given – very naive of us and an important lesson to learn from, always looking critically at the requirements and assumptions.
The whole thing is tricky because we're locked into a work contract that contradicts our agile working method. The actual task is straightforward:
- Adapt the data model.
- Revise and align the workflows in the wireframes.
- Present the corrections to the team and have them approved.
- Implementation and feedback.
