Blog

I must admit I’ve been sadly lax in getting this blog rolling for articles and things other than announcements. I had a plan in mind of some topics I wanted to start out with, but you know what they say about the best laid plans. I’d been collecting topics for a while but intended to stick with the plan for starting out. Well, priorities shift often, and nearly two years later (!) I still hadn’t started. Sometimes topics would come up that I wanted to write about when they were timely, but by the time I’d get to it they wouldn’t be anymore. So I made it one of my New Year’s Resolutions this year to forget The Plan, which by now was getting in the way, and Just Do It. It’s with this in mind that I just had to share this little tale of current projects, and why you need MIB Smithy if you’re a MIB author.

MIB Smithy, as you may be aware, is our editor/compiler environment for SNMP MIBs. My goal in creating the product was to make it as easy as possible for novices to write MIBs, but thorough enough in checking and enforcing standards compliance and compatibility with other compilers that even staunch experts and purists, who wrote MIBs using text editors and command-line tools, to use. Such a tool would save developers a great deal of time and money through a little form-filling and point-and-click action to quickly generate fully standards-compliant MIBs rather than through manual editing and worrying about silly things like missing a comma or curly brace.

In this regard, I believe I succeeded in my goal, though I’m always looking for ways to improve upon it. There are over 650 validation checks based on calls to generate compiler messages alone, which doesn’t account for checks handled by a single function applied in multiple places (like all the checks done on all OIDs). I’m a fan of eating out own dog food, so when consulting clients ask me to design and implement MIBs for them, I use MIB Smithy myself to do so and save weeks of development time in the process, translating to less billable time for the client. I like to believe using MIB Smithy saves our users similar time and costs whenever they use it, allowing the software to quickly pay for itself many times over.

Flash back to 2001 for a moment when I started writing the software, with the core in C++ and GUI in Tcl/Tk. The standards compliance of C++ compilers, particularly Visual C++ 6.0, were abysmal. Much of the architecture of the C++ portion needed to be based on partially reinvented wheels because one couldn’t rely on a simple thing like a standard string class being portable between platforms and compilers, and I design for cross-platform support as a rule. As time went on, the “partially” aspect became more and more of an obstacle to implementing various plans for the product, much as the compilers once were.

C++ standards compliance in g++ and Visual C++ have both come a long way since then, as have open source cross-platform libraries for previously tedious things to implement. For the 4.0 SDK development branch, I decided it was time to uplift, refactor, and simplify the code to get rid of the maintenance cost of those tired old wheels. That was a rather large undertaking itself due to how deep and interconnected the dependencies ran. Unfortunately, back in 2001, I hadn’t yet picked up the habit of test driven development, which is the idea that you write unit tests before (or in parallel with) with the code you’re testing. I did later, which means there are a lot of automated regression tests for things like SDK APIs that came later, but there weren’t for core functionality like the MIB parser and validator, originally tested manually, that haven’t changed much–exactly the places with the most code changes now.

Recognizing the need to thoroughly check for regression issues before releasing the 4.0 SDK branch, I hired someone to tackle regression test automation for the parser (about 450 tests there), and I’m currently working on tests for those 650++ checks our compiler does. That means, essentially (and tediously), writing about 650 small MIB modules, by hand, intentionally broken in various ways that the MIB Smithy editor won’t let you (or will only let you because sometimes you need break something temporarily to remove a dependency or change a design). Therein lies the irony.

As a side benefit, I have in a few instances discovered some previously unknown bugs in the current stable branch and been able to fix them. But boy do I wish I could be eating our dog food right now. Don’t you? Why don’t you give MIB Smithy a try?

My apologies to any early subscribers who experienced oddities with the RSS feeds as past release notes were being moved into the blog. Now that that’s done, I wanted to take a moment to introduce myself welcome you to the new Muonics Blog.

My name is Michael Kirkham, and I am President & CEO of Muonics, Inc. I founded the company in 2002 after creating MIB Smithy, our flagship SNMP MIB Editor/Compiler product, in 2001.

I’ve been writing software for around 20 years now, particularly in the network management industry since 1995, when I began a 5-year stint as the principal developer for one of the industry’s leading SNMP agent compliance test suites. There I developed tests for several SNMP MIBs, and was as a contributing member of the SNMPv3 Working Group. Prior to 1995 I was an embedded systems developer writing firmware for RF devices, such as radios and power amplifiers, used in applications including coast guard, air traffic control, and semiconductor manufacture.

One of the things that I valued most about my prior career and working with others in the network management industry was close interaction with users, partnering with them to provide for their needs at an individual level, while keeping a broad perspective for the entire current (or future) user base. I see this as a bit of a hybrid approach, between custom and traditional shrink-wrap software development.

The problem with custom software is that it doesn’t scale well as a business: a custom solution that works great for one customer is not necessarily going to work well for another, and you’re back to square one with each; plus it’s very expensive. On the other hand, with traditional shrink-wrap software there’s usually a very large disconnect between the individual user and the programmers–with the publisher’s desire to maximize market share in between.

For me, it’s not enough to churn out features just so that I can put check marks next to a competitor’s check marks on comparison sheet in a game of follow the leader. It’s infinitely more rewarding and satisfying to work closely with users to determine what their real needs are, extrapolate, and over-deliver; to create new and better ways of approaching a problem than simply copying what’s been done before.

Truthfully, I haven’t felt as much of a connection with the users lately. Part of that is because I often don’t get to communicate with users unless there’s a problem, and of course I try to keep problems from occurring! While the evaluation downloads do currently ask for contact information, and I follow up personally to address any comments or check for problems, they don’t go on any mailing lists, and if I don’t hear back I don’t keep sending messages. If I get too far behind on followups, I make the safer assumption that you’d rather not be bothered if it’s no longer timely. Part it is also because systems that were in place, such getting releases announced and notes published, were cobbled together back in 2002 with an aim for function before optimization.

Like other knowledge workers, I’m prone to neglect tedious tasks. I’m all about workflow efficiency, so I’m very excited to have the new blog up and running. Not only has this reduced four painful parts of the release process to one pain-free task, sure to get done in a timely fashion, but it will give me a platform for offering tips and tutorials to those interested that were previously only in the realm of support inquiries. With much better systems in place, I expect you’ll see great improvements in communication from me in the future, and look forward to reestablishing those missed connections. With better communication from me, I hope to hear more from you about what I can do to help you succeed.

I’ve been collecting topics to write about for some time, particularly with regards to SNMP and using our products, but I’d love to hear your topic suggestions as well. You’re welcome to comment or send a note to support@muonics.com and I’ll put it on the list.

Thanks!