Month: May 2021

I had a bit of a rant on a Twitter thread yesterday about this post.

The Transition to Trunk-Based Development

I’m going to repeat that rant here, then expand on it below.

The Rant

This kind-of gets on my tits.

It reads like, “we were doing everything badly and blamed it on GitFlow. Then we switched to trunk-based development and started to do everything properly. Trunk-based dev rules.”

You went from:

• No automation to automated delivery.
• Manual testing to automated testing.
• Huge, long-lived feature branches to deploying smaller units of work.

None of this is about GitFlow vs trunk-based. It’s all about doing modern development properly.

This is such a lazy argument. I would be interested to see you fix all that stuff in GitFlow, then move to trunk-based and see what the difference/improvement was. That is a better comparison.

Now I realise sometimes you have to have a big step-change project to get people to do something different, and maybe trunk-based development was that trigger for your company, and if so, that’s good for you, but as I said, this is not GitFlow vs. trunk-based.

So once again. I’m not saying one method is better than the other. I’m just saying be honest about the major factors that contributed to your increased velocity.

None of the factors listed were specific to these styles of development. They are basic Agile and DevOps things.

Expanding

I see this sort of thing all the time.

I remember being in a session about Exadata when it was first released, and being told about 1000x performance when one project was moved from old conventional kit to Exadata. Someone much brighter than me asked the question about what code changes were implemented as part of the migration. It turned out a bunch of row-by-row (slow-by-slow) procedural data loads were ripped out and replaced by parallel DML operations using external tables. So as well as moving from old crappy kit to Exadata, they switched from crappy procedural code to set-based data loads. Relatively speaking, relational databases tend to be pretty crap at procedural work, and amazing at set-based processing. There was of course no comparison of how well the new data load approach worked on the old kit, so who knows where the biggest performance gains were made?

This isn’t about me slagging off trunk-based development, or Exadata. It’s about people making flawed comparisons. Imagine what you would say if I said advanced driving courses are amazing and here’s the proof. I did a lap of the track in a Ford Fiesta and it took 5 minutes. I then did an advanced driving course and was able to improve my time to 3 minutes in a Ferrari. I credit the advanced driving course for all the performance improvements! It’s clearly a terrible comparison and a misleading conclusion.

Wrapping It Up

Going back to the post that initiated this rant, I don’t think they were purposely trying to be misleading. Please don’t send any hate, but I feel like the real conclusion was not about GitFlow verses trunk-based development. It was about two things.

• Manual process verses automation.
• A cultural shift to encourage large, long-lived enhancements to be broken down into smaller user stories and story points, and being willing to ship small sprints of work to production, rather than waiting for the entire enhancement to be complete before deploying.

The first point is very much what “The Principle of Flow” in Devops focusses on. The second point is common to discussions about DevOps and Agile in general. This is what resulted in the increased velocity IMHO.

So when you are reading stuff, try to engage your brain and read between the lines.

Cheers

Tim…

I was on a call a few weeks ago and the subject of technical content came up. As someone who produces a certain type of content, I had some thoughts related to cloud services. Specifically how cloud services make my style of content less meaningful these days.

A large part of my content could be described as “traditional” DBA content. As we move more systems to the cloud, and start to use increasingly automated database services, the “traditional” DBA is becoming less relevant, and therefore a certain proportion of my content is becoming less relevant with it. We are due to get an on-prem release of Oracle database 21c soon, and I’ll certainly be doing some installation articles for that, but how many more releases after that will need installation articles? How many more releases will require traditional DBA content? At some point we’ll be using cloud-based data services, so people like me won’t be installing or patching stuff anymore. What does that mean for my content?

Of course, if I’m still working I will still be producing content. As followers of the blog know, writing stuff is part of my learning process, so every time I’m learning something new, you are likely to see some articles appear on that subject. The issue is, if the traditional DBA content stops being necessary, or I’m just not doing DBA work anymore, what sort of content will I be producing?

The short answer is I don’t really know. I don’t think any DBA knows what they will be doing in five years. I suspect I will be some form of developer, but I don’t really know what type of developer. I would imagine it would be data-related, but who knows…

If this post raises any questions in your mind, I’m afraid I’m not the person to answer them. It’s just a really odd time…

Cheers

Tim…