In this episode of 30 minutes with Servoy we discuss best practices of saving data.
In this episode of 30 minutes with Servoy we discuss best practices of saving data.
Tech webinar series with Servoy. 30 minutes on Servoy related topics. In this session ChartJS for Servoy, a new component with a brief overview how to use and where to download it.
We are excited to invite you to join us for this webinar, announcing a new, open-source module svyDataBroadcaster.
If you have multiple applications connecting to a database, then you probably face the challenge of keeping a uniform view of the data. Please join us for this 30-minute technical webinar and learn best practices for a multi-application environment and how to incorporate this new module into your applications.
In this second part of the tech webinar series 30 minutes with Servoy we look at four new free web components for Servoy NG Client: Sidenav, Select2, Google maps and PDFViewer.
The svySearch module gives you a powerful and user-friendly search in your Servoy applications. Because of it’s API you can easily implement it both in new and in existing Servoy applications. And it’s free and open source!
Join Ken Levy, former product manager of FoxPro and Sean Devlin, senior engineer at Servoy for this demo because you owe it to yourself to learn more about this great natural successor to Visual FoxPro.
Canadian ERP vendor moves from FoxPro to Servoy to build revolutionary new solution
Jonar has been making enterprise resource planning software (ERPs) for the Canadian garment and textile industry since 1986. Following a recent change of management, the company reviewed its customers’ needs and long-term road map. Jonar wanted to design ERP software that provides a stellar user experience (UX) and removes user frustration.
For Jonar, the only way to make ERPs better was to create a brand-new product that was nonthreatening, uncluttered and easy to use. The company conducted in-depth research into skeuomorphism, saliency and context-based design to conceive a flawlessly functional solution with a clean interface and minimal training requirements.
Having honed its vision for a revolutionary new ERP, Jonar needed an integrated development environment (IDE) to enable that vision. Jonar was sensitive to vendor lock-in and diverging interests. FoxPro, Jonar’s previous programming tool, had been deprecated by Microsoft.
Requirements for a new rapid application development platform included:
Jonar tested multiple IDEs, which tended to fit into two categories: they either performed tasks well but scaled poorly or they offered the required horsepower but lacked a flexible enough tool set to execute Jonar’s vision. Only two products could deliver on both fronts.
Ultimately, Jonar chose Servoy because:
Additionally, as a company Servoy:
Jonar found Servoy easy to learn thanks to its use of a 4GL. For example, Jonar’s UX design team is made up of designers—not software engineers—yet they were able to work on fine-tuning user interface details after only a day and a half of training.
The first six months of the project consisted of rapid prototyping using the Servoy platform. Jonar’s engineering team relied on the framework to cut development time. Servoy suggested other time-saving devices such as a scrum methodology, a high-fidelity collaborative mock-up tool and test-driven development.
“Servoy recommended that we build 80% of what we wanted and then work on improving it, instead of chasing a theoretically perfect model,” comments Jon Ruby, Managing Director of Jonar. “They saved us from falling into a rabbit hole that might have wasted years.”
As the Jonar team grew more proficient, it removed optional framework components to further optimize performance. As soon as clients were willing to pay for the new ERP, a soft launch ensued. A backlog of potential customers soon developed.
“Servoy gave us a springboard to develop our product,” reports Ruby. “It normally takes six to nine years to build an ERP from scratch. With Servoy, we did it in a little over two years and with a much smaller team. By vastly accelerating the speed to market, Servoy helped us slash our development costs.”
“Clients love the new user experience,” notes Ruby. “Previously, we approached two or three leads per month, of which 50% would convert within six months. Now, 20 potential customers contact us every month, of which 80% sign up immediately. The sales team hasn’t made a single cold call since the new ERP launched.”
Jonar has expanded its customer base from Canadian only to clients all over the world. The company is also reaching new industries, thanks to its highly flexible ERP. Customers look for software that is specific to their business. Jonar is able to customize its product in a matter of minutes and offer clients exactly what they want. The company has successfully demonstrated that ERPs can be powerful and simple to use if they are well-designed.
That Jonar’s trailblazing new solution was built using Servoy should be credit enough. However, Ruby has equal praise for the support his company received. “Bouncing ideas off the Servoy team was invaluable,” he says. “A conversation would turn into a milestone from which the project would accelerate further still. I also agree with the direction they are taking with successive versions of the Servoy platform, based on customer feedback. They understand that our success is their success. They take us seriously and treat us like partners.”
EuroCloud is organizing the event ‘Show your Cloud’ on a regular basis. This time Servoy is hosting the event and a couple of Servoy customers will be presenting about their Cloud experiences. We invite you to join this 2 hour event at our new offices in Amsterdam.
We are proud to announce that we are a gold sponsor at the EMEA PUG (Progress User Group Europe conference) in Copenhagen on November 4-6. We will be speaking about modernizing Progress applications. Join us if you are interested in creating a modern User Experience for your Progress application with very little effort.
We will also be exhibiting in the sponsor area, if you would like to meet us or to learn more just step by our booth. We’re also handing out some nice goodies if you drop by!
Greece begging on its knees for another bailout? The Everest-size mountain of the United States national debt? The horror of losing your home and car to creditors?
Most people think debt is bad. But that’s not always true.
Properly managed, technical debt is a hallmark of optimal software development.
It is something everyone ought to be familiar with.
The tug-of-war between features and maintenance
At the heart of every software publisher, there is a conflict between the need for new features to sell and the need to make sure the software works.
If you’ve been working for some time, you’ve probably come across two types of companies.
In a commercially dominated firm, the sales team sells tomorrow’s features and the engineering team is playing catch-up. As code maintenance falls behind, quality deteriorates, exposing the product to performance, scalability or security issues.
In a technically focused company, everyone dreams of creating the next Facebook. The engineering team won’t release the software until it meets lofty technical goals. With no product to sell, the company risks running out of money before its first release.
Thankfully, it is possible to find a happy medium. And this is where technical debt comes into play.
The mechanism of technical debt in agile development
Agile methods consist of short sprints that produce working software to show customers.
In a sprint of, say, a couple of weeks, there isn’t time to introduce new features and tie up all the loose ends. Corners must be cut.
Technical debt is the concerted decision to cut those corners and the documented number of “story points” required to fix the software.
For example, the sales team may ask to include a new feature in the next sprint in order to win a customer. The engineering team responds by building the feature in a fraction of the time it requires.
Once the new customer is on board, the engineering team can spend time rewriting the feature correctly and repaying the technical debt.
Conversely, the engineering team may devote an entire sprint to repaying accumulated debt to avoid serious issues down the line.
Because the consequences of ignoring the debt are clearly explained in the sprint backlog, the sales team can accept the absence of new features in the current release cycle.
As we can see, technical debt is flexible and constantly evolving. Small amounts of debt are accepted in the current sprint and eliminated in the next.
It’s up to the company to decide how to allocate development time. For example, 40% may be invested in new features, 20% in customer-specific requirements and the balance to repay technical debt.
Benefits of technical debt
Technical debt acknowledges the company’s need to satisfy customers. It also encourages the engineering team to explain in layman’s terms the reasons why the debt should be repaid.
Instead of a tug-of-war between conflicting interests, technical debt brings transparency and consensus to the software development process.
The engineering team gains in respect—and job satisfaction—because others in the company see the value of its work.
How about you?
Are you familiar with technical debt? Do you think it could help your company work better?
Let us know in the comments below.