Menu
Menu
Lumley Tender

Lumley Tender

Just as more all too often turns out to be less, Lumley Technology research and development manager Adrian Pryke knows full well that faster can often ultimately prove slowestYears of application development experience have taught him the importance of classical programming techniques and good design, even in object oriented development environments. And he says too many IT shops are falling down when it comes to recasting those tried and true programming methods to suit object oriented developments.

"There's no snake oil. Really there isn't," he says.

"There's a lot of push these days to the idea of prototyping up solutions and time boxed development and all that sort of thing," he says. "I think in some instances people use this as an excuse not to do the real work. They fall back into this stage where they want to develop the whole application in the editor and change it as they go and hope they come up with something that works in the end.

"Now I don't think there's any tool really that allows anyone to do that. At the end of the day you've still got to go through all the motions."It's a philosophy that is reflected in Lumley's development of RepairCam, a computer-based imaging system.

Lumley is a quality-accredited organisation with a development framework and a set of deliverables that have evolved in-house over the past five to 10 years.

Both the framework and those deliverables were incorporated into development of RepairCam, a video imaging system designed to help automobile repair shops and insurance companies significantly streamline the process of repairing damaged cars.

With an over-enthusiastic marketing team inadvertently placing pressure on its developers to get a complete system out to users fast, Lumley relied on object oriented development to speed up the system development process for RepairCam.

But according to Adrian Pryke, while RepairCam shows the value of object oriented development to accelerate system development, it also reinforces the message that no amount of specialist tools to speed development can offset the need for tried and true programming techniques.

A Sydney software and services company, Lumley Technology has established itself through custom programming work for the insurance industry. In late 1994, several Lumley developers decided to try their hands at developing a way to streamline the labour-intensive process by which insurance claims for damaged vehicles were processed. Investigations showed the biggest bottleneck in the claims process came about because assessors had to physically travel to inspect damaged cars before authorising repairs. Car owners had to leave their vehicle at the repair shop until the assessor could get there, and assessors spent most of their time shuttling between garages for inspections. In country areas the problems were even worse, since assessors might only visit a remote town about once every two weeks. Lumley set out to find a remote assessing facility. It engaged a third-party organisation experienced in video technology, Megavision, to develop a prototype system. They came up with the RepairCam concept and developed the product in Visual C++.

After proof of concept, Lumley took over the system and very quickly realised that its architecture was not capable of the development and expansion required, so they decided to redevelop and expand the system, by integrating databases and replacing the communications DDE component with an API-based approach.

This in turn led to the final RepairCam system (see "Getting There From Here").

Marketed to individual repair shops, RepairCam lets panel beaters quickly capture images of a damaged car and submit these imagesdirectly to assessors via modem. It integrates an 8mm video camera with an Ipex 133MHz Pentium PC, 28.8Kbit/sec Hayes modem, Epson colour printer, and Movie Machine video capture board.

Worth a thousand words

Under the completed system, when a customer brings a damaged car into the shop, the mechanic spends several minutes videotaping it from all angles, paying special attention to physical damage and the car's identifying marks. The videotape, which is kept for evidentiary purposes, is then replayed and a series of still frames are grabbed into the computer. The panel beaters enter identifying information and RepairCam bundles the information to be transmitted via modem to a multi-line RepairCam server hosted by the customer's insurance company.

"We're bringing the damaged vehicle to the assessor's office using the computer," says Lumley general manager of sales and marketing, Bernie O'Brien.

Assessors can call up submitted RepairCam records and quickly review the damage on 21in monitors, using image quality adjustments built into the program to optimise their view. Because they can see the damaged vehicle without having to travel to the site, the system drastically cuts down the time it takes to authorise repairs - and clients don't have to leave their car at the panel beater's until the assessor can show up.

"It's made things a lot easier for everyone concerned," says Alan Mackay of Manson's Panel Shop, a panel beater in Kalgoorlie, Western Australia. "Whereas before it could take a week or two for an assessor to come out, I can process a whole claim in an hour and get them back on the road faster."Indeed, Mackay says the system has given him a significant competitive advantage considering that many of the area's vehicles are involved in Kalgoorlie's sizable mining industry. "Mining companies simply cannot afford to have vehicles off the road for long," he explains.

Six insurance companies - GIO, Mercantile Mutual, Lumley General Insurance, MMI, and South Australia companies SGIC and RIA - are currently participating in RepairCam. GIO senior assessor John Medcalf says the system had significantly streamlined the claims process. "If a job comes in today, we can do it straight away," he says. "We don't have to worry about travelling between jobs." Each insurer maintains a RepairCam server on its premises, which incorporates one or more modems to handle incoming calls and includes 4Gb to 8Gb of storage space. Borland's InterBase database runs underneath RepairCam to track submitted images and other information relevant to the processed claims.

Maintaining a long-term database of RepairCam submissions lets insurers monitor claim trends and generate statistics to compare the cost of repairs, O'Brien said - for example, which colour cars are more expensive to repaint. The database also needed to support multiplatform environments, since as the RepairCam network grows RepairCam servers will be handling multiple submissions from panel beaters at the same time.

Testing, testing, 1, 2, 3 . . .

All IT shops are under enormous pressure to take testing short cuts to cut down on system development times, and Lumley is no exception. As repor-ted in sister publication Computer-World on March 21, large numbers of software projects are victims of "quick and dirty" testing. The inevitable result is that expensive and frustrating problems are only being detected during usage.

