How PacketTrap developed its new network management tool

Justin James recently spoke with PacketTrap CTO Sal Sferlazza about the challenges and successes of developing the company's new slick network management tool. Justin learned about their programming languages of choice, their approach for recruiting developers in San Francisco, and more.

After checking out the demo of PacketTrap's pt360 Tool Suite, I was really curious to find out how they developed this application. Fortunately, on Jan. 17, 2008, I had the pleasure of talking with PacketTrap CTO Sal Sferlazza to hear about the project's behind the scenes work. Sal revealed the challenges and successes of developing this slick network management tool. (Be sure to read Cisco expert David Davis' rave review of pt360.)

Development methodology The PacketTrap team used a series of rapid prototypes to allow them to get to market quicker. Sal explained that they focused on putting together a solid framework and architecture because it would be easier to make changes down the road if necessary. In hindsight, he feels like this approach was definitely the right way to go. Language choice

The PacketTrap team uses a mixture of C++ and C#. Sal says that C++ is needed right now because it allows them to get the performance they require. The language choice has worked out well for PacketTrap. From what I saw in PacketTrap's demo, the pt360 is fast -- even when handling a large number of devices.

Developers The typical developer on their team has 10 - 15 years of experience. Some of the developers are people that Sal worked with at other companies, but the bulk of PacketTrap's recruitment efforts are done through Craigslist. Recruiting for developers with this mix of skills is a challenge in San Francisco. Sal says that Craigslist is a great tool for recruiting in the area due to the penetration of Craigslist in that market. Biggest challenge

The abstraction of devices was the team's biggest challenge. From what I've seen, the PacketTrap software (at the user level) seems to have this nailed really well; entirely different devices in the same class (routers, switches, etc.) all get represented in the same manner and can be treated the same by the user. From my experience with networks, this is important because the NOC cares a lot more about device type than the actual make or model. A router is a router is a router from the standpoint of monitoring and measuring the impact of service problems.

Biggest regret

Early in the project, they used third-party network controls that they later regretted. During their prototyping, they wasted a lot of time and money with these controls that just were not capable of the level of performance that they required. (Sal, the consummate professional, declined to "name names.")

On the flip side, they learned a lot about allowing the customer to drive the project. Most of their competitors are not customer driven (I can attest to that), particularly in the UI portion of the application. Most of the products in the space are legacy systems that organically grew into the tools they are today, so they lack a focus on the user.

From speaking to Sal and others at PacketTrap, I was impressed by their intense customer focus, which reminded me of my discussions with Scott Abel of Spiceworks. When I mentioned this connection to the PacketTrap team, they told me that they have a great deal of respect for Spiceworks' product and the way they do business.


Network monitoring and management software is extremely intensive when it comes to juggling a lot of threads. After all, with hundreds of devices to keep tabs on, many devices require frequent checking -- your software can't allow itself to be hung up on one device that is timing out. The PacketTrap software adjusts its use of threading based upon the operating system it is installed on, which is why using C++ is so important to the development team. C# is simply too abstract, which doesn't allow them the precise level of control they require. They also perform a lot of caching to improve performance and reduce chatter.

Lessons from a successful team

I really enjoyed talking with Sal. It's always a delight to hear from someone who is successfully running a development team. All too often, we focus on the Dilbert nightmare stories about the IT industry, so it's refreshing to have learned more about a development team that is working hard and getting great results.