Voice of the DBA

Tag: software development

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

  • API Changes

    Not the best API documentation

    There’s an interesting set of predictions about the possible new APIs (application programming interfaces) that we may see in the future. It’s a look forward into 2012, and a guess that setting standard ways in which we can build systems will become more important in the future. There were two items that I found of particular interest to the data professional.

    The first was the idea that we might have more data APIs in the future, designed to make the exchange of data easier. The people that work with data imports and exports have probably been hoping for his to become more prevalent, and it has gotten better. However I do think that data is becoming the most important part of the technology world. It isn’t the software, or the platform, or the device, but the data that’s available that is the most valuable part of a technology system.

    It isn’t likely that any company can create and manage all this data themselves, especially in a rapidly evolving world where so much of it changes from day to day. A successful business will need to acquire data from other sources and easily integrate the information into its systems,, and an API will make this process smoother. I expect that standards like OData will become something that we work with more in the future.

    The second interesting part of the article talked about the possibility of us seeing more Enterprise APIs, developed and built by individual customers so that their systems can be more easily integrated with others. That would seem to be counterintuitive, but with so much knowledge and talent available outside your company from others that want to build apps to interact with you, I expect this may catch on, at least for those companies that see a demand from partners and customers. One very valuable effect of building an API? You get more data on how your customers use your API, allowing you to better understand how your company might change to enhance its performance.

    Building an API means setting a standard, one you have to support and maintain for years. It can evolve, but the core elements of it will live for a long time, so it helps to gain experience here. Think about providing APIs as you develop software inside yout company, rather than just assuming you’ll build all the functionality needed.

    Steve Jones

    The Voice of the DBA Podcasts

    We have one version of the podcast back and are working to get the others back soon.

  • Change Management

    Hurry up and wait.

    Hurry up and wait.

    In a couple of the large enterprises I’ve worked in, that might have been the IT motto. It seemed as though the internal developers were always under pressure to get applications finished as soon as possible. However we often found that when applications were finished, there would be a delay in deploying the new code to the production servers, usually because of a strict change control process that required documentation and testing of the changes on related systems. In many smaller companies I’ve worked in, we had no change control process at all and could deploy updates at any time.

    I’m not sure which of those two systems I prefer. In general, I prefer to have some change management process to ensure that I can easily determine what changes were made at any time. However I’ve found that any change management quickly becomes a bottleneck devoid of common sense and full of bureaucratic nonsense. This Friday, I decided to ask a question about change management, but not about your opinion of whether it’s good or not. The question this week is:

    Do you follow a change control process 90+% of the time?

    By this question, I mean is change control a habit, an ingrained sense of the way you work and deploy updates to a live environment. I’m not asking if you have a formal process, if it’s a team process, or anything about the details, but rather do you actually follow some methodology to track and manage changes?

    I’d like to think most of us would, if for no other reason than to answer the common “what changed?” question that always comes up when something breaks. However I’m curious to see the results.

    Steve Jones

    The Voice of the DBA Podcasts

    We are still having hosting issues with the podcasts. We hope to resolve this and be back to releasing the podcast versions of the editorial next week.