We first thought about a VoIP control panel for providers about two years ago. Everything started when we were contracted by one of our clients to implement a VoIP integration. Our client, a medium sized hosting company, wanted to expand its product line. They had requests for VoIP services from some of their clients and offering business communication services sounded like a very good business decision. After a lot of discussions with many companies, they were not able to find a solution to match their needs. Our customer didn’t want to come up with something extraordinary. They already had a successful business and they were not tempted to start a new business just to have problems.

After around a month of analysis, it was pretty clear that we must build a solution from scratch. We gather the requirements and come up with a proposal. Unfortunately the costs were too high for our client budget, and we had to drop the project.

In January 2005, we ran a project contest in our company. Basically everyone was able to register a project idea and the best two projects would have been presented to our investors. This would have been a very good opportunity to get the necessary founding. I entered the contest with a VoIP control panel for ISP/HSP. I had a lot of ideas for such a project, and it would have been quite fun to develop the first product of this kind. Some may not agree with the first project declaration. The truth is that I investigated all solutions on the market (and I still do this). Most of them are fundamentally wrong from the software engineering perspective. If someone is really interested I can detail why, but I guess that you must be a developer to see behind the marketing bullshit. An experienced engineer can only install the product and take a look to its architecture. And I did this with many products. I lost a lot of precious hours, but I was able to understand the market.

In our internal contest entered fourteen projects, most of them very interesting and with a lot of potential. I was very excited when I heard that our project won the first place and we will get the founding to make it real. This happened in March 2005. I gathered our team and informed them that we are going to start and bring to live the VoIP project. The development was happy and eager to start working to something new, where they could express themselves and innovate. I was also anxious to use our experience in server software in the new product design.

We started to refine requirements. This was pretty scary, because there were quite a lot. Soon it was obvious that the translation of these requirements into reality will be a challenge. In about two months, we had the requirements list approved, and we started to write the project specifications that addressed all the requirements. We adopted an iterative development lifecycle for the first version of the product. The project High Level Design was extremely difficult to define. During the first three months we realized better the amount of innovation present in the project and how different our product will be of what have been already done by other companies. We did not find many ideas on the market that could have been used ‘as is’. I am a perfectionist and all my colleagues have high standards. Many times we had to modify projects with poor design. The client comes with the code and we can not say no. But in the end a lot of projects are redesigned as this more cost efficient. We knew best what would happen if the project was not designed correctly. We knew that we will develop on the VoipNow the foundation for many years of development, so we proceeded with extreme care during the architecture design steps. BTW, I am sick of companies that announce on every new version a “product redesign”. And they are quite proud of this! Why redesign something if it has been correctly designed the first time? 🙂

I would love to detail more on the first months in the 4PSA VoipNow life, but I am afraid that no one will read on :). A common mistake made by many programmers is that they go into coding very fast. Many companies lack software engineering techniques and make this mistake on first projects. When the project costs increase, when they realize that developers do no longer understand the code, and if the company survives, they start to invest in engineering. It’s sad, but this is the real life scenario.

Well, after about three months we completed the design, the prototype was ready and everything was much clearer. It was obvious that the project presents many risks, and strategies were developed to address these risks. When everything was clear for the team and the initial training was completed, the programming of the first iteration was ready to start.

Although we are experienced developers, programming was not trivial. The configuration items were identified and kept under control. The project is highly modularized, which allows interventions without affecting other components. The most important components are the PHP interface, the C control binaries, the Asterisk applications and the Asterisk patches. The project is based on the Rack-Soft framework, a framework designed to increase the development performance, to address cross platform compatibility issues and to increase reliability. We use two frameworks for PHP and C, and both are in continuous development. This common framework allows us to port changes to active projects quite easily, to control problems and to standardize most operations.

In my next blog post I will tell you more about the product architecture and programming issue. I really don’t know what you want to find more, so please do not forget to send me your suggestions for the next post. Oh, do not hesitate to check the forum at https://forum.4psa.com.