Life Tracking Dashboard - Retrospective
Friday 04 September, 2020
Tags: development retrospective
Having just completed the pre-release version of my first dive into Python desktop app development with the tkinter library, there are a lot of things that I have to reflect on that I'd like to share, both for my future self and anyone reading. Having a retrospective after completing a project release, regardless of the version or if it's an alpha/pre-release, is one of the most important parts of development to ensure that many of the same mistakes are minimised for future endeavours and anything that worked particularly well is carried forward to the next project. It's also a great opportunity to lay everything out on the table and ensure a clean slate afterward. Honesty and self-reflection is a key component of this.
So I wanted to do a short retrospective on seven learnings that I've had while undertaking this project and will take forward with future projects and extensions to this existing one:
- Keep a the scope of the project limited where possible.
I wasn't clear enough to myself on what I wanted to achieve for each section of the application because I was treating this as a learning experience as was just trying to keep things moving forward and avoid sticking points that could cause motivation loss. Because of that, I feel I sacrificed code quality where I shouldn't have, just so I could get the application to a finished state. Not a wise move when structure and readability is just as key when learning.
- Deconstruct and separate parts of the application that don't belong together.
I thought it would be a good idea to have everything inside one single desktop application but I don't think that was a wise decision. It was far too easy to make small additions out of scope and caused motivation to dwindle towards the end of the project as progress seemed slower - one large goal versus four small ones. I would rather have had four smaller applications that did a single thing very well.
- Encourage code re-use at all costs
There were many times during development where I needed to handle JSON file input and output. The first time writing the file loader, it seemed fine to keep the functionality within that section's class/directory as I wasn't aware of how I would handle the input for any other data and configurations. On reflection, I should have represented creating, editing and deleting files as separate classes that could be extended for my needs for each part of the application. This would also enhance readability and enforce a clear understanding of what is going on within the code.
- Put as much effort into the last elements of the application as the first.
A difficult one as it depends entirely on what project you've chosen. My application choice was okay but it was purely a learning experience rather than anything that was inherently riveting. What helped me push through in the end was the knowledge that this experience was helping me improve as an overall developer. In some way, I was "learning to learn" all over again, if that makes sense. Going from having zero knowledge of any sort of desktop development for Linux to having a pre-release version of something that generally works okay is an achievement in itself. I just wish that that last 10% was as good as the first 90%.
- Take short breaks when the road to continue on is not fully clear.
Whenever there was a point during development where I couldn't cleary see what the next step was, I would take a break and come back to the problem with a refreshed mind, whether that was doing exercise, cleaning or another hobby altogether. During this, albeit small project, it had a 100% success rate and every time I came back to the code, I was able to get unstuck and continue moving forward.
- Document and commit often.
On reflection, documenting as you go rather than in larger chunks really helps inform your understanding of your own codebase. It's much easier to write clear and concise documentation when the code you've written is still at the forefront of your mind. I found it much harder to write comments at the end of the day before a final commit where you're trying to remember all the intricacies of your code. Committing to your Git repository (or other provider) also means those commit messages can be clearer and end up being far less generic.
- Consider Test Driven Development before beginning the project to avoid bloat.
Test Driven Development had crossed my mind upon thinking about this project but I don't think I could let that get in the way of actually getting development started. It would be an entirely new workflow that could double development time but I couldn't justify it for this small project, even though it's something that I want to learn. Would it have been worth it to reduce all of the bloat in my code - maybe. However, I think it could be justified far more for something that I want other people to use in the open source world and get value out of.
I hope these points helped you as much as I did and can take any parts forward to your future projects. Onto the next project!