It’s been a year since we first launched the very first edition of the CPM Toolkit into the Java world. We had spent many months developing the Toolkit and were already using it for managing and measuring application performance during the development life cycle for our clients with great success.
One year after launching the CPM Toolkit we have learned some hard lessons.
In many ways we expected the market to be very much like DSI. Based on what we ‘read’ we expected Agile methodologies to be used everywhere and we expected processes such as continuous integration (CI) to be used just about everywhere serious Java code was cut. Boy, were we in for an education.
We noted that applications to support these fairly basic process automation activities were remarkably absent. Two thirds of organizations we spoke with do not use basic continuous integration tools and 40% do not use Java profiling tools. Indeed one industry colleague said that he thought global CI adoption in general was still in its infancy.
These are interesting statistics given that almost 100% of the people we spoke with understood that poor performance of critical applications means lost revenues, customer dissatisfaction and lost credibility for IT in the eyes of the business. So what are organizations about it? As they try to improve internal efficiencies and look to do more with less? Very little apparently. It’s not that they don’t care about it, all customers do, but it’s that they feel horribly challenged to try and get a handle around solving the process. This is where software process automation (of which CI and CPM play a vital part) kicks in and it can put a management and architecture back in control of their software – even if and maybe especially when it’s developed offshore.
In our discussions with people in the software development industry, we found that the most common issues driving organizations to software process automation were the needs to remain competitive and reduce costs. As a manager with a large Healthcare technology supplier stated, “IT budgets are all about doing things cheaper, faster and improving quality”. He believed CPM toolkit achieves all three. We did encounter some resistance to suggesting process change as an external solution provider, such as when a Software Development Manager from a large retailer said, “If Continuous Performance Management is perceived as being driven from outside the organization you will meet strong opposition, these changes needed to be driven internally to have any chance off success”.
In addition to these findings we repeatedly saw the following problems;
- Not gathering evidence on performance early enough
- Doing work based on performance assumptions without gathering evidence to support them
- Performance decisions tend to be ad hoc, with unfortunate results
No matter how you look at it, without the right tooling it’s almost impossible to get real unambiguous data to solve the above problems. In large complex application development who has the time to do the above manually. I can tell you, no one. Because it’s an impossible task. Developers will program a mixture of freestyle and frameworks based development. They will cut and paste from what they have done in the past and insert it into their new code. They will cut corners (sorry innovate) when they have to and they will make that milestone date ‘by any means necessary’. Now does that lend itself to best in class coding? You shouldn’t need to think long and hard about that one by the way. Management and architectural oversight has a huge role to play of course but without software process tools automation they are pretty much powerless.
