Tag: software development

  • The Control Poll

    Source Control provides lots of benefits.
    Source Control provides lots of benefits.

    I was reading about version control systems (VCS) recently, brushing up on some skills, and saw this quote in a thread:

    “There is no excuse for not using version control, even for a small project developed by single developer. Setting up local version control is beyond trivial, benefits huge. Any developer not knowing that cannot be considered good nor experienced.”

    That’s quite a pronouncement, and one that I believe is very true. No matter what type of development you engage in, I’d expect that you’d understand the benefits of using version control, and the dangers of not using it. It’s just like never backing up your system. I’d think that any developer that cares about their craft and is a professional has used version control. The really good ones will insist upon it.

    However I know that the decision to use a VCS is not always made by a developer. The company building the software might feel differently, and while I’ve always asked for a VCS, I have ended up with a series of folders on a share, named for dates, each containing a zip file of all our code at the end of that day. It was the bare minimum of version control I could live with, and fortunately we got by with just two people coordinating work. Any more than that and I’d insist on some type of VCS.

    This week, I wanted to ask how many of you voluntarily or involuntarily might be forced to do something similar.

    How many of you skip source control for certain apps?

    Even if you have source control for those large, multi-person teams, are there apps that you avoid putting into a VCS? What about your database code? I think it’s important that you keep all your code, whether for the front end application or database objects, in some type of Version Control system. If your boss won’t buy one, then check out Git or Subversion, both of which are open source and free.

    Let us know this week how you feel about source control and whether or not you decide the effort isn’t worthwhile for your projects.

    Steve Jones


    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Not My Google Reader Replacement

    Someone suggested Newsblur to me, and I went to their home page. Like many sites, it asks you to sign up, so I decided to give it a try.

    newsblur2

    The import from Google Reader caught my attention, so I clicked it. It asked for an authorization from Google, and then I got this page:

    newsblur

    I have to say. Not only do I now see anyway to understand the difference between $2 a month and $3 a month, but I also feel like this is a bait and switch, given the top banner. This could have been called out on the home page, though I suspect not as many people will click through.

    I’d gladly pay Google Reader $2 a month, but I know what I’m getting. Here I’m not sure, and I’m already annoyed.

    The search continues.

  • Better Coding, More Savings

    Learn to build better systems the first time with a little investment in your career.
    Learn to build better systems the first time with a little investment in your career.

    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


    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Practicing Deployments

    Practice makes perfect, especially for deployments.
    Practice makes perfect, especially for deployments.

    It’s said that amateurs practice until they can get something right. Professionals practice until they don’t get something wrong. That’s the idea, and while professionals make mistakes, they make far fewer than those that don’t approach their craft as a professional task.

    Many of us in the data industry develop software in some way. Whether we write queries in T-SQL or build projects in .NET, we produce code to accomplish some task. I’d like to think that many of us improve our skills over time, preferably by practicing new techniques and learning from our mistakes. I know some people stick with the tried and true methods without gaining skill over time, which not only hurts one’s career, but also doesn’t give an employer a reason to value their work.

    However the deployment of software, which encompasses more than the developer(s), doesn’t improve in many cases. Deployment includes operational people’s skills, scheduling dowtime with clients, possible even the briefing of support personel. However the whole process is often performed poorly. Deployments fail, or require more time than expected. People view them as a pain, and software deployment tends to happen less often than it could, resulting in a large software inventory.

    There’s a great quote from James Moore on how we can deploy software better: “…deployments are hard, but rather than long-winded planning, they need constant practice, testing and refining, and we could only do this by deploying early.” Red Gate Software has learned that deploying more often results in the company gaining skill in deploying software, resulting in more successful software changes in applications.

    The improvement you make in your software can bring tremendous value to your clients, but only if they can use those features in the software. Learning to push those changes out in a repeatable, professional manner is a great way to ensure your clients and customers trust you to deliver new features and enhancements that meet their needs.

    Steve Jones


    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.