Voice of the DBA

Tag: software development

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

  • Accept Failure

    Failure is sometimes an option

    We don’t expect ourselves to be perfect, do we? Is there ever any project you tackle that you might not complete? Is there a doubt that it might not work as expected, or that it may need substantial rework? I think that the vast majority of projects I undertake have some level of risk involved, and while I might understand that, I’m not sure I ever believe I will ever fail.

    Most things that I’ve built in technology don’t work the first time, and in fact, I expect that. I have learned from mistakes, corrected the problems, and usually finished them with some level of success. That’s the way that so many of us in technology approach our jobs. We start building, find issues, and then fix them.

    However you cannot every eliminate the risk that something will fail. There are times we need to abandon the project or abandon the work done and rebuild the software from scratch. Those failures should be learning opportunities, and should allow developers to improve their work. From my perspective it seems that too many managers, however, view failures as events that have to be avoided. Perfection and success are the only possible outcomes that are acceptable. One slip up and you may get fired.

    It seems that’s what managers think about their career, so they continue to push down dead end roads, and throw more resources at a project to recover some small level of success.

    We will always make mistakes. The true failure should come from failing to learn from the mistakes and improving your future work. If management cannot tolerate these setbacks, this problems, and allow for them, then the work will not only continue to be substandard, but people will spend more time worrying about avoiding blame than actually looking to improve their skills.

    I can’t tell you when work should be abandoned, or a project is hopeless, but every project ought to be examined periodically for this situation, especially when it is apparent that it is in trouble. You can’t save all projects, but you can learn to let some of them go, or change the situation, before it becomes a bigger problem than it is.

    Steve Jones

    The Voice of the DBA Podcasts

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