The Complexity of Branches

Branching code is hard.  Well, branching isn’t hard. Just right click in some GUI or or type “git branch” and off you go. The actual branching of code is pretty simple and painless. In some sense, branching might be too simple in today’s tools as developers are almost encouraged to branch in a VCS and “test something” quickly without a lot of thought.

Even merging has become easier, with tools to visual code changes, and automatic merging in many cases. Despite the hassles of merging, it often isn’t too difficult, which can mask the complexity of branching.

However branching can easily devolve into a nightmare of multiple versions of code, with various developers unsure of the impact of their changes on a merged code base. This is especially true in a large code base where many developers each have their own branch where they work. With pressure from multiple individuals to patch bugs, add features, and streamline performance, I’ve met developers that end up building changes in three or four branches at the same time.

Merging all the work together, into the correct main branch, becomes tricky.  We’re all human, and I’ve seen developers merge a change into the wrong branch. Tools try to limit this, but it still happens. The more branches that are in use, the more time that ends up getting spent on the administrative action of reconciling code differences rather than building new code (or fixing old code).

Understanding our code is hard enough, without adding the additional complexity of versioning multiple files and objects. My philosophy has always been to limit branches as much as possible, usually only allowing one, or at most, two, per team. We have also endeavored to merge back changes every few days, just to limit the amount of time spent performing merge reconciliations. I’d rather have developers have the pain of merging daily on a shared branch than dealing with branch merges less frequently (usually more complex merges).

We’ll always have mistakes made, but using automated testing and continuous integration builds on all branches can help limit the number of obvious mistakes that break code. This won’t prevent bugs, but our tests can help reduce the number of bugs, especially regression bugs, over time. At least, they can if we use testing on all branches, all the time.

Steve Jones

The Voice of the DBA Podcast

Listen to the MP3 Audio ( 3.2MB) podcast or subscribe to the feed at iTunes and LibSyn.

Here’s a Reason to Document

A search engine for code

This editorial was originally published on Feb 17, 2006. Steve is traveling in the UK this week and we are re-printing some old pieces.

A new search engine, Krugle, set to launch next month, is supposed to focus on code. Mostly open source code, but also places like, which has scripts and other types of code available. Wired has a good article on the idea behind this search.

It’s an interesting idea, though given the types of comments and the wide range of ways that things are described, I wonder if it will work. I know that we get lots of posts in the forums that I easily find answers for using Google when other don’t. I suspect that I am just searching on better terms than others. Course that doesn’t always work for my own questions, so perhaps it’s a second set of eyes that really help.

However this also depends on the actual coders spending some time to properly describe their system. That’s always a difficult task. But even assuming that they will describe their code well, how will you know if it will “plug in” easily to your system? I’ve seen lots of code that wouldn’t easily integrate with something I was writing.

And if I checked out 3 or 4 of these incompatible, or not easily integrated systems, from a search engine, I’d be tempted to just write my own. Actually I think lots of developers write their own code, or build on a base and then do everything themselves because it takes so long to integrate disparate code at times.

Still it’s a great idea and I hope it works.

Update Jul 13, 2011: Has anyone used, or is using, Krugle?


There is no book for modern etiquette

The world has changed a lot in my lifetime in the way we communicate with others. I am sure that when the telephone was first invented, or live news broadcasts were available, people felt a similar shift, but the way that technology has allowed us to keep in touch with each other, instantaneously, almost anywhere on the globe, is amazing. I grew up with one phone in the house, with an extra long cord, and now have a Smartphone that gives me not only voice communication, but incredible amounts of data on a regular basis. I find myself communicating with text (Twitter), voice (phone), and even with myself (Evernote) almost every day.

The shifts have also occurred very rapidly, which has brought with it challenges, and occasionally problems. This Intel survey highlights a few issues, and this PSA shows one that many of us are probably affected by at different times.

In technology we have to deal with interruptions, and sometimes urgent situations that require immediate attention. We have to respond like a doctor on call for emergency room situations, but the reality is that most of our “alerts” aren’t that critical and no one, or no business, will die if we are a few minutes late. There are exceptions but for in most cases these events aren’t extremely time sensitive.

