Voice of the DBA

Tag: software development

  • Truth and Demos

    Demoing SQL Server on stage

    In my career, I’ve given quite a few demos of various types of software, usually in an attempt to show how the application in its best possible light. I suspect that most people giving software demos engage in some level of simplification of a problem, or contriving one completely so as to make the software appear as simple as possible to use. One university thinks that Oracle went a bit too far, promising capabilities and misleading them about the costs and customizations that would be needed.

    I’m sure there are similar examples of this for all software vendors, especially those that sell large software packages such as ERP applications. Some are probably without merit, and are the result of customers not fully understanding what they are buying, but some are probably valid complaints where salespeople have misled customers in order to complete a sale.

    Most of us that work in technology and develop applications never sell our products for money. We often build our systems for internal users, but we are still selling something that I think is more important than money: our professional reputation. We work with clients, we promise to deliver some feature or solve some problem. If we do not complete the work as we agreed to, either we are not doing a good job, or we are misleading our clients. It’s the same way we might feel misled by salespeople when some purchase we make doesn’t work as expected.

    It’s your career, it’s your reputation, and I’d hope that most of you would want to ensure that when someone speaks of your work, they do so positively. Learn to communicate well with your clients, but do so in a fair, and truthful way that not only promises when you can deliver, but warns them about what you cannot. Or at least what it will cost.

    Steve Jones

    The Voice of the DBA Podcasts

  • Propose this to your boss

    If Nordstrom's can have an innovation lab, can't you?

    I’ve written a few times about the ways in which you could find interesting projects at work and potentially learn a few new skills while improving the ways your company uses technology. More and more companies are willing to allow side projects like the Google 20% time or the Atlassian FedEx days. My own company, Red Gate Software, implements this a few times a year as “Down Tools Week.”

    Many of you have replied that your companies are resistant to this, or your boss doesn’t think it’s a good idea. I have certainly had a few managers that felt that way, but I’ve also had success over time in changing their minds a bit. I’ve been able to get them to give me the chance to pilot ideas in a small way. Sometimes it’s taken years, but I’ve learned to play “long ball” and think about succeeding over time, not getting my way this week.

    One of the ways you can convince someone to give you a chance is to continue to show other examples of success from other companies. Nordstrom’s, not necessarily the place you’d expect to see IT innovation, has a video of how their lab enables them to build better applications. It might be worth saving this link, and even sending it to your boss with a proposal.

    If your boss is supportive, ask for a week to work on a project with another person or two and spec something out in your proposal. If your boss is skeptical, ask for a few half days across a month to work on something and build some basic prototype project. Even if it’s mocked up on paper, you can show the value of how an idea might work. If you get some support from your end users and customers, you might find yourself with a fun project to work on in 2012.

    Steve Jones

    The Voice of the DBA Podcasts

  • Jacks of all trades

    I'm a jack of all trades at the ranch, but not in software.

    Does your envrionment look like the one at Instagram? I’d bet that you ha there are a few of you that have an applicaiton or two that contains as many servers, components, pieces and parts, all held together with the proverbial duct tape and baling twine. I think I’ve had a few environments that were close to this complicated, but in general I try to avoid this type of mish mosh of technologies tools and platforms.

    When I look at the SQLServerCentral architecture, while much smaller, still scales nicely on a single database server (clustered) and a web server. If I needed more performance, I’d hope that I could do something more similar to the setup at StackOverflow, with better development and fewer parts of my architecture than adding the type of complexity that powers Instagram.

    That’s not to say that one environment is better than the other. I know that the staff at Instagram is learning a lot about integrating disparate systems, building new tools that can better manage their environment. As I read through the list, I’m not sure it’s a lot different than some of the environments I’ve worked in. If I listed all the pieces of software I’ve used in some applications, it might be just as complex, though it didn’t feel that way at the time.

    I tend to prefer a simple environment, using as few pieces of software as necessary, but using the pieces that are appropriate for the job. Rather than build a complex XML processor, or fumble with XML in T-SQL, if I could buy a module that handled that function, I’d be happy to do so.

    Working in technology is about choices, making the build/buy decision over and over, on a regular basis, and making the best decisions we can.

    Steve Jones

    The Voice of the DBA Podcasts

  • Going Green in Software Development

    We use a little solar power at the ranch, making us a touch more "green"

    I am very interested in a better use of the electricity we use on this planet. I think energy production from non-fossil fuel sources will be important in the future, and I’m regularly examining the energy usage at my ranch, calculating the cost of wind, solar, and other energy production technologies to see if any of them are a good investment. I believe that our future will both require and consume more electrical energy. That’s fine, but I think that we ought to be looking to be more efficient in how we use energy, which will require an effort to build and use more efficient devices.

    Many authors write articles and speak about techniques that you can use to build more efficient applications. The most popular sessions given by speakers and requested by attendees are those that deal with improving performance. Writing better code, troubleshooting issues, and increasing the efficiency of our systems are under our control seem to be the priorities for most IT workers that I know. Every time we build something a little better, it’s a great win for the author.

    Intel published an interesting article that talks about the impact that writing better code might have on energy usage in applications. Computers use different amounts of energy under different loads. More intensive computations use more power than the idle thread that occupies the CPU during low usage periods. I don’t know how much power I’m using at my house for computing, but I plan on measuring it, especially after reading this post from someone that calculated his power consumption.

    Power is becoming a more of an issue for many data centers. The cost is rising and becoming a significant percentage of the total expense of operation. While data professionals tend to work on server systems, which share the load from many clients and might not have much idle time, there still could be room for improvement. Writing better, more efficient code that requires less reads, less CPU cycles, can end up reducing the cost of operation. Maybe that’s a reason to ask for a little larger training budget and learn how to write better, non-RBAR code (as Jeff Moden would say).

    Whether better code could save a significant amount of electricity is hard to know, but in most cases, it doesn’t take any more time or effort to write more efficient code than poor code: if you know how. You probably have plenty of reasons to learn to write better code, but here’s one more. Writing better code might help you feel a little more green.

    Steve Jones

    The Voice of the DBA Podcasts