I just spent the day at Progress Software's annual analyst day. The highlight of the event is, always, to hear from their customers about how they are getting real things done. This year we heard from: EMC, Sallie Mae, TD Securities, Royal Dikzwager, BT Global Services, Lincoln Financial Group, Sabre Holdings, and Fiserv.
The theme: High velocity business demands high velocity technologies such as complex event processing, enterprise infrastructure, data infrastrcuture, and others.
But, this post is about Kenneth Rugg, VP and GM of Integration Infrastrcuture for Progress Software, comments on open source software.
Many years ago as I started researching and analyzing the differences between major BI vendors, one criterion that I always used was whether these vendors ate their own dog food. In other words, did a vendor executive team use the same solutions for data collection, building metrics and dashboards to run their own companies that they also tried to sell to their clients? Those who did tended to score higher in my evaluations.
The same guiding principle is applicable to Forrester: you have to eat your own dog food in order to convince the clients to buy your products and services. Hence, our methodologies, such as Forrester Waves are completely open and transparent (thank you, Doug Henschen, for recognizing this in your recent blog), and we encourage our clients to challenge us on every point made in our Waves.
During the last three months I have been talking to many people on what a software development process looks like to them in the 21st century — you have seen some of the initial thoughts and ideas posted in this blog. The community seems full of different views as to what makes a process, or even if process, as we currently think of it, is right for software development teams.
It is clear that software development is NOT the same as other manufacturing processes, and that organizations that approach software development in that manner do not exploit the opportunity for innovation or develop an efficient process.
In the pursuit of building better software, it has always been the belief of most senior managers that if you have a good process you will get great software; that problems with software can be attributed to problems with process. Many people are now questioning that traditional mindset, believing that changing the tasks, work products, and responsibilities within the process does not lead to success, but a focus on culture, knowledge, and skills will instead improve the end product. This change in emphasis is embodied by the Agile methods movement and described nicely in one principle in the Agile manifesto ‘Individuals and interactions over process and tools’.