As you build monitoring and alerting systems, include a little etiquette . Don’t unnecessarily page people, or alert them for situations that don’t need immediate attention. Bring visibility to problems, but don’t overwhelm someone with a large amount of data, and please, don’t alert people that things are working correctly. At this point in computing, automated systems ought to triage out most of the minor issues without involving humans.

Our world has changed rapidly, with the speed and accessibility of communications growing quicker than our ability to deal with it. In some sense, I think that the deluge of data that we now have will bring new problems to our world, especially as more and more businesses look to analyze data in real time. We will face challenges that would have seemed like science fiction a decade ago.

Steve Jones

The Voice of the DBA Podcasts

Greed Is Good (for IT)

I think that the lottery mentality that so many executives of companies have these days is bad for business. The idea that someone can be promoted from a director or vice president to CEO and then earn enough money in bonuses, benefits and stock options to retire is silly. People that lead a company should make more, but their jobs should be no more secure than anyone else’s in the company, and they shouldn’t be paid multiples more than their direct reports. If they lose their jobs, they should have to get a new one, just like the rest of us.

Last week LInkedIn had an initial public offering (IPO), which was very successful. The company raised money, which hopefully will help it grow, and many stockholders and investors became rich. That might not be important to data professionals, but the news may have caught the attention of your management, and that could be good for IT.

The CEO of wrote a blog about the event, and he brought up an interesting point. Executives and management in many companies probably are thinking that social networking, or just online engagement with customers,  has an impact on their business. How do they get better engagement? Better Information Technology.

While I’m not sure this will be pervasive throughout all companies and industries, there will be executives that want to build new systems and move faster. They will want new applications, which means new databases, and for some of us, this will be the chance to get a better job, build a strategic application, or just get a little more budget for our group.

It’s also potentially an opportunity for you to be pro-active. Maybe you can suggest a few new ideas for projects or enhancements that you might want to tackle which would improve customer engagement. Maybe you’ll even get the chance to have some fun at work.

Steve Jones

The Voice of the DBA Podcasts

From Great Idea to End Result

Great ideas come from anywhere

What’s the time for you IT department to get from great idea to a resulting application? This is a very good piece from CIO magazinethat finds many IT departments are seen as too slow. However there are a number of companies that are trying to innovate and find ways to increase the speed at which IT departments can deploy an application and respond to a business need.

One great quote in there is “velocity is more important than perfection”,  which is a tenet that I have found to be very true over the years. It’s not that you throw junk out that isn’t well built or tested, but that you don’t try to meet every possible requirement or handle every little issue. The system has to be secure, handle errors, and meet the basic requirements, but it’s more important to get something done and in production than to have it perform and scale perfectly.

Is that heresy to the developers and DBAs out there? Perhaps, but I think this methodology has to go hand in hand with another mantra I heard fromJason Fried: do more of what works and less of what doesn’t. In this case if a system shows promise and starts to get heavy use, it receives more resources and perhaps gets refactoring in real time, even as it gets enhanced with new ideas.

“You want IT to be in constant test-and-learn mode”, another quote showing that IT needs to be working closely with the business to try ideas, learn from them, and move forward. The Agile style of development applies, and in some sense I think this is the future for the strategic IT department of the future.

For the data professional this means that you must learn to model quickly, and with an eye towards a flexible design that might need to change regularly. We need to understand the businesses we work in better so that we can anticipate how requirements might change.

Management has to buy into the idea that applications will not be perfect, they won’t be polished, and most importantly, they are essentially prototypes that either need to have addition resources spent on enhancements or they should be abandoned quickly. However I think this is a great way to develop internal applications that can provide a nice ROI, and be a more enjoyable way for developers to work.

Steve Jones

The Voice of the DBA Podcasts

Which Bugs Do You Find?

Software bugs are usually not this easy to find.

