Voice of the DBA

Tag: software development

  • Being Responsible for Code

    I read this great account of how Facebook releases new code, and found it to be very interesting. Apparently the entire FB site compiles to a single 1.5GB binary at this time. That in and of itself is interesting, but their deployment strategy caught my eye as well. They use bittorrent to deploy the large file to all their servers. Very creative and interesting look at things from one of the largest web sites in the world.

    The process is interesting, but one of the comments caught my eye. It includes a quote from the article:

    developers must be held responsible
    I’m sure many DBAs wish developers were held responsible for issues.

    I know there’s no shortage of developers that make mistakes and don’t want to have responsibility for the code they release. I like the idea of tracking these metrics, and letting people’s actual performance being a part of their evaluation each year. Not trusting the manager’s memory, or the recent complaints from co-workers, but actually looking at the relative mistakes being made. This leaves out scale, but I’m not sure the scale of the mistake is as important as the frequency.

    However this is a double edged sword. Some people will perform worse if you place them under this pressure and may find it too stressful an environment. If you don’t have the same pressures as a company like Facebook, you might end up driving away good employees that could fit in elsewhere.

    My recommendation would be that you hold people accountable for their work and use metrics like this to actually track that back to specific incidents, but that you use this as only a portion of someone’s evaluation. Track other measures available that help you determine if a particular worker is contributing value to your company outside of the bugs they might have in their code.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Tabs or Spaces

    Obfuscated Code
    Hopefully your code doesn’t get formatted like this.

    An argument among developers that might rival the NULLs/No NULLs debate, or even the comma appending/prepending items in T-SQL might be tabs versus spaces. I was engaged in a debate recently with a developer on this very topic, with this person insisting that tabs were the proper way to handle indentation in code, and my insisting just as hard that spaces were the way to go.

    Actually, I should clarify, I think that tabs should be inserted into code as spaces, so that a consistent layout can be maintained. Most tools allow for this, and while I have never worked in a place where the tab/space ratio was entirely consistent among all those writing code, I have found that using ASCII 32 is preferable to ASCII 9 when files are shared among different people.

    Am I right? I don’t know that I’m right, but I have found that spaces result in less issues, and easier to read code over time as more and more developers work on a project. Invariably spaces creep into code, and when they mix with tabs, the visual layout of the code can vary wildly, depending on the configuration of the developer. I understand that indents and alignment differ, and using a mix of tabs for indentation and spaces for alignment can work. I just feel that this is an additional level of conformity that will never work well for most team projects.

    There are all sorts of arguments for tabs, for spaces, even for saving the planet. The one thing I know is true: the only programming project with no disagreement whatsoever on code formatting is the one you work on alone (from Coding Horror). I also love the concluding sentence in that post (since I agree with it).

    With that in mind, I do think having a standard makes sense, and while the standard might annoy a portion of your developers, overall they will get used to it and be more productive than having no formatting standard at all.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Great Developers

     

    Are you on track to be a great developer?

    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 Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Code Scanning

    Code Review
    I think we need better tools for scanning code.

    When I started writing code, the applications I wrote for various companies would only receive manual code reviews from my peers, and then limited testing from a group of people that were usually bored and unchallenged in their jobs. More often than not, I’d be asked by people what to test, how the various parts of the application worked, and receive a basic double check on the tests I’d run, not any extensive analysis. I think a lot of people had, or even still have, a similar experience, which is one reason we have such poor security in many applications.

    These days I know there are much better tools for testing applications, and I have heard of black box scanning of static source code. I haven’t heard of too much real time scanning of the executable code by the authors of code, but I’m sure there are tools out there to help you find vulnerabilities. I saw recently there are even better tools for scanning code that combine both techniques into something being called glass-box scanning.

    Security is a problem in many applications, and it’s great to see more tools being put into place to help uncover issues before our customers do. I don’t know to what extent we are vulnerable in these ways at the database level, but I suspect that we do need better tools to help us comb through access logs, as well as double check permissioning for users and objects. When we do have security problems, they are usually large security problems because of the large amount of data that can be exposed inappropriately, yet we don’t have very mature tools and processes for monitoring and detecting problems.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.