So if the software development business is infested with snake oil salesmen selling poorly-built systems written by
low quality programmers, why should my claims to be able to help you be any more trustworthy than theirs?
I’ve spent the last 30 years writing software for business clients, and the last 20 of those also managing
software development projects. I love writing software, and care deeply about the quality of software that I and my teams produce. I am fully committed to the principle that if a business contracts a software company to build a custom system, that system should
be delivered on time and on budget
do exactly what the business expects
continue to perform well as its user-base grows
allow for new features to be added with minimum effort
I’ve built software for companies of all sizes, from 3-person start-ups to multinationals including Microsoft,
Motorola, Honda and Shell. For all clients I commit to implement the highest quality software that I and my
teams can produce. If I collaborate with you and your company to identify, contract and work with a software
vendor, I will help to ensure that we achieve the same level of commitment from that software vendor, and that
the quality of software written for you remains consistently high throughout the project lifecycle.
The principles of good software design and implementation are not specific to any industry. It is also true
that these principles are not technology-specific. A good Java programmer can easily verify the quality of code
written in C++ or C#. Code which is devoid of comments, with hard-coded constants scattered throughout, without
consistent naming conventions, and without a coherent, modular structure, is bad code whatever the language it is
written in. My preferred programming language is not PHP, but I can certainly audit PHP code and identify weaknesses,
and indications of bad design.
If a software vendor is reluctant to expose their code to the client that is paying for it, or declines to explain
how it works (“You’re not a programmer, so you wouldn’t understand”) that is a Very Bad Sign. It likely implies
that the code is low quality, or even that the vendor doesn’t actually understand their own code (this is a more
common situation that you might expect—programmers leave a company and no one there understands how the code that they wrote actually works).
My goal is to empower you when dealing with software vendors. There is absolutely no reason why you cannot understand
the high-level workings and logic of the system being built for you, irrespective of your own technical knowledge.
Similarly, if you need a system driven by a database, the design of that database (the ‘schema’) should be something that
you can understand, specifically to confirm that it is indeed an accurate reflection of your business operation. Part
of my support of your work will be to dismiss any attempts by a prospective software vendor to hide anything from you on
the grounds of your lack of technical knowledge.
Having said all this, it is of course still true that if you contract my services, there is a large degree of trust implied
in that decision. So before making any commitment you will have the opportunity to talk to me, to understand my philosophy
and approach, to clarify exactly what I would do for you, and ultimately to feel comfortable that my goals are in fact the
same as yours—for your company to have a reliable software system, written to your specifications, and performing as your business requires.