Services vendor IV&V Australia managing director Donna O'Neill says taking short cuts on testing is "a disastrous set of circumstances given the ever-increasing complexity of software systems". She also says the testing needs to be managed as a project within itself - from strategic planning to formal signing off.

Adrian Pryke would agree, and says the RepairCam development highlights the importance of testing even in cases where systems must be developed fast.

"These days we have a lot higher focus on formalised testing evidence that formal testing has been done. "RepairCam currently has a user base of more than 100 sites. If there's one error or one fault in a critical component of the application, we will get 100 phone calls. So we have people develop formal test plans - and this is all standard text book stuff even though testing is the phase most often skipped - that we go through to verify the test plan against the design and against the requirement." The Lumley development team conducted component testing throughout the development process.

"One problem you always have with delivery is that at some time you have to do a test of the entire system, and get a 100 per cent result, for you to release that system.

"Now if you go through your full test cycle and you do get errors and you choose to fix them, you realistically should do the full test cycle again, because you've changed the product.

"Let's face it, this degree of testing is not very glamourous. It's a lot of hard work and I think that's why people tend to take short cuts, but I think it isvery important."Getting There From HereHow tried and true programming techniques moved RepairCam out of the workshop and into the fieldMegavision initially wrote the RepairCam prototype in Microsoft Visual C++, but the growing appeal of the system made Lumley decide to take another look at the way the system had been developed.

"The prototype did a wonderful job on the imaging side," says Lumley's Adrian Pryke, "but the application side wasn't as good as it could be. Being a prototype, it had been changed around quite a bit and there hadn't been much care to follow a precise structure and good design philosophies.

"It was also developed by people that knew a lot about the imaging software and the imaging technology, but in a very piecemeal manner, in that there was no application architecture. The application itself wasn't designed from the top down or the bottom up - it was just developed.

"We believed it was vital to have a strong architecture because RepairCam as a product is a long-term proposition for Lumley Technology, so it's essential we have something robust and maintainable and open to expansion.

"While we were running some pilot RepairCam systems a number of issues came up stemming from the way the application was designed."These issues made the prototype "highly effective" in helping Lumley more exactly match the system to the business need. Indeed, the company eventually ended up with a very long list of shortfalls in the prototype that would need to be addressed in the redevelopment. Lumley ran the prototype for some eight months before closing it down. That added some expense to the project, because Lumley had to maintain the prototype while developing the new application. On the other hand, the prototype did a reasonable job of servicing a need while allowing the company to fine-tune the application requirements.

"The prototype went a little bit further than it should have, in that as usual marketing jumped the gun a bit and started selling the prototype as a going concern. That meant it very quickly had to be made a growingconcern," Adrian Pryke says. "Ideally, from my point of view, as an exercise it would have been good at that point to stop and do some more work, but as a business reality you can't really carry on like that."With the extra pressure from marketing giving them an added incentive to move things along, Lumley started work on the new application inearnest. Eschewing any notion that rapid system development necessarily meant taking short cuts, the team adopted a fairly classical approach to the system development. It used the prototype solution plus the list of known shortfalls and suggested improvements as the basis for a requirements definition. It then went through an object oriented design approach.

"The technique we were using at that stage was a bit of a hybrid. It was a combination of classical structured analysis and design combined with object oriented modelling and so forth."Sloppy C++Because of the complexity of Visual C++ and the disorganised way the code was initially written, the team found that the costs of getting the system into line with what it wanted to be able to do with it was around the same cost as rewriting the system from scratch.

After surveying the 4GL-development tools market, the team compared Microsoft Visual Basic and Visual C++ with Borland's Delphi environment. It discounted Visual Basic because of its performance and language structure and the fact that its underlying language was Basic, which the team did not consider a commercially viable language. It also decided that while Visual C++ would have met most of its criteria, it would have been more expensive and development would have been harder and take longer than using Delphi. In the end, an evaluation and trial development undertaken in Delphi convinced the team Delphi was the best option.

Delphi appealed to the Lumley developers for several reasons. "The application's performance was impressive, and Delphi was highly suitable in allowing us to attach an underlying database," Adrian Pryke says.

"Our view of development is that as application developers we should be protected from the nitty gritty of the low-level environment while still being able to have access to it. We also believe we should be able to concentrate on the task at hand, which is after all developing the business application.

"In doing so, we should be able to apply a modern development paradigm such as object oriented design and development and relational database technology without having to do handstands to achieve it."The team also approved of Delphi's "visual characteristics" - its ability to give developers a high degree of control over the look and feel of applications. Lumley considers getting the presentation layer right to be a vital component of matching any application to the business needs.

"In this case the mechanic might be using the keyboard with a shifting spanner in one hand and a mallet in the other. In seeking to develop a new application we wanted to use a language which would allow us to easily develop very effective user interfaces that gave good visual feedback."The availability of Delphi add-ons was also a bonus. The Lumley team incorporated Turbo Power's Async Pro communications drivers, which facilitated a "total rewrite" of RepairCam's communications modules. "The communications routines were inherently error-prone and cranky," he says. "Theywere based on Dynamic Data Exchange, which doesn't provide the feedback the application needs to have full control over the process. If something changes, you're likely to get an error. Using Delphi, we now have very well-developed error recovery for modem communications." * Sue Bushell is ComputerWorld's Canberra editor(c) 1997, COMPUTERWORLD

Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.

Join the newsletter!

Error: Please check your email address.

More about Borland AustraliaEpsonGIOHayesIpexMercantile MutualMicrosoftMMIObject OrientedSECSydney SoftwareTechnology Research

Show Comments

Market Place