Accountants as Custom Computer Software Developers


W

Wolfgang Rochow

Is this statement an oxymoron?



I am a Certified General Accountant in Canada with many years in public
practice (write-ups, audits, and taxation). This was followed by
establishing a successful data centre operation with branches in Toronto and
Calgary. During these "data centre years" we always developed our own
software applications because the real needs of our customers could not
adequately be met by off-the-shelf software (unless one was prepared to
modify administrative and marketing procedures to fit into the constraints
of the software acquired). The only real drawback to me, as an accountant,
was that I had to be totally dependent upon programmers and their long
development cycles.



My dream was always to have software development tools that would allow me,
as an accountant with no formal programming training, to just sit down and
do it myself in a reasonable short time frame. As the needs for data centres
diminished, we decided to do something about this dream and started on a
project that would eventually see the completion of a graphical software
development framework that we called STEP FORWARD.



A few of our early projects included applications for a variety of
businesses and organizations (NGO's) that provided for accounting and
non-accounting information management. We have now started to market STEP
FORWARD and included in our target market accountants who wish to add a
lucrative software development and consulting service to their practice
offerings. (Remember, formal programming expertise is not required but a
logical mind is a prerequisite for using STEP FORWARD).



We have started talking to members of the accounting profession and find
that many of them are not interested (or possibly afraid) in learning new
skills. It seems as if they would rather concentrate on one or two
off-the-shelf accounting applications and, essentially, say to their
clients, "here is the solution, what is your problem;" rather than saying,
"what is your problem, we can provide a solution."



I can't believe that my attitude towards dealing with a client's problems is
shared by only a few accountants. It is, therefore, a distinct possibility
that our marketing approach to the accounting profession is flawed.



Ideally, we would like to establish a network of accountants and management
consultants across North America and elsewhere who are willing to adopt STEP
FORWARD as one of their solution tools.



Here is the question:

Are we taking a wrong approach or is the accounting profession, which
usually concentrates on write-ups, audits, and taxation, the wrong target
market for this type of product and the professional services that flow from
it? This is a sincere request for your professional opinion which you may
post to this group or e-mail me directly.



Thank you for your responses.



Wolfgang



(e-mail address removed) (remove contact to e-mail)

www.gestalt.com
 
Ad

Advertisements

B

Bob

Wolfgang Rochow said:
Is this statement an oxymoron?
I am a Certified General Accountant in Canada with many years in public
practice (write-ups, audits, and taxation). This was followed by
establishing a successful data centre operation with branches in Toronto and
Calgary. During these "data centre years" we always developed our own
software applications because the real needs of our customers could not
adequately be met by off-the-shelf software (unless one was prepared to
modify administrative and marketing procedures to fit into the constraints
of the software acquired). The only real drawback to me, as an accountant,
was that I had to be totally dependent upon programmers and their long
development cycles.
My dream was always to have software development tools that would allow me,
as an accountant with no formal programming training, to just sit down and
do it myself in a reasonable short time frame. As the needs for data centres
diminished, we decided to do something about this dream and started on a
project that would eventually see the completion of a graphical software
development framework that we called STEP FORWARD.
A few of our early projects included applications for a variety of
businesses and organizations (NGO's) that provided for accounting and
non-accounting information management. We have now started to market STEP
FORWARD and included in our target market accountants who wish to add a
lucrative software development and consulting service to their practice
offerings. (Remember, formal programming expertise is not required but a
logical mind is a prerequisite for using STEP FORWARD).
We have started talking to members of the accounting profession and find
that many of them are not interested (or possibly afraid) in learning new
skills. It seems as if they would rather concentrate on one or two
off-the-shelf accounting applications and, essentially, say to their
clients, "here is the solution, what is your problem;" rather than saying,
"what is your problem, we can provide a solution."
I can't believe that my attitude towards dealing with a client's problems is
shared by only a few accountants. It is, therefore, a distinct possibility
that our marketing approach to the accounting profession is flawed.
Ideally, we would like to establish a network of accountants and management
consultants across North America and elsewhere who are willing to adopt STEP
FORWARD as one of their solution tools.
Here is the question:

Are we taking a wrong approach or is the accounting profession, which
usually concentrates on write-ups, audits, and taxation, the wrong target
market for this type of product and the professional services that flow from
it? This is a sincere request for your professional opinion which you may
post to this group or e-mail me directly.

Thank you for your responses.
Wolfgang
(e-mail address removed) (remove contact to e-mail)
www.gestalt.com
you have mentioned this before and it's still not clear how "step forward"
is used, you portray it as a software development tool but there are plenty
of those for accountants - XBRL www.xbrl.org a part of "XML extensible
markup language" is the supposedly "open source -- royalty free" software
development tool currently promoted by accounting organizations - AICPA,
SEC, etc. -- how is "step forward" different or better from this?
 
P

Preston

I think what you are up against is the fact that most accountants,
like you mentioned, are trained and experienced in the areas of
write-up, tax, or audit. Most of us are not involved in that niche of
our profession where custom software is recommended and assistance is
given with implementation. It's not that we don't feel this area of
services is important, or that we don't want to learn new things, its
that we are just too involved in working in our own specialty of doing
audits or tax work.

The reason that we seem to always want to recommend the popular
software packages on the market is that we know they will meet the
needs of most clients and that they can generate good reports and
usually interface with other popular software. Of course we will come
across clients that need customized software, but from my experience,
I don't think we come across those types of clients enough to warrant
the time and effort required to become a specialist in this area. I
am sure that every accountant that works in developing custom software
for clients will tell me how wrong I am for making the prior
statement, but I do think my observation is true for the majority of
accountants in practice.

My advice is that you continue to market STEP FORWARD to accountants,
but try to identify those practices that provide custom software
services. Your advertising with these firms will be much more
effective and response rate should be much better.

Oh yeah, remember that it is hard to sell something to an accountant
because we are all so skeptical and cheap!

Preston Singleton, CPA
Austin, Texas
 
J

Joe Canuck

Wolfgang Rochow wrote:


of the software acquired). The only real drawback to me, as an accountant,
was that I had to be totally dependent upon programmers and their long
development cycles.
<snip>

There is a reason for this... and no it isn't to line the pockets of
computer professionals.

Also, an applications development team consists of more than programmers.

I think I'd rather have the accountants concentrate on numbers and
analysis of them rahter than also have them dabbling in systems
development which draws time away from what an accountants main purpose
really is.

I suspect your post is a veiled attempt to drum up more business and as
such could be considered spam.
 
A

Amy Gray

of the software acquired). The only real drawback to me, as an accountant,You show me someone who complains about the long process
of creating a program and i'll show you someone who has never
created a large program, never looked at the entire enterprise
behind the program. Sometime it's more than a matter of just
creating a program, sometimes you have to set up an entire
infrastructure to back that program. (Take orders, fill the orders,
ship the orders, etc.)

