Guy Reams (00:01.198)
This is day 234, self version 6 .2.
So this morning I was thinking about version control. You know what software developers do when they release a branch of fully reviewed code that is ready for a major. It is common to create a numbering system internally that is used to track what version is in production versus what major changes that are still in pipeline. In the early days of the software industry, they started informing clients of releases or builds, and that kind of remains the practice today.
Of course, now that we have a lot of SaaS software, this is less common as we're expecting and okay with continuous release of new features. I was pondering the shift in mentality from versioning to constant release today. And then I started making comparisons myself. What version am I right now? What versions are currently under development? After some thought about
various career decisions I've made in my life and the various time period in which I experienced major life moments, I decided that my current build is version 6 .2. The current guy has some good, well -tested features, some of which are popular with the users, but there are some definite challenges still going on. The user interface is in desperate need of a makeover, and there are some bugs that have not quite resolved yet.
I have a tendency to crash and occasionally my data retrieval takes a really long time, resulting in some timeouts and
Guy Reams (01:45.134)
The pipeline process needs some work as well. Management keeps changing aspects of version 6 .3. They cannot make up their minds about what they want. So as a consequence, the new features promised in upcoming versions keep getting sidelined by urgent priorities. Scope creep is frequent and at times uncontrollable. The dev team finds themselves working on unscheduled priorities and keeping track of what is currently being worked on for the next release.
was challenging. The much anticipated release of Guy 6 .3 is once again getting pushed back because most, if not all, of the new features are failing QA. Usually because the primary person responsible for QA at times is lazy and chooses to spend his weekends doing more leisurely activities. Above all, the people in charge of product testing do not rightly understand what the intended purpose was of the new feature.
And when pressed, management struggles with that question themselves. So yes, the new and improved guy will take time, take a while to be ready for production, sorry to say. I guess I'll have to deal with the same feature set in the work arounds that I'm used to. Additionally, there is some regression going on where for some reason, unknown to anyone, old code branches get rolled back to roll back to major production at random times. This is not a desirable outcome.
especially when the management was so pleased to get version 6 .2 finally out to market several months ago. To have code from 5 .8 suddenly be pushed to production is a bit unsettling and really caused a drop in our customer SAT score. I really need to get on top of this production pipeline of new releases of Guy, forced uniformity, and consistency on reporting, and perhaps even bring in some new team members.
If I'm ever hoping to get a clean and stable 6 .3 release to market, I need to set reasonable goals, identify and measure key results, and establish a sprint cycle where work effort is more accurately predicted and change control is correctly sequenced. So I hope you have a fun time working on your next release. I know I have a lot of work ahead of me. Thank you.