Tag: software

What’s the state of software in 2014? Here’s one set of thoughts from Tim Bray. He works for Google, and understandably has a bit of a slant towards the Google view of the world. Or maybe that’s his view and that’s why he works at Google. I am never quite sure how many people choose jobs or employers that fit them and how many get sucked into thinking a certain way because they fell into the job.

In any case, I think that the state of software in 2014 hasn’t dramatically changed from the last decade. We’ve seen a push towards the idea of “apps” in mobile/tablet spaces, and now that’s coming into the desktop/laptop space as well. Even Google, with the Chromebooks and apps in their own browser store, has been pushing the idea of a store with a curated distribution of software. However I think it’s still a fad, with most people preferring desktop versions, or browser based versions, of the software they need. As users mature and become more savvy, I do think the distinction between how we get our software matters less and less.

Are we writing better software? I see lots more experimentation, which is good. Some people love Javascript, I mean really love it. Others hate it, as Mr. Bray does. Flash seems to be fading, along the same way that Cold Fusion, Foxpro, and VB6 have gone away. I rarely hear about Java these days, though it seems that C, C++, Java, and Obj-C are still very popular. They don’t seem to have the media attention or excitement that I hear about with Python and Ruby, but there are lots of people still using them.

Interestingly enough, T-SQL is one of the most popular languages. That’s good for us, though I suspect if we included PL/SQL and other variants, SQL might be one of the most used languages. It seems like most developers need to use some SQL, though surprisingly most don’t work on those skills. As Mr. Bray mentioned, I do think that relational databases are here to stay. They work well, and they will continue to be used, but we’ll also see other types of databases being incorporated more and more into applications. If for no other reasons than because developers get excited by them and want to try out new ideas.

I can appreciate the view from a programmer used to having the power of thousands (or tens of thousands) of machines available that mobile hardware sucks. In comparison to what we have in a laptop, yes. However the ability to play a game, or edit a spreadsheet, or work with a visualization while walking down the sidewalk is stunning. We’ve just started to scratch the value of mobile, and while there are constraints (not to mention extra work to get your software onto all platforms), it’s also stunning to see how much computing can happen in the palm of my hand. I predict mobile is still exploding from its Big Bang. It’s up to technologists to work on solutions to the constraints in mobile, not complain about the frustrations of building software for mobile devices.

I think software is continuing to evolve and change, and while it hasn’t changed dramatically (to me) in the last few years, it’s still one of the more exciting industries to be a part of.

Steve Jones

This editorial was originally published on May 18, 2009. It is being re-run as Steve is on vacation.

Software is a very interesting business. Where else can you produce a product that has zero marginal costs for additional units? Where else can you force a “maintenance” charge on your product? What other product must continue to be improved upon by the manufacturer after it’s sold?

There actually are other industries for all of these cases, but they’re not numerous, and they differ from software. The business of building and selling software is fascinating, and I’m always learning more about it. I constantly see great questions in the forums at the Business of Software social network site. I’ll also plug the Business of Software 2009 Conference; if you’re a software person, consider attending this event. I went last year and found it very stimulating and educational, forcing me to think a lot about how that industry works.

I happen to work for a software vendor now, Red Gate software, and I used to work for another, JD Edwards. I wasn’t a part of the development or sales in either company, but I did get to talk to people that were, and learned a bit the business. And so when I saw thisopen letter to Oracle,  it struck a bit of a chord.

I’m not sure how software maintenance evolved to where it is today, but I think requiring it on a regular basis is an antiquated way of doing business. Microsoft doesn’t do it, though many third party vendors that work with Microsoft product do.  However I’m not sure that it’s really a value proposition for most customers.

At least not if the software is written well. It’s a piece of junk, maybe that maintenance is required.

I think that maintenance should be an optional part of the product, and that should fund support efforts, not a rolling cash cow to build the next version of your product. Sales fund that, or I think they should.

Steve Jones

The Voice of the DBA Podcasts

The podcast feeds are available atsqlservercentral.mevio.com. Comments are definitely appreciated and wanted, and you can get feeds from there.

You can also follow Steve Jones on Twitter:

Overall RSS Feed:  or now on iTunes! 

• Windows Media Podcast – 20.6MB WMV 
• iPod Video Podcast – 19.8MB MP4 
• MP3 Audio Podcast – 4.0MB 

Today’s 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.

Software development can be a complicated dance. Most of us do not work for a software vendor and don’t have the strict requirements for our deployments when we control the client systems. That doesn’t mean it’s easier for us, especially as our environments grow more complex and the availability of our systems becomes more important. Application changes can become disconnected from the database changes, especially when the scope or scale of the change is large, which can present problems.

Making database changes can be challenging since we must ensure that our data is not lost as objects are altered. We have to ensure that any application functions that depend on a certain schema receive the data they need, without unnecessary errors. The timing of changes becomes more important in the database than in applications in many situations. This Friday I am curious how many of you decide to stage these changes in your environment. If you have dependent changes, I’m wondering if you might alter the database first and change the application in a later deployment.

How many of you deploy database changes before code changes?

By “before” I mean you deploy the database changes, possibly making some application changes, but there are other code changes deferred for a separate deployment at a later time. The use of views, defaults, optional parameters and more allow database changes to proceed without accompanying application changes. It may require a bit more work, but the database can potentially be changed during a less busy time, even if development or testing for the all the application changes is not complete.

The future will require more availability and stability from our systems as they become more essential to our organizations. Learning to update software, and databases, with minimal disruption is a skill that will set you apart in the future.

Steve Jones

The Voice of the DBA Podcasts

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

• Watch the Windows Media Podcast – 21.5MB WMV 
• Watch the iPod Video Podcast – 18.6MB MP4 
• Listen to the MP3 Audio Podcast – 3.8MB MP3