And sometimes you have to manufacture the stuff before you
take orders.
 
W

Wolfgang Rochow

Bob said:
problems


you have mentioned this before and it's still not clear how "step forward"
is used, you portray it as a software development tool but there are plenty
of those for accountants - XBRL www.xbrl.org a part of "XML extensible
markup language" is the supposedly "open source -- royalty free" software
development tool currently promoted by accounting organizations - AICPA,
SEC, etc. -- how is "step forward" different or better from this?
The following is an edited comment from Alex Molochnikov, VP Software
Development, STEP FORWARD Software Inc.:

Firstly, a "tool" is not a "language". XBRL is just that - a language for
exchanging financial data. I could compare it with HTML (you know what it
looks like in the text editor); in order to make sense out of an HTML file,
one has to pass it through the browser, which is a tool for handling the
data written in HTML language.

You can find the tools that work with XBRL here: http://www.xbrl.org/Tools/.
There are two types of software one can find on this page:

1. Applications - ready to use, with GUI, oriented towards the non-technical
end user ("consumer");
2. Libraries and developer tools - to manipulate the contents of XBRL from
other applications, or to aid in developing such applications; these are
intended for use by a "programmer".

Now, guess which ones are "free" and "open source"?
Secondly, STEP FORWARD (SF) is a high-level graphical abstraction of the
process of programming accounting and general purpose database applications.
It allows the end users to do development without becoming programmers.
XBRL, with all freebee tools that one can find, turns the end user into a
programmer (actually, as far as I understand it, if the user is not a
programmer by training, all he can do with XBRL is to buy one of those
commercial gadgets that hide the XBRL details from him).

