8 New Year's Resolutions For Enterprise Developers
Every year around this time, people make stupid resolutions, such as, "Drink less coffee" or "Learn Esperanto." Here's a look at 8 New Year's resolutions that might do some serious good for enterprise software developers.
![](https://eu-images.contentstack.com/v3/assets/blt69509c9116440be8/blt3ff50b4555683687/64cb4261c9df9b357a8865e9/Image_1.jpg?width=700&auto=webp&quality=80&disable=upscale)
It's that time of the year again, time to look back on the old year and resolve to take steps to make the new one better. If your organization moved from waterfall development disciplines to an agile development methodology (or DevOps) in 2015, you're probably looking for steps to ease the transition.
That's because moving from waterfall development disciplines (where many of us learned how to do the whole "development thing") to agile or its successors can be hard on an organization. It's not that agile is bad (though you'll hear some people swear that it is), but that agile is so very different. Different is difficult when human beings are involved.
To help you get past the "difficult," I have some suggestions for New Year's resolutions that might help. Some of these are simple -- spend a little time reading, and you can cross a successfully completed resolution off your list. Others are more difficult, largely because they involve other people. But you can always look back at those resolutions you've completed for encouragement.
[See Top Priorities For State CIOs In 2016.]
Every organization and situation is unique, but these resolutions can apply to many different sets of issues. Even if you think you're farther along the path than the point where these resolutions would seem to apply, going back to revisit the basics can be a good refresher before moving to more advanced topics.
Where are you and your organization on the path to agile? Is everyone embracing the new discipline? Are you taking the next step into DevOps? Or is your organization still chasing waterfalls? Let me know. I'd love to understand where you are so I can fulfill one of my resolutions for the coming year: To bring more valuable stories (in print and on the radio) about enterprise development to InformationWeek for our readers.
So, let me know about your experience in enterprise development -- and what you want to hear about more often. 2015 has been a most interesting year and I'm looking forward to a 2016 that is no less exciting, but far less stressful for all of us. (Hey, I can dream, can't I?)
**Elite 100 2016: DEADLINE EXTENDED TO JAN. 15, 2016** There's still time to be a part of the prestigious InformationWeek Elite 100! Submit your company's application by Jan. 15, 2016. You'll find instructions and a submission form here: InformationWeek's Elite 100 2016.
I hate to recommend that you read anything labeled a "manifesto," but if you're going to embrace and use Agile development, you really should know what it's all about. For that, you need to start with "The Agile Manifesto." Don't worry, it's short -- you can probably knock this one off your list in less time it would take to watch the entire Tournament of Roses Parade. But you really should go at least a little deeper. Take the time to read "The Principles Behind the Agile Manifesto" as well. These principles really explain what it means to use Agile development and they deserve to be read, and understood, by everyone trying to be agile.
Every computer language carries with it a set of assumptions about how computers should be controlled and about the most logical way to make that control happen. When you learn a new language, you gain some additional insight into how applications can be built and structured. And new insight is good. Now, your new language doesn't have to be the latest on the scene. If you never bothered to pick up Ruby or Java, then put it on your list. You can even go old-school and learn the Cobol or Fortran they didn't teach you at university. Just learn something new. Especially if you're an executive who doesn't write code as part of your daily work. You, and your staff, will be glad you did.
I'm not suggesting you download a new app to get you through another boring meeting. Pick up a board or card game and have a game lunch with your team. This is a resolution that comes from personal experience. A long time ago, I managed a software team that was regularly tasked with rather ridiculous jobs. At least once a week we sat down together to eat lunch and run through a session of Trivial Pursuit. I can't tell you how many seemingly intractable technical problems were solved between the third and fourth pie slices in a game. If you don't like trivia, pick something else. Allow me to suggest Killer Bunnies and the Quest for the Magic Carrot as a good starting point. If that doesn't crank your tractor, then Munchkin Deluxe is a good alternative. In any case, get together, talk, and play a game. Your work will benefit.
You don't have to write code in Python to benefit from the philosophy behind the language's development. If you want to improve the code you write, read The Zen of Python. If you want your team's code to be better, have everyone read it. It's short and to the point, and it encapsulates many of the principles that development projects should use. If you read this and the principles behind "The Agile Manifesto," you'll have many of the tools you need to make your applications better.
It seems like the world of the mainframe and the world of DevOps are diametrically opposed. Mainframe development tends to be based on the waterfall method, with priority given to slow, cautious release schedules that give precedence to maintenance over innovation. There's no question that many mainframe shops are now working to incorporate Agile methodologies into their development practice.
The truth is, though, that even the most thoroughly Agile shop can learn a lot from the old mainframe guys. Here's a big one: Decades of maintaining code means that they know what works and what doesn't for the business as a whole. There are other lessons to learn, but first you have to be willing to look. Take that deep look and see which lessons you can learn and bring into your Agile world to make it even better.
(Image via vintageprintable.com)
The problem with the cloud is that there are pieces you don't control. The virtue is that function and operation are tied so closely that one disappears into the other. For DevOps, too, application function and operation are one and the same. That means that there are lessons you can learn from cloud providers and lessons you must learn to take your DevOps into the cloud.
Despite those who say that everything should be controlled and maintained inside the enterprise, cloud services make too much sense for most of us to ignore. Make studying the cloud part of your practice for the new year and get ready for your applications to improve with each lesson you learn.
When I talk to CIOs and IT executives, they tell me that changing a team's culture to embrace Agile and DevOps is much more difficult than anything that happens on the tool and technical side. The hardest thing is rooting out the last pockets of waterfall development for projects where people think Agile doesn't make sense.
If you're going Agile, go all the way. Convince the naysayers, prove your point with successful rolling releases, and be prepared to provide good references and employment assistance to those who refuse to make the jump. Life is hard enough when everyone is working together. You can't win when you're trying to manage multiple cultures.
Of the executives I've talked to, the ones who consider their shift to Agile most successful point out the fact that it's not just something for their software developers. Their whole organization has gone Agile. When these executives talk about the impact of Agile accounting, marketing, and even HR, they tell stories of companies that have been completely transformed for the better.
So, spread the word. Let your colleagues in other departments know what great results you're getting. Pay special attention to marketing. In many companies they spend more on IT than you do, so they really should be part of the Agile culture. Everyone will be annoyed with you for proselytizing, then they'll thank you for making their operation better.
Those are my suggestions. What are your resolutions for the coming year? I've got some ideas for things that will make my work better and make me happier. Meet me in the comments and I'll share.
Of the executives I've talked to, the ones who consider their shift to Agile most successful point out the fact that it's not just something for their software developers. Their whole organization has gone Agile. When these executives talk about the impact of Agile accounting, marketing, and even HR, they tell stories of companies that have been completely transformed for the better.
So, spread the word. Let your colleagues in other departments know what great results you're getting. Pay special attention to marketing. In many companies they spend more on IT than you do, so they really should be part of the Agile culture. Everyone will be annoyed with you for proselytizing, then they'll thank you for making their operation better.
Those are my suggestions. What are your resolutions for the coming year? I've got some ideas for things that will make my work better and make me happier. Meet me in the comments and I'll share.
-
About the Author(s)
You May Also Like