How to Grow and Stay Agile – Part 2: Top 6 Software Development Decisions | Guest Blog Post | Dirk Paessler

15 Years of Continuous Improvement

When you are running your business based on a single software product, decisions about software development are as integral to your success as business decisions—in fact, they are directly related to your business. This is why the second part of this blog series about the inseparable connection between growth and agility focuses on the top 6 software development decisions we have taken in the last 15 years. These are the decisions that, in retrospect, we consider important—most of them didn’t feel so important at the time:

Decision 1: 21st Century Software Development

To grow your business, you have to stay agile—especially when it comes to your product. Developing software that really helps IT professionals to simplify their work requires us to adapt quickly to the challenges they face on a daily basis. For example, when a new security leak like Heartbleed or POODLE is discovered, we need to be able to release an update for PRTG with a fix for 150,000 installations in a few hours, not weeks. In addition to these hotfixes, we also build and test several new versions of PRTG per day and regularly deliver new versions to customers several times per week. Modern software development tactics like agile development and fully automated build and test and delivery processes are the key elements. It’s a well proven process, which has evolved over the years to keep up with changing requirements. Also it will continue to evolve in the future, thus it’s agile! Actually, we call it Paegile—but that’s going to be a blog article of its own…

 

Another aspect which adds agility to our software development is our “cloud first” approach. Whenever we create a new system or service, we consider using the cloud and SaaS (Software as a Service) solutions first. In most cases this approach scales better than in-house solutions and frees up development resources to further enhance our product, PRTG Network Monitor.

Decision 2: Continuous Rollout

Customers are accustomed to continuous update delivery with SaaS solutions. They are a simple and convenient way to always run the latest version of a service. Even though PRTG is run “on-premises” (i.e. within our customers’ networks), we adapted the concept to offer the advantages of continuous delivery to our users: We introduced continuous rollout in 2012 and since then our users receive new versions of PRTG, including new features and improvements, on a regular basis.

In 2012 we were early adopters for such a process. Nowadays even large vendors (e.g. Microsoft) have adapted this approach to update their operating systems—it’s state of the art today. For us as a software development company this means that instead of delivering just a few versions per year, with massive changes between them, we can be agile in our development process and can also test new code and new features before rolling them out to all servers.

 

Decision 3: No Custom Development, No OEMs

Yes, in the early years of our company, we did custom development on a project basis. At that time, we were young and needed the money to get started.

Custom development actually gave us quick money, but we also paid a price: massive delays in the development of our own product. However, about five years in, we realized that in the long run we will get more out of our work when we focus on our company and our own product. According to our calculations, this was also true if we charged our customers as much as €1,500 for a developer day. Since this discovery, we haven’t done any more custom development and all our energy that goes into PRTG can be used by 150,000 users every single day.

Decision 4: Don’t Talk About the Future

Planning software projects is hard. Too hard. Especially when you have to maintain and support a product consisting of two million lines of code, which is running at 150,000 customer sites, in a constantly evolving world of networks, at the same time. These are a lot of changes and variables we need to consider when planning the next steps for our product.

This is why we don’t talk about features or functions to the outside world before they are publicly visible in the Canary version, the daily build of our three release channels. Only at that point can we give a reliable estimate of when the feature will actually be available. This also lets us avoid getting our users’ hopes up too soon and then disappointing them if a promised feature gets delayed (or even cancelled) by evolutions we can’t foresee. The consequence is: We don’t have a (public) roadmap. We only sell what we have today—vaporware doesn’t help anyone and our goal is to simplify the daily work of our users.

Decision 5: Don’t Look at Competitors

At Paessler we have our own way of doing things. In every regard. This, of course, also relates to software development—we have 15 years of in-depth experience when it comes to monitoring, network protocols and APIs, plus all the tiny details in-between that you can’t learn from a course but have to learn through experience. This knowledge helps shape what PRTG can do for its users every day.

I know it’s tempting to keep track of what your competitors are up to in terms of products, user interfaces and strategy. We have found that this kind of competitor screening blurs your vision—and we don’t want to spoil our creativity. We would rather listen to our users and come up with our own vision for our product, concepts and user interface. The thing is, when everybody starts copying everybody else, then all products will be equally boring. You’re left with washed-out products with no “personality” or “excitement” for the user. Try to be bold, try to be unique—and find your own way.

Decision 6: What’s the Bang-for-the-Buck of New Features?

Our users (plus everyone working at Paessler) always have more feature requests and ideas than we can implement. It’s a matter of limited resources. That’s why we came up with a “bang-for-the-buck formula”, which allows us to evaluate incoming feature requests with the help of the following four parameters:

• Reach: How many of our license-holding customers will benefit from the new feature? How many have asked for it?
• Boah: How likely is it that those users will be impressed, happy, or relieved by this new feature?
• Pain²: How much pain would it be to the affected users to not have this new feature? This value is used squared in the following calculations, so a truly annoying problem is much more important than any nice-to-have boah effect item.
• Effort: How many days do our developers need to research, create, develop, test, and document the feature?

Our “formula” to calculate a “bang-for-the-buck” value is:

When someone suggests a feature that will be used by less than 1% of our customers, we turn that down immediately, even if an idea is very good. This helps us to focus on those features and improvements, which will help the highest percentage of our users make more of their work day.

Did you miss the first part of this blog series? Have a look at “How to Grow and Stay Agile – Part 1: Top 6 Business Decisions” >>