Devlog #2: Bad news...

Welcome back to the latest installment of my bi-weekly devlog, where I share updates on building my Expenses Tracker. This not only keeps my network informed but also helps me stay accountable and adds structure to solo-preneurship.

If you missed it, check out Devlog #1: Design Deep Dive and styling Proof-of-Concept, where I picked a design system and component library for this project. Thank you all for your support and feedback — it’s been a huge motivator!

Special thanks to ?? Riccardo Bevilacqua for his feedback and design critique. Thanks to him I was able to make some small, but meaningful UX and visual design tweaks and Riccardo also helped me improve the accessibility of the app by pointing out areas with low contrast ratio. Luckily these shortcomings have been addressed, but it's always good to stay vigilant ??

So what's the bad news? Three open pull requests (PR), zero merged in the last two weeks and nothing went "to production". This is a feeling many developers know all too well and here is what you can do about it.

Too many tasks in progress, but nothing is finished. Now what?

Having too many tasks in progress without finishing them is a common pitfall for developers. To get back on track, I start by cleaning up my Git workflow and make sure my commits get neatly sorted. That's why I'm a squash-and-rebase kinda guy. Here's what my GIT history looks like now I did some cleaning up:

Once I can see the steps I took to get my code base in the current state, I separate out large features into their own branches. That gives me the following work that's still in progress:

1. Re-design of the app based on the design system I mentioned in my last devlog
2. While implementing Preline UI, I got sidetracked by building the theme toggle because...well, let's be honest: who doesn't love switching their app to dark mode ??
3. While working on the redesign I realized that the upload page introduced more complexity than I had anticipated. And it uses a dependency I've never worked with (Dropzone.js), which would require me to dig a little deeper into the implementation of the drag-and-drop component in Preline UI before delivering a proper solution.

Now I have my branches, each of these can be reviewed and merged separately.

Next step: sprint goals...and the Elephant Carpaccio.

What is the Elephant Carpaccio?

This concept, introduced to me by my friend Albert Starreveld , emphasizes breaking down a chunks of work into thin slices that can be built, reviewed and deployed incrementally ensuring that value is being delivered without endangering project timelines or the quality of the product.

Dr. Alistair Cockburn, the inventor of this method, describes the exercise as follows:

The learning in this workshop is how to slice that little problem into 15-20 growth stages, which reduce risk, deliver value, produce income, provide market learning points, and allow pivoting the business all with the smallest energy.

He goes on to say...

The activity teaches how to slice business initiatives, whether marketing or product, into thin enough pieces to fit into any size of timebox or sprint, and why that is beneficial.

— Elephant Carpaccio, Dr. Alistair Cockburn

How can this help me:

• Smaller PRs are easier to review and merge.
• Reduces risk of delays from sidetracks or unforeseen complexities.

What does that mean for my workflow specifically? First and foremost PR's have to become smaller. It's better than last time, but I'm still struggling making these changes (carpaccio) byte sized:

I think this problem calls for an additional tool: the sprint goal!

Sprint goals are typically used on software projects and by scrum teams so everyone is clear on the goal and can have an open conversation about whether or not they can commit to this goal, or if there are any risks or impediments that could prevent them from reaching that goal.

As a solo developer I thought I wouldn't need to explicitly write down my goals, but because this is the second time I'm getting sidetracked on my journey by some shiny object along the way, I think this could be a nice tool to make sure I stay focused.

So in hindsight my previous goal was maybe a bit too vague:

? "Redesign the app"

The sprint goal should have looked something like this:

? "Redesign the overview page"

? "Redesign the upload page"

? "Redesign the expenses page"

? "Implement dark theme toggle"

If I had been more critical in the planning phase, I would have focused on delivering the redesign and wouldn't have gotten sidetracked with the theme toggle or unexpectedly getting confronted with a library that I'm unfamiliar with ??

I think I should have immediately pulled the breaks on the theme toggle and the upload component once I saw they took longer than half a day to complete.

Definition of Done

As I'm taking steps to professionalize my project, I'm also forced to go back to basics. That's why I've spent some time thinking about my Definition of Done:

The Definition of Done includes all of the characteristics and standards an Increment needs to meet in order to be released.

— Scrum.org

Basically, a Definition of Done (DoD) ensures that every feature or fix meets a consistent standard before it’s considered complete and ready for production. For the current state of my app, this project and infrastructure I use the following checklist as my DoD:

• Linting passes
• Unit tests pass
• Code is reviewed
• PR is merged
• The app is deployed

Luckily many of these checks can be automated thanks to GitHub Actions and will prevent from defects making it onto the server:

The goal of having a DoD is to make sure each incremental change is robust and well tested, which means I want to make sure the upload page and theme toggle get the focus and attention they deserve instead of rushing them over the finish line. I think it's crucial to set a bar and try to clear it with every single change. I've summarized this mindset in the following quote:

Developing software is about making tradeoffs, not cutting corners.

— Florestan Korp

The upload component is still a work-in-progress. It doesn’t meet the quality bar, align with the app’s functional requirements, or match its styling. As a result, it’s not ready for production.

Unfortunately, the same goes for the other two increments: the redesign and the dark/light theme toggle. None of them are DONE, which has delayed feature delivery and made the project timeline less predictable ??

To get back on track, I’ve set a clear goal for the next sprint:

? "Implement dark theme toggle"

And this time, I’m sticking to it! ??

Have you faced similar challenges when juggling multiple tasks in your projects? Share your strategies or lessons learned — I’d love to hear from you! See you in the next devlog!