Changing libraries causes more pain than necessary.
If only it was like the old days. When I was younger library issues were overdue books, or that someone had the book you wanted. Were it so simple in software development.
These days you can lose days to unexpected library changes in your app development process. And, you never know when it will hit you. That is the real kicker.
Plan for the unexpected
You put all of the pieces together, and create your application. You refine it over time, and smooth the rough edges so it shines. You might even go further and ease the build process with some extra tooling of your own to combine steps.
Then you notice a new version of your main library drops. Now you can pause and wait for people to find issues, and have them resolved. You think “I’ll do that later after I finish this current component.”
As you finish the component you go through your own drop process. You clean out precompiled versions, and build again. All is fine.
Then you think, ok, let’s check the basics again and really confirm it all works. You remove the libraries, and reinstall them. You find this time that this can be a gamble. Libraries were updated since you last installed them.
Your build breaks. You find errors can be cryptic and lead you down many paths. Now you find things you never knew you might need to know. This time around I found some things, that I have now added to permanent configuration details. Sadly, also found myself editing library files, as suggested by one person. This sadly didn’t work.
You also find yourself visiting forums and other discussion platforms looking for information. This is useful for general knowledge. I add these to my list of information sources. This list means I can start here if a general search doesn’t reveal a solution. It is also where I can post questions, and hopefully receive answers.
Tradeoffs are a key issue
I find the tradeoff the worst aspect of this process. You plan on doing other work, and then you find yourself spending time doing things you didn’t plan on doing. Yes, you learn new things, but it’s always at an inopportune time. Grrr.
The learning you gain as you fix library issues should be noted in a file in your repository. This lets you review the issue later, and also means you can store solutions for later use too. This is also a source of knowledge for any other team members too.
Oh. The duck replied! I just realised by writing this out what I forgot to try: rolling back to a previous version, and then reinstalling those libraries. Or, at least looking at the previous library list to see what changed. This is why pausing and thinking, and writing helps.
This post is part of a project pulling together my materials and ideas about Teaching Team Collaboration: the Human-Side of Software Development for software development to students.
If you’d like to be notified of future posts, then please sign up for more using the adjacent form. When you sign up, then I’ll send you a free copy of the collaboration rules as a PDF from the book. You can also follow me on LinkedIn
The ideas above are from my book 101+ Ideas to Improve Team Collaboration, which covers all of these little things that students can do to improve their collaboration. Also available via Kindle.