I was listening to a StackOverflow podcast awhile back and there was a discussion on  programming, debugging, and how software has changed. One of the interesting things was that we have solved many programming issues and are building more complex software, which has resulted in the types of bugs that we often find today are different than the bugs many of us older folks used to deal with in programming.

When I was writing code as a youth, we often had bugs that were process bugs. We were trying to get software to do X, and struggling with actually how to tell the computer that X should occur. I heard a few people on the podcast mention that they typically didn’t have those bugs too often, at least not once the software was at a point where they would release it for general use. Instead they talked about finding bugs that were issues because the flow of the software wasn’t what the user expected. These bugs were problems in terms of actually determining the way the software should function in order for it to be useful for the user.

That’s an interesting idea. As we’ve built more frameworks, abstraction layers, and other tools to help us program, you would expect that many simple bugs, things like issues with memory, buffer overflows, etc. would become less prevalent, and more often we’d have these flow bugs that are based on how the software is used. It’s a topic that begs this question for a Friday poll:

Do you think your code has more bugs because of problems building the algorithm in code, or because of a lack of understanding in how the user will interact with it?

With more “agile style programming”, rapid development and changing of requirements, one would think there are more of the latter bug. However let us know this week what you think. Reflect on the issues that you have had in writing code, reports, user interfaces, even more complex calculations. Are there more problems with actually understanding the design of what you need to build, or the actual implementation once you understand it.

Steve Jones

The Voice of the DBA Podcasts

Showing Its Age

Are these computer too old to be in production?

I went to register a new car recently at the DMV and couldn’t do it. Apparently the state DMV system in Colorado was down that week, and had been down for two weeks because of a DR situation. The primary system had failed, and after being down, the state agency moved to their older, backup system. However when that failed, many of the remote offices were down and were issuing extensions to car owners for registrations.

I am guessing that the Colorado state DMV system runs on some sort of mainframe or mini, and not on a 15 year old PC architecture. However I do know lots of companies that are working on older software, often on older versions of Operating Systems that might struggle to work on newer hardware. It makes me wonder if we will start seeing these types of problems for database applications over time as companies look to extend the lifetime of their IT infrastructure.

There was a time when it seemed many companies were refreshing servers every 2-3 years, and they would upgrade to a new version of their OS or database platform whenever the vendor released it. However the last 5-6 years have seen many people holding on to older systems. I know lots of companies that are on 4 or 5 year hardware refresh cycles, and there are still lots of SQL Server 2000 instances still running out there.

For awhile it felt like keeping a database application alive for 10 years was a stretch, but as I look at the evolution of SQL Server, and the power that we have with modern hardware, it doesn’t seem like a stretch. The advances in virtualization can prevent newer hardware architectures from being a problem, and perhaps even extend the lifetime of old software significantly.

I do think that the latest releases of SQL Server are much, much more efficient and powerful than previous versions. Today’s hardware can even be more cost effective given the price of power and cooling. However if all you need are core database engine features, I’m not sure it’s worth upgrading. Just be sure that you have a better backup plan than the CO DMV.

Steve Jones

The Voice of the DBA Podcasts

Saying Thank You

This plane left without me😦

Recently I had problems with one of my flights. That’s nothing new, and as Grant Fritchey noted, I tend to anger the travel gods for some reason and often find myself in situations that make me regret ever leaving the ranch. In this case, I flew to the Dallas-Fort Worth airport, which was fairly close to SQL Saturday #63. I attended the event, and drove back early Sunday morning in time to have some coffee before my flight. I walked in, went straight to security with no bags to check and a mobile boarding pass. I scanned my phone 4 or 5 times before the security guard told me to leave.

Actually he didn’t tell me to leave, and was very polite in asking me to go check with the airline for a new boarding pass. The airline agent informed me that my flight was out of Love field (new service starting that day) and despite my early arrival, I wouldn’t make it to Love field in time.  I was stunned as I had booked a flight like I normally do: pick an outbound flight, then an inbound one. I  have never been presented choices from a different airports for the return flight, but in this case that was what happened.