------------

Now to my own comments.
Although computer programming is a mystery to many accountants, I have
always taking a simplistic approach to it. Information management is
essentially nothing more than a number of procedures that capture and
manipulate data which in and of itself is utterly useless unless one can
extract that data and present it in a meaningful format suitable to a
specific purpose which can range from a job estimate to invoicing to
financial statements, customer relations management, or whatever the mind
can conceive, or management deems necessary to assist it in making
intelligent business decisions. The underlying data repository, in the case
of SF, is a relational database (RDBMS) e.g., MS SQL Server, Oracle, Sybase,
McKoi, Mimer, etc. SF provides all the necessary tools to quickly achieve
these information capture and reporting requirements.

Here is the how: SF is a graphical application development framework that
allows one to create (to name a few basic features):
Data Input Templates (DIT) - (templates are the prototypes for data input
windows); Data Input Procedures (DIP) - (executable flowcharts that attach
logic to data capture procedures; Report Print Templates (PT) - (creating
the cosmetic components of a report); Report Procedures (RP) - (executable
flowcharts that take care of the entire report logic including data
retrieval and manipulation); Procedures - (executable flowcharts that can
perform any desired functions including updating of database tables and the
automatic generation of accounting transactions based upon an event).

Data Capture:
A DIT is a collection of data fields that have been defined as to data type
(e.g. text, integer, date, switch, image, etc.) and whose editable fields
are connected in the order in which one wants the cursor to move during data
capture. On "saving" the template design, SF creates the underlying
relational database table automatically. DITs are classified in SF as
Global, Subledger, or Transaction DITs. A Global DIT can carry any type of
data including data from linked Global tables (there is virtually no
restriction as to the number of fields that a template can have, or the
number of templates that are deployed); Subledger DITs are attached to
General Ledger Control Accounts and may contain data fields that are linked
to Global tables (common examples include master records for Accounts
Receivable, Accounts Payable, Fixed Assets, etc. - again no limitations ast
to how many fields or Subledger masters or formats); Transaction DITs are
used for accounting based data entries and can have a number features
attached to them that monitor accuracy, rules, etc.

A DIP is event driven and can carry out predetermined calculations or
methods which, again, carry no system imposed limitations. An event may be
the disturbance of a specific field or a record event e.g. loading, saving,
updating, etc.

Utilizing the DIT/DIP tools, one can capture any type of data.

Data Reporting:
A PT defines the cosmetic layout of a report. Each PT can consist of a
Header, a Body, and a Footer although they do not all have to be present in
a PT. A report can be produced with a single PT or any number of PTs. A PT
is strictly cosmetic and carries no logic.

A RP handles all data extraction and manipulation and directs the resulting
data combinations to the appropriate PT.

Utilizing the PT/RP tools, one can create any report imaginable based upon
the captured data and any parameter input and direct these reports to a
printer or over the WEB in PDF format.

Processes and Automatic Data Generation:
Processes can be used to manipulate data, run a series of reports,
automatically update database tables including but not limited to the
generation of specific accounting transactions e.g. a Sales Invoice might
trigger this balanced entry: Dr to Accounts Receivable, Cr Sales, Cr Sales
Tax, Dr Cost of Sale, Cr Inventory, Dr Commission Expense, Cr Commissions
Payable, etc., etc.- without requiring further clerical effort.

Perhaps this response is over-kill to your question - I hope it does not
offend anyone. As accountant I know very little, if anything, about various
programming languages including XML. What I do know, however, is that STEP
FORWARD empowers me to meet virually all challenges a client can through at
me and do so in record time and, hence, cost effectively.

Thanks for asking "how is "step forward" different or better from this?" I
may not have answered this to your satisfaction; however, you are welcome to
go to our website and take a look at some of the video clips which may give
you a better understanding of STEP FORWARD and allow you to make an
assessment of it in regards to what you know about XBRL.

Wolfgang
 
Ad

Advertisements

W

Wolfgang Rochow

Joe Canuck said:
Wolfgang Rochow wrote:




<snip>

There is a reason for this... and no it isn't to line the pockets of
computer professionals.

Also, an applications development team consists of more than programmers.
I could not agree with you more. Thats why our team is a mix of accountants
and programmers. However, by understanding what can be done with STEP
FORWARD, I can address the needs of my clients to their satisfaction.
I think I'd rather have the accountants concentrate on numbers and
analysis of them rahter than also have them dabbling in systems
development which draws time away from what an accountants main purpose
really is.
While I agree with your comment, it does beg the question what is an
"accountants main purpose"? A different way of stating it may be to say:
"Rather than have them dabbling in systems development which draws time away
from what their specialties are - unless system development is one of their
specialty."

In my own case, while in public practice, I used to be involved in all the
usual accounting specific services including audit and taxation, and used
the services of a data centre. However, I put audit and taxation behind me
and now specialize in business reengineering and system development while
the taxation angle is addressed by an associate. I guess, what it boils down
to is whether one operates as a sole practioner or in partnership or
association with a number of professionals in order to adequately the needs
of one clients without spreading oneself too thin and become ineffective.

I suspect your post is a veiled attempt to drum up more business and as
such could be considered spam.
Actually, my original post was a sincere attempt of learning from my peers,
not to drum up business, although that will never be refused. Besides that,
I am of the opinion that we are always "selling ourselves", either
positively or negatively. I have, for example, followed various posts on
this newsgroup and made my assessment of various posters and respondents.
For some, I have developed deep respect; for others, utter disdain. As a
result I know whom I would recommend to others whenever an occasion arises;
should that occur, they will have received business through this newsgroup
and I do not consider that spamming, even when Arnold espouses "a-systems".
It's all part of our knowledge base and the more I learn from and about
others, the better I will become.

So I do hope that responses to my post will be treated with professional
courtesy as Preston Singleton did.

Thanks Preston.

Wolfgang
 
W

Wolfgang Rochow

Amy Gray said:
You show me someone who complains about the long process
of creating a program and i'll show you someone who has never
created a large program, never looked at the entire enterprise
behind the program. Sometime it's more than a matter of just
creating a program, sometimes you have to set up an entire
infrastructure to back that program. (Take orders, fill the orders,
ship the orders, etc.)

And sometimes you have to manufacture the stuff before you
take orders.
While I concur with you on your basic premise, I disagree with you in
principle. The length of time that I have complained about was aimed
specifically at the programming cycle after completion of all research and
project specifications.

What STEP FORWARD has achieved is to drastically shorten the progamming
cycle because "code writing" has been virtually eliminated. And after over
thirty years of quality experience and performance on large and small
systems for departmental and enterprise-wide applications, I consider myself
somewhat of an expert.

Wolfgang
 
J

Joe Canuck

Wolfgang said:
While I concur with you on your basic premise, I disagree with you in
principle. The length of time that I have complained about was aimed
specifically at the programming cycle after completion of all research and
project specifications.

What STEP FORWARD has achieved is to drastically shorten the progamming
cycle because "code writing" has been virtually eliminated. And after over
thirty years of quality experience and performance on large and small
systems for departmental and enterprise-wide applications, I consider myself
somewhat of an expert.
The bottom line is someone has to provide instructions to the computer
so it knows what to do.

The more complex the task involved the more complex those instructions
will be... even with some of the modern 4GLs (4th generation languages).

Elimination of the programming is only possible when one purchases a
package and adapts to it... rather than trying to bent it to their will.
 
A

Amy Gray

The bottom line is someone has to provide instructions to the computer
so it knows what to do.

The more complex the task involved the more complex those instructions
will be... even with some of the modern 4GLs (4th generation languages).

Elimination of the programming is only possible when one purchases a
package and adapts to it... rather than trying to bent it to their will.
I would point out the computer only recoginzes 0s an 1s. It takes a
lot of time effort and money to create applications that translate
those 0s and 1s into some usesable application .

To someone who complains about how long it takes to write computer
programs I would issue this challenge: go write a full accounting
package, have it ready tomorrow, and have it produce the desired
results with zero bugs.

Bet you can't do it. This from someone who has 1. done lots of
programming and used lots of buggy overpriced flawed software
packages.
 
A

Arnold

Amy, et al.

Extended development times and the burdensome costs associated with them
are the "barriers to entry" of the software business. At A-Systems, we
had nearly 20 years of development in our DOS software before we began
the rewrite into a 32-bit (windows) environment. Our experienced,
professional programming staff had great depth in accounting and a
proven template (in DOS code) to work from. Still, the project took
four years before we delivered our first product. It was almost two
years more before we were routinely shipping software with no reported
bugs. For nearly three years, every update that has left A-Systems has
had no reported bugs. And, probably 95% of the bugs we fixed were found
through our rigorous internal testing procedures.

Anyone can purchase generic code for the beginnings of an accounting
program that you can use to build your own accounting software. You can
even get it with certain programming languages, thrown in for free.
Everyone can create their own program. The problem is that the
individual accounting modules are poorly integrated (inventory to
accounts payable, accounts receivable, and purchase orders and all of
them with general ledger), they are not tested by actual users, they
have only rudimentary functionality, and they have no "bells and
whistles" (conveniences ) that make for happy users. WC Fields started
his career as a juggler. He was often approached by people who pestered
him to teach them how to juggle. His idea of getting them to go away
and inflict pain at the same time was to teach them to juggle with
knives. Trying to write an accounting program is not an easy task and
trying to build one from "free code" is like learning to juggle knives.
It is guaranteed to be a painful experience with few rewards. For a
fraction of the cost and without the years of delays, users can buy an
accounting program that meets their needs.

However, not all accounting software is created equal. On one end of
the spectrum is QuickBooks, an accounting program that evolved from a
home checkbook program. On the other end is J.D. Edwards, a mainframe
application that costs hundreds of thousands of dollars and the users
have to do their own work to connect the modules together.

With all of the competition, why would A-Systems or anyone in their
right mind want to write an accounting program? To start with, when
A-Systems wrote its first accounting program, it was for the
construction industry and there was no such thing as a job cost
accounting for the PC. A-Systems was the first to develop it.
A-Systems was privately owned and it carved out a niche in the
construction industry. Later, competitors entered the market, but many
of them had to go public to raise the funds necessary to develop their
products. A-Systems remained privately owned. In time, numerous non
construction companies were using A-Systems construction software,
selecting it for its power and affordability. Finally, A-Systems
decided to provide a general business accounting program to meet that
demand.

Because the existing software literally had years of development and
testing, it was not a "new" product. Because it had power and
versatility borne from thousands of users demanding niceties to
accommodate their needs and wants, it was not a shallow product.
Because A-Systems was a conservatively run company, debt free, with low
overhead, the product could be sold for a low price and still generate
respectable profitability. So, A-Systems began to offer its general
business accounting software to the mass market. Without disclosing the
details of its marketing plan, A-Systems has laid the groundwork to be a
solid presence in the market, a proven, powerful alternative to
QuickBooks with its Small Business Advantage version and an affordable
alternative to Great Plains with its Preferred Edition.

With our existing software operation, the back office functions are
already in place, the technical support staff is in place, and the
software is already "proven." Unless, we do something incredibly
wrong, you should be seeing A-Systems as a major alternative in the
accounting software business in the near future. We have already been
approached by investors wanting to buy in or buy us out. It is kind of
flattering. It is also somewhat intimidating to contemplate that our
competitors are Microsoft and Great Plains, but we bring quality that
few software companies strive for and even fewer attain. For years, our
goal has been to make a superior product and ignore marketing. Now, we
are gearing up our marketing effort.

Arnold



------------------------------------------------------------------------
 
Ad

Advertisements

W

Wolfgang Rochow

Joe Canuck said:
The bottom line is someone has to provide instructions to the computer
so it knows what to do.

The more complex the task involved the more complex those instructions
will be... even with some of the modern 4GLs (4th generation languages).
Correct, if you have to deal with a "language", even if it is 4th
generation. However, STEP FORWARD is not a programming language but a
development framework that comes with powerful pre-compiled development
objects. It still requires logical thought to define and map out tasks to be
performed whether they are complex or simple.
Elimination of the programming is only possible when one purchases a
package and adapts to it... rather than trying to bent it to their will.
The key word is found in your last paragraph: "adapt".
This has been the basic rule so far because many business people could not
afford "code-based" programming. Now they have the option of adapting to
someone else ideas as to how their business is run or to configure a
proprietary system themselves, without it costing an arm and a leg.

As accountant and consultant to a client, it is up to me to know what all is
available, understand and disseminate the pros and cons, and help my client
make an intelligent choice based on all the facts. The final choice must be
his/hers, not mine.
 
W

Wolfgang Rochow

Amy Gray said:
I would point out the computer only recoginzes 0s an 1s. It takes a
lot of time effort and money to create applications that translate
those 0s and 1s into some usesable application .

To someone who complains about how long it takes to write computer
programs I would issue this challenge: go write a full accounting
package, have it ready tomorrow, and have it produce the desired
results with zero bugs.

Bet you can't do it. This from someone who has 1. done lots of
programming and used lots of buggy overpriced flawed software
packages.
As a father of six children, I have learned that even a pregnancy takes 9
months, give or take a few days. In our case we were blessed with greater
productivity because of twins. So exceptions are possible :)
 
