Tag: software development

When I was in college, I mostly wrote my own code for assignments (and fun), turning it in when I thought it was done. At some point I had a class that started to adopt more software engineering practices, and I was forced to get my code reviewed by a peer before handing it in. This was an interruption to my workflow (and more work since I had to review other code), but it did allow find mistakes I had made and seemed to improve my grade.

In one of my first development positions, I had to get two people to review my code before I could submit it for deployment. A humbling and painful process at first, but over time I became used to the idea. I’m not sure the quality of code improved, but it was more readable, more in-line with everyone else’s code, and as we learned techniques that worked well, all developers adopted them quickly.

These days as I talk with various customers and clients, I find that code reviews are handled very inconsistently. Some companies require them, some have automated processes, some have ad hoc reviews, and everyone has ways to circumvent the system. Certainly emergency patches need to be made at times, often with little review, but I will say that it seems the more common a set process and practice is, the less issues a customer has.

If you review code, or have your own code reviewed, on a regular basis, I have question for you.

How much code can you review for a deployment?

The question I’m asking is about your process and habits. Is it worth reviewing every bit of code? Perhaps there are objects that you don’t worry about as much as others, or certain developers that receive more (or less) review of their code. Perhaps seniority makes a difference as to the level of scrutiny. If there are problems found in QA and changes made, is there a way to re-review code? I’m wondering today about your process. Share what you can, and if you want to do it anonymously, please feel free to send me a note at sjones (at this domain).

Steve Jones

The Voice of the DBA Podcast

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

This editorial was originally published on May 13, 2013. It is being re-run as Steve is on holiday.

I’m sure most of us would like to think that we write fairly efficient code. However the reality for many of us might be that we don’t actually know. Many of us use the same patterns and practices that we’ve been using for a long time, rarely changing. When we learn a new technique or find a different way of coding that works better, we tend to then use that method over, and over, and over, and over again.

I would guess that if many of us profiled our code, and examined the CPU and network bandwidth we consume, we might be surprised at what we find. CPU and network usage isn’t something we are often concerned about. We assume that we’ve bought a machine and we should be able to use as much of it as we can at any point in time. That’s not the best approach, but since we often have more hardware than we need for many processes, it works. It also explains why so many applications struggle as the load increases. They’re not coded efficiently.

If you’re going to work in the cloud, you better learn to code more efficiently, mostly because it costs money. If you think about your design, you can reduce the amount of resources you use. In the cloud this translates to less cost. In the on-premises world, this means better performance and higher scale. It also means less complaints and phone calls.

Scaling up an application can be hard, but much of the struggle comes from poorly coding your application in the beginning. Most of us have heard the saying that it takes less time to do it right the first time. That’s true in many situations, and it’s true for your application development. Learn to write more efficient code and use patterns that conserve resources. You’ll find your applications will run better, no matter what type of environment hosts them. If you’re not sure what patterns and practices work well, read an article or ask a question and find out what efficient techniques others use.

Steve Jones

This editorial was originally published on Jan 7, 2014. It is being re-run as Steve is at SQL in the City today.

My first exposure to computers was as a child, learning to program in BASIC, Assembler, and Pascal. From there I moved into other areas, such as networking and system administration. I learned about a variety of technologies before focusing on databases, but I found that my knowledge from other areas of computing helped me be a more successful DBA at quite a few jobs.

Last year we put on a number of SQL in the City Seminars where Grant Fritchey and I talked about development practices. We give a variety of advice and practices that you can use, but one of the best things that we say in our half day event comes from Grant. He says that DBAs need to “Follow the local development paradigm as much as possible.”

I completely agree with this. I think that many of the practices of building software, as flawed as they might be, are good ideas that many developers use on a regular basis. They know how to work in a flexible manner, tracking their code and keeping it under control, and fixing problems in a rapid manner. As immature as the software development process can be, there are things that we, as DBAs, can learn.

As SQL Server continues to grow as a platform, there are more and more enhancements, many of which involve programmatic capabilities expanding. I highly recommend that DBAs think about learning more about programming, and specifically a .NET language, if you’ve never used one. If you have, consider brushing up those skills.

Steve Jones