Voice of the DBA

Category: Editorial

  • Which Bugs Do You Find?

    Software bugs are usually not this easy to find.

    I was listening to a StackOverflow podcast awhile back and there was a discussion on  programming, debugging, and how software has changed. One of the interesting things was that we have solved many programming issues and are building more complex software, which has resulted in the types of bugs that we often find today are different than the bugs many of us older folks used to deal with in programming.

    When I was writing code as a youth, we often had bugs that were process bugs. We were trying to get software to do X, and struggling with actually how to tell the computer that X should occur. I heard a few people on the podcast mention that they typically didn’t have those bugs too often, at least not once the software was at a point where they would release it for general use. Instead they talked about finding bugs that were issues because the flow of the software wasn’t what the user expected. These bugs were problems in terms of actually determining the way the software should function in order for it to be useful for the user.

    That’s an interesting idea. As we’ve built more frameworks, abstraction layers, and other tools to help us program, you would expect that many simple bugs, things like issues with memory, buffer overflows, etc. would become less prevalent, and more often we’d have these flow bugs that are based on how the software is used. It’s a topic that begs this question for a Friday poll:

    Do you think your code has more bugs because of problems building the algorithm in code, or because of a lack of understanding in how the user will interact with it?

    With more “agile style programming”, rapid development and changing of requirements, one would think there are more of the latter bug. However let us know this week what you think. Reflect on the issues that you have had in writing code, reports, user interfaces, even more complex calculations. Are there more problems with actually understanding the design of what you need to build, or the actual implementation once you understand it.

    Steve Jones

    The Voice of the DBA Podcasts

  • Stalking the Bad Guys

    Tracking down bad guys

    Suppose you found some malicious code on your system. Maybe it’s a login that didn’t below at the sysadmin level, or maybe a stored procedure that might disable a trigger, make a change, and re-enable the trigger. What do you do?

    Suppose you stumbled upon a strange stored procedure in one of your databases. It wasn’t something you had coded, and it appeared to be altering permissions, maybe adding a login, or even querying sensitive data. What do you do?

    The easy answer is to delete the procedure and go on about your day. Some of you might save a copy of the code, along with its permissions and make a note to check the system a week or two later and see if it needed to be there.  However I’m not sure that is the best action to take.

    If you are unaware of the origins of code, it can be detrimental to your system if you remove object. A legitimate stored procedure might cause application errors, which can result in some type of discipline. At the very least, managers might be upset with you for taking action without understanding the consequences.

    I think a different approach might be better. Set up auditing or tracing, focusing on the code and documenting any actions. I would talk to security people and potentially initiate lower level tracing of the network to determine who is making use of this code. If it’s truly malicious code, it’s not necessarily your job to stop someone. Setting up the honeypot, documenting actions, and then allowing someone else to determine the final action might be the best way to deal with the situation.

    Steve Jones

    The Voice of the DBA Podcasts

  • Working Long or Working Hard

    Do you want to work hard or long?

    Seth Godin has some very interesting things to say and often makes me think with his short posts on the world. I saw him speak a few years ago, enjoyed it, and while I don’t always agree with the way he views the world, his comments and thoughts often cause me to rethink my position. Recently he had a blog on Hard Work vs. Long Workthat made me stop and think about my career.

    Seth talks about the difference between those two types of effort, with most people dreading hard work more than long work. I think most people would say that they’d rather work hard for 8 hours a day then work for12 at a lesser pace. Most people in IT seem to not want to work long hours, especially as they age, and would prefer to work hard for a shorter period of time. However,  my guess is most workers tend to shy away from hard work more than long hours.

    Why is that? Seth nails the reason when he mentions risk. Doing hard work involves risk, it involves taking chances and trying to fundamentally do something that is hard. If it wasn’t a challenge, we wouldn’t call it “hard” work, and everyone would tackle it. However the risk introduced by taking on a difficult task is daunting to most people, especially if failure might involve consequences. Most people avoid increasing their risk, even at the expense of spending more time coasting along.

    We see this every day in our jobs, and I know I’m not immune. I implement change slowly, and tend to shy away from risk. I do take some changes, but they are calculated efforts, without too much downside.  Both at work and in the rest of my life, I am definitely risk-averse.

    Should you be doing hard work instead of long work? I can’t answer that for you, but I would urge you to think about the differences, and understand what you are more comfortable doing. It pays to leave your comfort zone as you often grow, but being uncomfortable with the way you work is also a large source of stress in your life. And stress is best dealt with in short doses, not long periods of time.

    Steve Jones

    The Voice of the DBA Podcasts

  • Competing with an MBA

    It seems that if you want to move up in management, you need an MBA. At least that was the prevailing wisdom a few years back as I worked in various corporations. Most executives were expected to get an MBA, and most did. There was an explosion of “executive MBA” programs in the late 90s and early part of this decade allowing employees to earn an MBA while still working in a full time position.

    However a lot of the MBA program was geared towards teaching hard topics, like finance and accounting, and ensuring that graduates understood the roles of information technology in a company. I think that was a bit of a mistake as we ended up with a generation or two of managers who viewed ROI, profit margin, and the bottom line as the most important parts of a company.

    Companies are realizing that becoming an executive and leader takes more than understanding numbers, and are starting to look to hire candidates that have stronger “soft skills” that emphasize working with others, understanding other viewpoints, motivating employees, and relating to customers. Business schools are starting to catch up in these areas and looking to offer more courses that deal with softer skills.

    If you are interesting in advancing into management, an MBA might be a good investment, but I would also argue that building strong soft skills is just as important. If you demonstrate strong abilities to interact with others, solve problems, handle disagreements, and act as a leader, you might be just as strong a candidate as that recent MBA graduate.

    There’s a lot more to IT than technology, and a lot more to business than crunching numbers. Those soft skills will be valuable in every facet of your life, and are worth spending some time on in your personal development plan.

    Steve Jones

    The Voice of the DBA Podcasts