W

Wolfgang Rochow

Amy, et al.

Extended development times and the burdensome costs associated with them are the "barriers to entry" of the software business. At A-Systems, we had nearly 20 years of development in our DOS software before we began the rewrite into a 32-bit (windows) environment. Our experienced, professional programming staff had great depth in accounting and a proven template (in DOS code) to work from. Still, the project took four years before we delivered our first product. It was almost two years more before we were routinely shipping software with no reported bugs. For nearly three years, every update that has left A-Systems has had no reported bugs. And, probably 95% of the bugs we fixed were found through our rigorous internal testing procedures.

Congratulations, that's the way it ought to be.

<snip>

The problem is that the individual accounting modules are poorly integrated (inventory to accounts payable, accounts receivable, and purchase orders and all of them with general ledger), they are not tested by actual users, they have only rudimentary functionality, and they have no "bells and whistles" (conveniences ) that make for happy users.

<snip>

From my point of view, accounting applications are a niche market. Information management is much broader than that and while it incorporates accounting requirements, it is definitely not restricted to it. Furthermore, accounting modules are a leftover from the past, regardless of how tightly integrated. The ideal information management design is a unified (non-modular) system.

There are many fine "off-the-shelf" accounting systems, including yours I'm sure, although I have not yet had the opportunity to see or experience it. If they work for a business or NGO to their total satisfaction, by all means, implement and use them. In other situations a STEP FORWARD application development might be more appropriate.