I could have gotten upset, especially after spending 5 hours in the DFW airport waiting for another flight. Instead I tried something else. I sent a nice note to Expedia, letting them know that despite my issues, I am pleased with the way that they provide a booking service on the web. I have used their site for years, and it’s been a nice tool for me, allowing me to keep all of my data in one place. Their services have expanded over time and I like their service. I then told them of my issue, and noted that it might have been a bug or a glitch, but in any case, it was an inconvenience for me.

It was a strange situation for me, and a convergence of a few things. My inattention to detail, new service for an airline, and a large city with multiple airports. I rarely fly to cities with more than one airport to choose from, and was willing to accept some of the blame. However I also know that application developers try to build applications that work, and a little praise is always appreciated.

Steve Jones

The Voice of the DBA Podcasts

You Don’t Know Enough

Always be learning

We always expect developers to test their own code and be sure that it works as expected before they release it for anyone else to use. However we should be aware that developers won’t think of all the edge cases that might break their code, so a good software process includes another group (QA) that tests the software separately, and hopefully also reviews the code as well.

Why do we do this? It’s because you can’t be sure that just because code passes your own tests that it is well written. You can only be sure that it passes the various tests you have designed, which is likely a subset of all possible tests it ought to pass.

Bruce Schneier wrote a piece that talks about this from the security perspective. If a system fails initial testing, we know there’s a problem. However if it passes those tests, we still don’t know it’s secure. There still might be other vulnerabilities, perhaps even obvious ones. Only through exhaustive testing and review of the code, can we gain any sense of confidence in the security of a system. Even then we would still want to include some monitoring of the system as vulnerabilities might be discovered at a later time.

Each of us has some limited amount of knowledge about the technology we work with, but there is one common thing we all share: we can all learn more.  Those limitations of our knowledge carry over to the code we write, and mean that we won’t necessarily completely test our code to cover all possibilities.  We might not even remember to test for some things as our work gets more complicated.

We need to work with others to ensure enough code coverage and have some level of confidence in the quality of our work. Today’s systems are just too complex for one person to completely understand. Once you accept that and learn to work in a team, critiquing the code of others and accepting criticisms from them on your work, you will find the quality of your software will rise.

Steve Jones

The Voice of the DBA Podcasts

How to Fix Connect

Microsoft Connect is the place to submit feedback

The Connect system is the main way that all of us can feed back information on SQL Server to Microsoft . You can use this system to submit a bug or a suggestion, and your submission will go to the SQL Server development team so that they can respond. There is the ability to comment on other people’s posts, view workarounds that Microsoft or another user have posted, and vote a suggestion up or down. A great example that’s one of the most voted on items is the Create or Replace idea.

Recently a large number of Connect items were closed, including a few that I had submitted. Based on all the Twitter comments, it seems that most of these items were closed and marked as “Won’t Fix”, which I assume means these will not be fixed for SQL 11.

That’s good and bad. Having watched the Connect Feed for SQL Server, I’m surprised by some of the suggestions that I see come through. While I can appreciate someone wanting to know when SQL 11 “Denali” will be released, I’m not sure it’s worth a Connect submission. Or this brilliant duplicate indexes note. I feel bad for the people that triage these requests since these not-very-well-thought-out submissions create ill will and waste time. How would you like to get these type of suggestions for your software? My guess is most of these suggestions ought to be closed and this was a good thing.

But it’s also discouraging for those of us that submit feedback and don’t necessarily get a good response on why our feedback doesn’t make sense, especially when you have dozens of people voting for the idea.

For a long time I really liked the SQLWish email address where one could send ideas to Microsoft. That was discontinued in favor of Connect, which I think is a good idea. However I think Connect has a scale problem and doesn’t necessarily work as well for “ideas” as it does for bugs.

I’m not sure how we can fix it, but one thing I’d like to see is a ranking of the top xx items that could be considered for the next version. Feed that back to the community and let us give you opinions on whether or not those items are still important. I know we can’t necessarily drive development, but I do think that SQL Server can evolve into a product that we are more likely to upgrade if our feedback is visibly and obviously considered.

Steve Jones

The Voice of the DBA Podcasts