|
1.
If it ain’t broke, don’t fix it.
This is a favourite saying amongst finance directors. After all, computer systems that worked
last week may well work this week, even next week. In reviewing an imperfect system, the most important analysis is
to identify the areas that do work. Those areas may be in functionality, such as the correct calculation of premium.
They may be measurable, such as performance and solidity. Or they can be emotional - the staff are happy with the
system and do not want to change.
Decide what is good about the system, and keep it.
2. Cutting out the dead wood.
This is the necessary balance to the previous statement.
If there is “dead wood” in the system it should be removed totally - not patched or bodged. Once a piece of
software is misbehaving, it is almost inevitable that fixing a little problem will have knock-on effects that will
then need to be fixed.
3. Don’t believe the hype.
Never, ever be impressed by new technology. Remember that the marketing departments and public
relations firms have enormous resources to push their latest gizmo. If they claim that it’s the best thing since
sliced bread, remind yourself that you prefer fresh bread from your local bakery. Question the motives of any
programmer evangelising about the gimmick of the day - are they more interested in their CV than your business?
As an example, here are some of Microsoft’s technologies
for getting data from a database to your program.ODBC, OleDB, RDO, DAO, ADO, ADO.Net, CRecordSet, SqlDataAdapter.
Each one is better than what came before it. But changing to the new one each year would not have noticeably benefited
your system.
4. Buy the new model.
Again a balance to the previous statement. When a technology has proved itself, and when it is a
sensible upgrade from what is currently in use, it is worth considering. This should be every three to five years - any
faster and you’re believing the hype, but any more slowly your system risks becoming fossilised.
We moved our programming from C to C++ once the “new”
language was no longer new. Our system has moved between generations of hardware and operating system, so that it is now
running on a physically smaller box that is a thousand times more powerful than the original.
5. Talk is cheap.
I know it does not feel like it’s cheap - the three hour meeting is often a huge waste of time.
But talking to the programmer before and during development is a lot cheaper than fixing software that has been written
under a misunderstanding about what you wanted. And if three hour meetings are wasteful then don’t use them - many
small chats are probably more productive than one big one.
On which subject, be suspicious of developers who don’t communicate well with you. If the
programmers don’t visit your offices, don’t talk to a broad range of users, don’t ask intelligent
questions then I suspect they will write not a system that suits you. The nerdy programmer is a stereotype you do not
have to deal with - my colleagues are all affable, well adjusted individuals. Even if I do say so myself.
6. Survival of the fittest.
The Darwinian principle is about adaptation. The software that will last longest is not the fastest
or most clever, it is the software that is most able to adapt. The place you need adaptation is in the business
requirements that the software can meet. These requirements change all the time as you keep your business competitive,
and they simply cannot be anticipated.
Sometimes, a system specification can be used against you. The programmers may swear that as it
was not in the spec, it will take months to do. You should sack these programmers. The fact is that the business changes
and all software should be built with adaptability in mind.
7. A brave new world.
This is the previous statement, writ large. If there is a huge
change, then the software should be able to move forward, to engage with that change. The Internet is a quantum leap -
a nearly free network that allows your data to go anywhere in the world. It is not the case that the new world requires
new systems, just that the existing systems are capable of major changes.
We are proud of how well our systems moved out onto the Internet. Significant amounts of new
code had to be written because Internet systems are different from back-office applications. But equally significant
blocks were re-used from the main system, including the storage of all data, the automated underwriting decision and
the calculation of premiums.
Keep these seven clichés in mind. After all, they are clichés because they
have stood the test of time.
|
For more information please call Whitespace marketing on 020 7240 0208
Alternatively, you can email us with your request at
info@whitespace.co.uk.
|
| 