We have also found that the complaint about systems in use is often not aimed at data capture but at insufficient reporting capabilities. To address this issue, we have spun off STEP FORWARD's reporting tools as a stand-alone application under the name of Scribe which is currently in final beta testing in a number of countries. Scribe is capable of retrieving data, creating reports and, yes, even updating relational databases and do so, if desired, on multiple databases simultaneously. The currently supported relational databases that Scribe will work with include Oracle, Ms SQL Server, Sybase, MySQL, Mimer, McKoi, and Daffodil. Other databases will be added.

The important think is that accountants and consultants are fully informed about what is available and to make quality recommendations to their clients.

Wolfgang
 
A

Amy Gray

It was almost two
years more before we were routinely shipping software with no reported
bugs.
And if you believe that i've got a bridge in Arizona to sell you.

I've been using computers since the early 70s. You show me a
software
package with no reported bugs and i'll show you a software developer
who shut off his phone, left town with no forwarding address.
..
For nearly three years, every update that has left A-Systems has
had no reported bugs. And, probably 95% of the bugs we fixed were found
through our rigorous internal testing procedures.
After dealing with Microsoft and their bugs (undocumented features) I
don't buy it.
 
J

Joe Canuck

Wolfgang said:
Correct, if you have to deal with a "language", even if it is 4th
generation. However, STEP FORWARD is not a programming language but a
development framework that comes with powerful pre-compiled development
objects. It still requires logical thought to define and map out tasks to be
performed whether they are complex or simple.
Which is what I thought... and if those none of those "...development
objects..." meet the needs of a particulary project one is severely
restricted as to what can be developed with your product.

