Why is software so expensive ?
There are many reasons why software is expensive, always late and usually not as good as originally hoped. At Shellware Engineering we have attempted to design out some of these reasons as early as possible.
Listed here are a few examples -
- Multiple Event Handling
In a complex system software must catch and handle events as quickly as possible.
This places a large strain on the overall design and can often lead to programmers
'jumping through hoops' in an attempt to accommodate the events correctly.
Our solution is to use an event driven multi-threader that handles all events in a
transparent and safe manner. All the threads are designed to work in parallel.
- Memory Leaks
This problem affects most modern software. If a system has no protection against leaks
then it will certainly be leaking. Leaky software will crash inexplicably after a
period of time - days, months or even years. The usual cure is to reboot the system which
is not always an option.
Our solution is to allocate dynamic blocks to individual threads. As the blocks pass
into a new thread the ownership is also transferred. Each thread declares how many
blocks it is planning to own (the default is 3) and if it exceeds this amount a
software trap is set off to alert the programmer.
- Buffer Under/Over Flow
Every programmer has to spend a considerable amount of time tracking down buffer underflows
and overflows. Crashes caused by these types of errors are notoriously difficult to find.
Our solution is to place 'trip wires' just above and below the buffer. Before a thread
is allowed to transfer a buffer into a new thread the trip wires are tested to ensure that
no corruption has occured. If the trip wires have been compromised then a software trap
is set off to alert the programmer.
- Code is not Re-usable
Despite the huge amount of research that has been performed to make code re-usable the sad fact
remains that very little actually is. Huge amounts of designing, coding and testing could be
saved if code could be constructed to be more re-usable.
Our solution is give each thread two identical ends - an 'in' and an 'out'. This enables
any thread to connect with any other thread to form a long 'necklace' to process the
data. The necklace can be broken, re-arranged or extended at will by the designer. In this
way re-usable software is not just limited to the simple peripheral tasks.
- Incomprehensible Designs
Complex software is often damaged because the maintainer is unaware of the full picture.
In traditional software it is very difficult to provide an understandable image of how
the system works.
Our solution is a free by-product of our approach to multi-threading. A chart can be drawn
which shows how all the threads are connected to each other. The software is represented
by a virtual machine that is constantly moving data across the chart from left to right.
- Systems are Started from Scratch
Most systems are still designed from scratch mainly due to the re-usable code problem described
earlier. It is obvious that software will be ready earlier and contain less bugs if it can
be built on top of a generic system base.
Our solution is to write a large number of threads dedicated to the functions that every
system will require. For example - starting and stopping processes - individually and in groups,
distributing dynamic parameters as and when they change, generating and collecting reports etc.
- Secondary Systems are Different
Amazingly, when a company commisions a second system it contains few, if any, parts of the
original system. If all systems within a company were all hosted on the same generic base the
savings would be enormous.
Our solution is to design all our systems with the generic multi-threader and to write as many
generic threads as possible. As the library of general threads continues to grow the simpler
it is to build new systems.
Back to our main page