Dev of the Week: Jim Bird
Join the DZone community and get the full member experience.Join For Free
- Agile Development Leads to Alzheimer's
- Maintaining Software Sucks – and What We Can Do About It
- Design Patterns after Design is Done
Thanks for talking to us, Jim! What have you been working on lately?
We're rolling out a major hardware upgrade, so my focus today is about getting developers, testers and ops working together really closely, and lots and lots of operational reviews and testing to make sure we've got all of the details covered.
You blog a lot about Agile development. What, to you, is the most important Agile principle?
Whether you're doing Scrum, XP, Kanban, Continuous Delivery, Continuous Deployment, or whatever, it all starts with breaking work down into small pieces and delivering more often. Once you decide to work this way, everything changes because it has to in order to keep up with the faster pace. People have to communicate more and more often with each other and with the customer and with ops. You have to automate more, especially testing and deployment. You have to change the way that you manage people, the way that you plan, and the way that you manage risks. Even the way that your organization is structured will change or should change. Agility - in the way that people think and work - comes out of working smaller and faster.
Are there any particular developer tools or resources you couldn't live without?
Too many programmers today are still not taking advantage of static analysis tools to help them catch coding mistakes and poorly-written code. If you're programming in Java, at least try Findbugs, or, better, something like Sonar, which integrates Findbugs and a bunch of other static analysis tools like PMD etc. These tools - and the fancier and more expensive commercial products like Coverity, Klocwork or Fortify - catch real coding problems that are hard to find in testing or even code reviews or pairing, and they are easy to use and integrate. It doesn't make sense not to use them.
Do you have a favorite open source project (or projects) that you've contributed to recently?
I care a lot about how software should be designed and built and especially about how to design and build secure and resilient software. I contribute where I can to OWASP projects such as the Cheat Sheet series, which is one of the best resources for developers who want to understand more about application security problems and how to build secure software.
Do you follow any blogs or Twitter feeds that you would recommend to developers?
Besides what you can find on DZone of course, there are a few blogs that I follow regularly. If you really care about writing good code, check out Michael Feathers' blog. I am really looking forward to his next book on Brutal Refactoring. Developers need to understand more about DevOps, and one of the best people to learn DevOps from is John Allspaw at Etsy - check out his blog Kitchen Soap. He is one of the deepest thinkers in this area, and one of the most pragmatic.
For advice on leading developers, I like Rands in Repose.
I don't always agree with everything these guys write, but they are smart and have a lot of experience and are worth following.
Did you have a coding first love -- a particular program, gadget, game or language that set you on the path to life as a developer?
I spend a lot of time managing technical and business issues today so I haven't coded in a while. I got into coding accidentally a long time ago. I started working in ops, and had problems with some of the tools that we were using. So I got out manuals for the compilers and debugger, and taught myself how to program so I could fix what we had and write some better tools. Then I decided to go to school to learn how to do this properly. I've programmed in a lot of languages, and I'm probably one of only a handful of people in the world who ever worked in a cool language called SPLash!, which was used back in the 90s to bridge system programming tools on HP hardware.
Opinions expressed by DZone contributors are their own.