Or... one must resort to developing another "...pre-compiled development
object..." to accomplish the task. So what language are these STEP
FORWARD pre-compiled development objects coded with?
The key word is found in your last paragraph: "adapt".
This has been the basic rule so far because many business people could not
afford "code-based" programming. Now they have the option of adapting to
someone else ideas as to how their business is run or to configure a
proprietary system themselves, without it costing an arm and a leg.
But how can that system be proprietary when it will be built using the
same STEP FORWARD "...precompiled development objects..." everyone else
will be using?
As accountant and consultant to a client, it is up to me to know what all is
available, understand and disseminate the pros and cons, and help my client
make an intelligent choice based on all the facts. The final choice must be
his/hers, not mine.
But I suspect your STEP FORWARD product figures strongly in your
proposals when a new automated solution is one of the issues. :)
 
Ad

Advertisements

A

Arnold

Amy,


It doesn't say the software is bug-free. The words are "no reported
bugs." I doubt that any software is bug free.

Every time we add a new feature it creates the opportunity for new bugs
to creep in. For instance, if we add a new report template to job
costing, it might be able to be formatted and printed in a range of say,
1-2 billion combinations. It is literally impossible to test every
possible report format that report template might generate. We test the
most likely formats until everything consistently works as designed.
There might never be a bug reported. Or, one day someone sets up a
combination of parameters that we did not anticipate and it sorts the
data wrong. We fix it and put the fix on the website, probably the same
day. Our software even has a built in Update icon that allows users to
check the internet for interim fixes. (Not service packs, but little
fixes.)
And if you believe that i've got a bridge in Arizona to sell you.

