Voice of the DBA

Tag: software development

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

  • Should we outsource identity management

    My Database Weekly editorial for Jan 30, 2012

    One of the first things many people build when they’re developing an application these days on the web is a login/identity system for their users. This allows them to identify people, customize the features and functions, and separate out the different classes of users from each other. However many developers don’t really understand good, secure design, much less encryption, and end up “storing passwords hair kari in unsecured databases”, a quote from this piece on password security.

    I’d hope that most developers know that passwords should be stored in a digest (one-way hash) form, but that’s like assuming most developers understand the issues with SQL Injection. It’s not true, and not necessarily going to be true until, well, it’s not likely to ever be true. Even if we had minimum standards, there are plenty of developers that would ignore them and plow forward with the arrogance that their custom method is better implemented, and more secure, than any standard.

    Passwords and password security are hard. I’d hope that most people would be looking to move to passphrases instead of passwords, but I don’t see the recommendations being widely disseminated in the world. I recently rebuilt a computer, requiring my kids to implement new credentials, and my recommendation was a simple phrase they can remember with a number. I was hoping it would serve the dual purpose of instilling good security habits as well as improving their typing skills. We’ll see if it helps.

    With large rainbow tables, creative social engineering, and poor application security, it’s even more important now that we use passphrases, and even develop better identity frameworks for applications. Personally I liked the Passport system Microsoft had, and I like the OAuth system even better. Perhaps we can get more of these frameworks implemented in reference applications and frameworks, as a default way of managing identity systems.

    That’s the easy part; convincing developers they can’t manage identity better is probably the hard part and I would love to see some good ideas for that.

    Steve Jones