Tag: software development

  • Great Developers

    This editorial was originally publised on March 12, 2012. It is being re-run as Steve is on vacation.

    Is a great software developer worth 100 average ones? On one hand I think there are some good arguments that it’s not true. One developer certainly can’t write the amount of code that 100 average ones can. However there’s another way to look at things. A great developer can do things that the 100 will never think of, or never consider. He might not write the code that does as many things as 100 people, but I think a great developer could easily write code that performs a hundred times faster than the code 100 developers write.

    That’s why you always have an open position available for a great developer. If one is available, and they rarely are, you hire them if they want to work for you. You can always find things for them to do, and they can make improvements in code that your other 5, 10, or 20 developers will never come up with. I’d make sure they fit in your team and get along with others. You can get less work done if you have someone that is too difficult to deal with or too critical of others. While a great developer can accomplish things that others can’t, or won’t, they can’t do all the work.

    Ultimately I think that managing great developers is hard, and they are unlikely to stay with your company for a long period of time. However they are rarely available, and for a few years, they might jump start the evolution of your software, and potentially build something that makes your software great. I’d always have an open spot in my team for a great developer, and hire them as soon as they came available, if I thought they would fit in well with the rest of the team.

    Steve Jones

  • 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.

  • What is the True Version of Code?

    As I’ve been working on more development tasks, I regularly hear from developers that a version control system (VCS) is the “true” version of our code. We should always look to a VCS for the actual code that we need to work with. I believe that, and I think it’s true.

    However I heard a DBA say that the true version of the code is always in production. That’s what’s being executed, especially in the database world. There is some truth here as well, but in my mind this speaks to a broken process. This means we have a more chaotic, and less “engineered” way of producing our software. Perhaps more importantly, we don’t have a good source from which development can proceeed.

    Certainly hot fixes need to occur, and there are times that you can’t wait for a set of changes to be made in development, tested, approved, and then deployed to production. I think you can overcome most of this, but there may always be cases where this happens, so I don’t think we should  argue about how fast a software deployment pipeline we can build.

    Instead I’d say that production changes should always be fed back to the VCS. Our code is an ever changing set of files that we can only really keep track of by using a proper VCS. We should be able to track back the view of production at any point in time to a set of versions for our files in a VCS.

    Certainly some of you have gotten by for years, perhaps your entire career, without a VCS. However I’d argue that isn’t a good position for your organization. What habits and skills you have could easily be lost if you leave, and your memory isn’t a point of record. A stable system, a VCS, should note the state of our systems, both in development and production.

    And if you’re worried about the cost of a VCS, there are plenty of free (as in beer) ones. I recommend Git, but there are plenty to choose from. In terms of overhead, certainly you can use tools like SQL Source Control or ReadyRoll, but even without those tools, using a VCS really just requires building some habits. If you aren’t willing to change your workflow slightly, there’s probably no way you will ever ensure your environment is under control in the long run. However, if you do change to a VCS, I think you’ll find it’s well worth the effort.

    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.

  • Custom Column in SQL Data Generator

    This is a series on SQL Data Generator, covering some interesting scenarios I’ve run into. If you’ve never tried it, SQL Data Generator is a part of the SQL Toolbelt. Give it a try today with an evaluation today.

    One of the interesting things with Redgate’s SQL Data Generator (SDG) is that it allows the user of custom data patterns for your columns. The user of regular expressions (RegEx) is used, which is something I find many SQL Server DBAs don’t really work with often.

    While there are plenty of RegEx tutorials out there, I wanted to give some simple ideas here that I’ve used to make slightly more realistic data.

    Help

    There’s a help icon available if you choose a column in one of your tables and have a regular expression selected. In this case, I can see there are a few different suggestions for the “title” column.

    2015-08-28 09_30_34-

    SDG guesses that title is a Mr/Mrs/Ms field, but it’s not. I really need something that looks like the title of an article. If I scan through some of the articles on SQLServerCentral, I see titles like:

    In this case, there are a few patterns. SQL Server appears in a few places, Some articles user a “top x” type of format. The word lengths vary, and are in the 6-12 range. Around six or so words are in many titles.

    Building a Regular Expression

    I could certainly do something like this, which just gives me a few words made up of random letters, of the specified lengths.

    [A-Z]{3} [A-Z]{5} [A-Z]{7} [A-Z]{4}

    I’ve got a 3 letter word, then a 5 letter one, then 7, then 4. All upper case, all random. That gives me results like this:

    2015-08-28 09_38_37-SQL Data Generator - TestSDG.sqlgen _

    Not quite what I want. I’d rather have some words at the beginning like “A”, “The”, or “Top”. I can do that with literals.I enclose those in parenthesis rather then brackets.

    (A|The|Top) [A-Z]{5} [A-Z]{7} [A-Z]{4}

    This gives me something slightly better.

    2015-08-28 09_41_23-Get Started

    Not perfect, but better. Let’s clean up the words themselves, following some capitalization rules for titles. In this case, we’ll use a pattern like this:

    [A-Z]{1}[a-z]{5}

    Now I see something a bit better. This doesn’t make complete sense, but it does look like random word structures.

    2015-08-28 09_43_20-SQL Data Generator - TestSDG.sqlgen _

    Let’s change the “Top” item to include a number. I can do that, but changing just the part of the OR (|) that includes Top. I’ll do that like this:

    (A|The|Top [3-7]{1})

    Now I see a number, randomly from 3 to 7, when Top comes up.

    2015-08-28 09_46_20-SQL Data Generator - TestSDG.sqlgen _

    This still isn’t great. How about if I include SQL Server at the end? I’ll use a space, or something with SQL Server.

    ( |(in|for|on) SQL Server)

    That shows me a random addition to SQL Server a the end of some titles.

    2015-08-28 09_48_31-SQL Data Generator - TestSDG.sqlgen _

    Getting better. I can even use the space or something to get the versions of SQL Server.

    ( |(in|for|on) SQL Server ( |2005|2008|2012|2014))

    Now I see some interesting titles. What if I want real words instead of random ones? There’s nothing wrong with random data for testing, but if I’m actually trying to compare data values in queries, it’s hard to focus on and remember random patterns. I could use the same OR values.

    (A|The|Top [3-7]{1}) (Blocking|Indexing|Tuning|T-SQL) (Tips|Techniques|Methods) (for| |in) ( |(in|for|on) SQL Server ( |2005|2008|2012|2014))

    Now I get some interesting, and perhaps memorable titles.

    2015-08-28 09_53_41-SQL Data Generator - TestSDG.sqlgen _

    Have Fun

    For much of our development work, the data itself doesn’t matter, but if needs to be easily discerned if you want to ensure that it’s easy to examine in queries. While random values work fine, I find them hard to deal with.

    I like the idea of using random words. Often the results are still nonsense, but they can be fun to work with. They remind me of a set of magnets my kids have on the fridge. Each is a word that will get randomly combined with others for humorous sentences.

    You can do the same thing with some RegEx and SDG.