I've been using computers since the early 70s.
The PC was first delivered in 1975 with 4 k of RAM. Those were the days
before basic. Basic was a huge step forward, but it was still a very
cumbersome program. Current programming languages have come a long
ways. Rapid Application Development (RAD) tools have revolutionized the
way programming is done.
You show me a software package with no reported bugs and i'll show you a software developer
who shut off his phone, left town with no forwarding address.
..
Our phone is answered by live bodies. We don't use voice mail or
machines. It's old fashioned, perhaps that's part of why we are so
different.
After dealing with Microsoft and their bugs (undocumented features) I
don't buy it.
A-Systems does not do business the way Microsoft does. We do not set a
calendar date and ship whatever happens to be ready on that date and
then follow it up with "service packs." Each A-Systems update is a
discrete project that is not shipped until it is programmed, tested
internally by multiple testers (whose job it is to make it fail) and
then tested by a list of coast to coast beta testers, each with their
own way of doing things.

We track every bug reported by our clientele. If we can reproduce it,
we fix it. If we can't reproduce a bug (by multiple testers and tests)
it is probably an issue with hardware or their network configuration.
We implemented a bug tracking system when we first started our 32-bit
software. It was a necessary part of our project. Every bug is
described in detail and assigned a problem resolution number, as it is
reported. If our internal testers turns up a bug (not reported by
users), we follow the same procedure. Those involved in documenting
bugs take a perverse pleasure in adding them to the bug list. Their
counterparts are always in a race to see how quickly they can get them
off that list. It is our system of quality control. You may buy it or
not, but that's the way it is, no matter how Microsoft does it, that's
how we do it. Perhaps that's why over 80% of our sales come from
referrals from existing clientele.

Perhaps you would feel better if I said, "Our software is not bug-free,
but when a bug is reported, it is fixed."

Arnold
 
J

Joe Canuck

Arnold said:
Amy, et al.

Extended development times and the burdensome costs associated with them
are the "barriers to entry" of the software business. At A-Systems, we
had nearly 20 years of development in our DOS software before we began
the rewrite into a 32-bit (windows) environment. Our experienced,
professional programming staff had great depth in accounting and a
proven template (in DOS code) to work from. Still, the project took
four years before we delivered our first product. It was almost two
years more before we were routinely shipping software with no reported
bugs. For nearly three years, every update that has left A-Systems has
had no reported bugs. And, probably 95% of the bugs we fixed were found
through our rigorous internal testing procedures.
Arnold, I am pleased you used the phrase "reported bugs" since there is
very little software that undiscovered bugs of some sort. :)

User testing is sometimes more rigerous since they are not aware of the
limitations of the software and will try to make it accomplish things it
was never designed for... unlike project staff who are aware of the
limitations of the software and will not make excessive demands on it.
Anyone can purchase generic code for the beginnings of an accounting
program that you can use to build your own accounting software. You can
even get it with certain programming languages, thrown in for free.
Everyone can create their own program. The problem is that the
individual accounting modules are poorly integrated (inventory to
accounts payable, accounts receivable, and purchase orders and all of
them with general ledger), they are not tested by actual users, they
have only rudimentary functionality, and they have no "bells and
whistles" (conveniences ) that make for happy users. WC Fields started
his career as a juggler. He was often approached by people who pestered
him to teach them how to juggle. His idea of getting them to go away
and inflict pain at the same time was to teach them to juggle with
knives. Trying to write an accounting program is not an easy task and
trying to build one from "free code" is like learning to juggle knives.
It is guaranteed to be a painful experience with few rewards. For a
fraction of the cost and without the years of delays, users can buy an
accounting program that meets their needs.

