Day 234 – Self Version 6.2

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 release. It is common to create a numbering system internally that is used to track what version is in production versus what major changes are in the pipeline. In the early days of the software industry, they started informing clients of releases or builds, and that remains today. Of course, now that we have a lot of SAAS software, this is less common, as we are expecting and ok with the continual release of new features. As I was pondering this shift in the software business, I started to make comparisons to myself.

What version am I right now? What versions are under development? After some thought about the various career decisions in my life and the various time periods in which I experienced major life moments, I decided that my current build is 6.2. This current “Guy” has some good, well-tested features, some of which are popular with 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 I have not quite resolved yet. I have a tendency to crash, and occasionally, my data retrieval takes a long time, resulting in some timeouts and system failures.

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 is 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 in QA. Usually, because the primary person responsible for QA is, at times, lazy and chooses to spend his weekend 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 features, and when pressed, management struggles with that question themselves.

So yes, the new and improved Guy will take a while to be ready for production. I guess I will have to deal with the same feature set and the workarounds that I am used to. Additionally, there is some regression going on, where for some reason unknown to anyone, old code branches are getting rolled back to and random times. This is not a desirable outcome, especially when the management was so pleased to get Version 6.2 out to market several months ago finally. To have code from version 5.8 to be suddenly pushed to production was a bit unsettling and really caused a drop in our customer sat scores.

I really need to get on top of this production pipeline issue of new releases, force uniformity and consistency on reporting, and perhaps even bring in some new team members if I am ever hoping to get a clean and stable Guy 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 well sequenced.

For now, I will keep telling management that I am 99% done.