5 things to know about software development in 2016

These are the things that are changing software development.

By Rachel Roumeliotis
January 4, 2016
Focus sign Focus sign (source: Bart Everson via Flickr)

Get the O’Reilly Programming Newsletter and receive weekly programming news and insights from industry insiders. The following piece was first published in the Programming newsletter.

Know all the things? No way! Here’s the important stuff.

Learn faster. Dig deeper. See farther.

Join the O'Reilly online learning platform. Get a free trial today and find answers on the fly, or master something new and useful.

Learn more

How many software developers are there? Millions! And, I’m guessing you are one if you are reading this. Well, the tricky part about picking five things to focus on is that there are so many different kinds of you working on so many different projects, from mobile apps, to killer databases and IOT gadgets, to large infrastructure. What you’ll read here is my take on the things that are changing what it means to be a part of software development. Enjoy the following and let me know what else you think is going to be important in 2016.

1. Versatile and modular architectures gain momentum

Dare I ask, have you heard of microservices? (If not, Martin Fowler breaks it down for you.) Some folks think that it’s just a new name for service-oriented architectures (not I). No longer must software architectures be monolithic structures that need to be patched and built onto at your peril. Microservices break your architecture down into smaller, independent applications that can be continuously upgraded, switched out, and optimized. For instance, when one piece of your system is being taxed, you can focus on shoring up its performance while the other pieces chill out. Now, microservices are not the answer in every case. I expect the monolith to be around for a long time, as it can be the right approach. But this year, it is very much worth your time to check out if microservices make sense for your company.

Check out Building Microservices and The Principles of Microservices for some guidance from Sam Newman or if you are just starting out, come to Mark Richards’ Software Architecture: From Developer to Architect Training.

2. The continuous delivery and deployment revolution continues

Some people believe that microservices are the first ‘DevOps’ architecture. I agree, but the revolution of DevOps goes far beyond a new architecture. It has been and will continue to be a game-changer for everyone who develops software, from system administrators to software engineers. From Chef to Kubernetes, a bevy of new tools to release, monitor, and optimize software apps has landed. And, if shipping software early and often is the new normal, then everyone from the team leader to the release engineer is affected. In fact, the line between development and operations has effectively been smudged beyond recognition. In my view, this is all great news—software doesn’t have to be static, it can continue to improve (and is even expected to) and there is an infrastructure in place to make it so. What used to be a buzzword—DevOps—is now a reality, albeit one that is still being tuned and refined. If you haven’t already, look into what this means for how your team is structured and how you can pick the best tools for you.

Check out Effective DevOps, Kubernetes: Up and Running, and Programming for SysAdmins.

3. Software development influences the entire company

Software developers do so much more than develop software. They can be responsible for many things:

  • Understanding customer needs
  • Generating revenue via app sales
  • Creating the face of the company via a website
  • Facilitating delivery of content to millions of individuals
  • Keeping identities safe
  • Making sure hardware works every time

I could go on, but the point I’m making here is not that you are the center of the world, but that your work is central to pretty much everything your organization does. Creating software of any kind goes far beyond making sure the perfect Python code gets written (though that’s critical!). It means crafting a product that solves a problem, answers a need, or facilitates a service. Understanding and contributing to the design, development, and deployment of software that truly succeeds for users is much more involved and powerful than simply writing code. Step up to that leadership position this year.

Check out Hello, Startup and Beyond Blame for insight beyond coding.

4. The care and feeding of sustainable open source projects

Something I’ll be thinking a lot about this year is—what happens now that open source has become ubiquitous? Almost all software languages, frameworks, etc. are open source, so do we just let up on the gas? After speaking with people who’ve been with open source since the beginning, as well as those new to it, it’s clear that we can’t just say “Mission Accomplished.” We need to continue to nourish this community, define how both individuals and enterprises can best contribute and collaborate, and respond to changes in the technology environment that impact how open source software is developed and maintained.

Check out these free reports as a starting place for some good debate.

5. Keep a good balance—The New Shiny vs. Tried and True

Here at O’Reilly we get very excited and carried away at times, frankly, with “The New Shiny.” The idea of an emerging language, to me, is just so cool. I think about how it reflects the world of programming today like Java and others never could.

On the flip side, I love to think about how developers deal with legacy software: when to upgrade; considering if the COBOL code is ok as is; etc. I was talking with someone recently who said that NASA uses older software architecture because, when you are drifting past Pluto you either work or you don’t—and well, we now have great pictures of Pluto. My point here—we will always have lots of “New Shiny” techniques, frameworks, languages, etc., but don’t forget about the old standbys and how they can solve your problems just as well, if not better, at times.

Dan McKinley participated in an online conference we did this past summer where he speaks to this point very well with “Choose Boring Technology“—take a listen.

Post topics: Software Engineering