However, not all accounting software is created equal. On one end of
the spectrum is QuickBooks, an accounting program that evolved from a
home checkbook program. On the other end is J.D. Edwards, a mainframe
application that costs hundreds of thousands of dollars and the users
have to do their own work to connect the modules together.

With all of the competition, why would A-Systems or anyone in their
right mind want to write an accounting program? To start with, when
A-Systems wrote its first accounting program, it was for the
construction industry and there was no such thing as a job cost
accounting for the PC. A-Systems was the first to develop it.
A-Systems was privately owned and it carved out a niche in the
construction industry. Later, competitors entered the market, but many
of them had to go public to raise the funds necessary to develop their
products. A-Systems remained privately owned. In time, numerous non
construction companies were using A-Systems construction software,
selecting it for its power and affordability. Finally, A-Systems
decided to provide a general business accounting program to meet that
demand.

Because the existing software literally had years of development and
testing, it was not a "new" product. Because it had power and
versatility borne from thousands of users demanding niceties to
accommodate their needs and wants, it was not a shallow product.
Because A-Systems was a conservatively run company, debt free, with low
overhead, the product could be sold for a low price and still generate
respectable profitability. So, A-Systems began to offer its general
business accounting software to the mass market. Without disclosing the
details of its marketing plan, A-Systems has laid the groundwork to be a
solid presence in the market, a proven, powerful alternative to
QuickBooks with its Small Business Advantage version and an affordable
alternative to Great Plains with its Preferred Edition.

With our existing software operation, the back office functions are
already in place, the technical support staff is in place, and the
software is already "proven." Unless, we do something incredibly
wrong, you should be seeing A-Systems as a major alternative in the
accounting software business in the near future. We have already been
approached by investors wanting to buy in or buy us out. It is kind of
flattering. It is also somewhat intimidating to contemplate that our
competitors are Microsoft and Great Plains, but we bring quality that
few software companies strive for and even fewer attain. For years, our
goal has been to make a superior product and ignore marketing. Now, we
are gearing up our marketing effort.

Arnold
That was spoken with a decided marketing slant.

However, the proof is STILL in the pudding. :)
 
Ad

Advertisements

W

Wolfgang Rochow

Joe Canuck said:
Which is what I thought... and if those none of those "...development
objects..." meet the needs of a particulary project one is severely
restricted as to what can be developed with your product.
You can only guess. Others speak from experience:
"I have never seen anything like it. It's so simple, how come nobody else
has thought of doing it that way. The only limiation that I see is the
limitation of my own imagination." (Barbara P., Controller, Denver,
Colorado)

I am almost tempted to suggest that you download STEP FORWARD from our
website and try it yourself. But you might think of it as spamming, wanting
to drum up business. Therefore, I wont.

Or... one must resort to developing another "...pre-compiled development
object..." to accomplish the task. So what language are these STEP
FORWARD pre-compiled development objects coded with?
STEP FORWARD is written entirely in Java; and, yes, you can write and add
additional feature sets if you wish. Far be it for us to dictate to anyone.

But how can that system be proprietary when it will be built using the
same STEP FORWARD "...precompiled development objects..." everyone else
will be using?
Simple. It's the encapsulated business logic that makes it proprietary.
But I suspect your STEP FORWARD product figures strongly in your
proposals when a new automated solution is one of the issues. :)
If asked to create a custom (programming) solution, I'll use my own tools.
Just as your plumber would to fix a leak in your house. But remember that
STEP FORWARD is essentially a set of tools and not a solution. Therefore,
the desired "automated solution" could be achieved using any number of other
tools or programming languages. Just that STEP FORWARD is more efficient and
can be used by any person with a logical mind, without requiring formal
programming skills.

Wolfgang
 
Ad

Advertisements


Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top