Voice of the DBA

Tag: software development

  • Estimates

    Estimating the time it takes to build a piece of software is quite a difficult task. As many of us have seen over the years, most estimates can wildly differ from the actual time it takes to complete a project. There are lots of reasons for this, but I was surprised to find this post explaining some of the problems in a very interesting way.

    I realize that many software projects are very different in scale and scope, but I hadn’t ever considered the spectrum to be quite as wide as explained in the post. Just as in other industries, there are times that your software project needs to create its own technologies and techniques in order to be successful. While software might not be as complex as curing a disease, it might not be that far off at times.

    However it’s not just that the body of knowledge about software development techniques is so vast, it’s also the problem that each of us might have a very limited amount of knowledge about building specific types of projects. What might seem simple and easy to some developers feels complex to others. A simple example I’ll give you is with version control. I know version control isn’t the same as building software, but it’s a tool that many developers use.

    I think version control is fairly trivial to implement and use. It can be a pain to use with T-SQL code and scripts without some tooling, but it’s easy to learn how to use a version control system (VCS). However as I’ve spent two years talking about version control at various events to lots of people, and I still meet lots of people and organizations that see a VCS as an impediment to getting work done. Hint, it’s not.

    I think we share so much knowledge in the SQL Server community, but it still seems that we don’t seem to be educating people as well as I’d like, and as quickly as I’d hoped. Our Stairway Series were designed to try and organize information, but I’m sure there are other, better ways to do so. I’m open to suggestions, and other efforts to help raise the level of knowledge for SQL Server professionals. I’d like to find ways to help people learn more, write higher quality code, at a faster pace.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.8MB) podcast or subscribe to the feed at iTunes and LibSyn. feed

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music.

  • Silicon Valley is a different world

    I spent the last couple days at Flowcon 2014, a conference that is bringing people together to talk about growing their organizations with continuous delivery and design, and lean product development.

    It does some of that, but it wasn’t what I expected. The attendees for the most part were people that already believe in continuous delivery, in lean principles for their organization, and in flow. If you don’t know what flow is, read the Phoenix Project, Martin Fowler, and other lean, agile methodology books. It’s a concept from labor and manufacturing, with the idea that we can increase the rate at which we get work done.

    I believe in it, it’s a tenet of DevOps, and I think it works well. The conference features people from Netflix, Nordstrom, Etsy, Thoughtworks, and other companies that are already using these ideas. They believe, and they are looking for ways to better smooth out their own groups.

    However they also have ideas about rapidly changing and adaptive groups and organizations, which isn’t where most of us work. Far, far too many people are still stuck performing waterfall work, or even waterfall-like work.

    It’s also a world where people are looking for startup ideas, looking to move quickly and build something new. It’s a world that’s quite unlike my own. While there’s a buzz and energy from many people, it also feels somewhat shallow and hollow from some that are searching for riches. It’s also a bubble of thought that is so far away from most of my experiences, that it feels sheltered and idealistic.

    Don’t get me wrong, it’s exciting, and there is a passion some of these people have for their craft that’s inspiring. I’m just not sure it’s a place I’d want to be every week.

    However I do wish more and more people would look to better develop software. If we are to improve as an industry, I think many of the ideas and techniques that are invading the software development world related to flow need to be adopted.

  • Hooks

    I read this sentence recently, and it really caught my eye, mostly because I’ve rarely seen hooks being built into the software systems that I’ve written, or that have been deployed to my production systems.

    “A quick chat with your Operations team should convince you of the necessity to log every error condition to a single wellknown location, with the appropriate severity, so that they [the Operations team] know exactly what the problem is.”

    It seems obvious, but so few people I know have taken advantage of this. Far too many software products build their own logs and display errors on screens rather than alerting operations departments. So few people have taken advantage of RAISERROR to write to Windows logs, or the custom SQL Server performance counters to disclose information to operations systems or personnel.

    That’s my experience, but I wanted to ask you this week how you’ve handled things. Do you have software installed that does this? Is it a part of your development process to include hooks?

    Do you hook your logging into operations systems to alert others?

    As I think about it, I can’t imagine not doing this now. After all, I like to sleep. I don’t need calls at 2am from Production operator trying to find a log and debug a problem. I’d rather ensure that I log information to well known places and ensure exceptions will catch the eye of operations people. I want to give them as much information as I can in order to help them solve the problem. I’d rather sleep and depend on the on-call staff then be woken up because they rely on me to solve problems.

    Personally I think that logging to the Event logs, or including configuration switches to send alerts to other software ought to be part of the best practice of developing software. It’s a maturity point where we recognize that we’re building interconnected systems, not individual bits of software that live like hermits.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.6MB) podcast or subscribe to the feed at iTunes and LibSyn. feed

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

  • Reverse Engineering Disasters

    If you are responsible for managing systems, you should have some sort of disaster recovery plan. Even if you are only managing the one system you carry with you on a regular basis, you should ask the question: What would it take to destroy this data?

    It’s a good question, and in the post I’ve linked above, a technologist talks about some of the failings of disaster recovery plans because they forward engineer plans to recover systems. People think of specific problems and try to prevent them. They don’t reverse engineer to find out what events would cause them to lose their system.

    That’s really the key to a lot of design and architecture in computer science. You can’t think about just what you expect to happen, or even what you want to happen. You have to consider the other ways in which events could occur or the issues that could cause an problem in your system. In development, the things you expect are considered to be the happy path. A good architect or engineer will think about everything else in addition to the happy path.

    I sometimes think that far too many decisions are made while considering the happy path, but ignoring or discounting the other paths available. These other paths may be unlikely to occur, but having worked with computer for over 25 years, I can tell you that I often find the least likely events occurring far too frequently.

    As the author says, you should never say “I never even thought of that happening.” Consider reverse engineering problematic situations and then make a judgment of how likely is it that any of the events will occur. That way you have at some idea of what could go wrong and what events you are willing to protect against.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.1MB) podcast or subscribe to the feed at iTunes and LibSyn. feed

    The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.