The “accidental system administrator” is one of the most popular columns I have ever written. In that article, I talked about becoming an accidental system administrator — how over the years I had gradually become the go-to person for server and network issues in the company.
There is another trend I want to cover this month, and that is the fact that many media companies have developed small software development shops within their engineering departments. This is good and bad. The good part is that adding the ability to write code to support media operations has become a core capability for many of us. The bad part is, as with the accidental system administrator, it is a role we take on out of necessity, and many of us, myself included, have never really worked in a small software development shop where best practices were being used.
I thought it would be useful to look at small-shop best practices, so I asked three of the most talented software architects I know — Jim Trainor at Trainor Engineering, Dan Shockley at Turner Broadcasting System and Richard Cartright at Quantel — to give me their advice for those who find themselves in a small software shop. The sidebars below and on page 20 summarize what they said.
Agile
Agile software development is an extremely popular method for developing software. It establishes specific roles for people during development, makes it clear who is responsible for which decisions, enforces good communication within teams and helps mitigate the feeling that many of us have that we have to get it absolutely perfect the first time. Agile is a great way to get stalled projects moving, and it is also a great way to allow team managers and business managers gauge the progress or lack of progress a team is making.
It can take time and training to properly implement agile in your shop. It does have overhead, and it is not the right solution for every situation. Plus, many people equate agile with iteration. Iteration is just one component of the agile process, albeit an important one. Iterating your code allows you to get software out there that delivers “a unit of business value,” meaning that the release does something positive for the business. So you do not have to do everything prior to getting value out of the time you have spent developing the code. But if you iterate your code and think you are doing Agile, you are missing out on a lot of the value that the framework can bring to your shop and to your business.
Software patterns
Look for software patterns. Software patterns are practices that have been tried in the past and worked well. The sidebar on page 18 lists some good patterns.
And, of course, there are specific software coding practices that work well too. Look for practices that work well in your organization, and actively seek to repeat them.
Not only should you look for software patterns that are successful, you should also actively study anti-patterns. This helps you to avoid making mistakes — either making mistakes that others have made, or repeating mistakes you have made yourself. Studying failure can be very enlightening. The anti-pattern I see over and over is Watch Folders. I could write a whole article on why these are a bad idea, and perhaps one day I will.
Tools
The Open Source community is an absolutely invaluable resource for small software shops. Just about any tool you can imagine for the development, testing and deployment of code is available free of charge. (See http://sourceforge.net, for example). While you can pay a lot of money for commercial development tools, there is almost always a free tool available that will do the same thing. Check for Open Source tools that have a good following and are well supported, and then implement them.
Testing
As the testing comments in the sidebar on page 20 make clear, a critical step for any shop is testing your software. You could argue that if you cannot describe how you would automatically test your software, you do not know what your software is doing in the first place — a dangerous proposition for sure!
Sometimes we find ourselves doing jobs that are very different from what we originally signed up to do. And for some reason, broadcast engineering is one of those fields where this happens rather frequently. Think about your job. Think about the advice of these software experts. If you now find yourself in a situation where you are writing code for your company, or you are managing people who do, you can benefit from the wise council of these experts.
—Brad Gilmer is president of Gilmer & Associates, executive director of the AMWA and executive director of the VSF.
