On this page Frank explains his vision on developing high quality software, and how manning a helpdesk in his early twenties shaped his development style.
What does a business customer want? It is not the fanciest latest tech, and not the latest beta of your development tool.
For the customer your software is nothing more than one of the tools used to get their job done. So, keep it simple and smooth.
The customer wants Ease-Of-Use, Performance, Stability and minimal helpdesk contact.
During all stages of software development, you need to keep looking at the product through the eyes of the end-user. If you view the product as a technical achievement, your product is never going to be the best.
Really good software is a combination of all the following five qualities:
The UI must be kept as simple as possible. Invest time and energy in simplifying the dialogs and UI. If you think the UI is done, ask yourself if it can be simplified some more?
The application should run as fast as possible. High performance contributes to usability and means a good user experience and high productivity. We want faster load times and the fastest processing time. When the user clicks a button, data should display immediately.
Writing code is not about showing how smart you are. Coding needs to be organized in such a way that close to bug-free code comes out.
Nothing is more damaging your to company and to the relationship with the customer than buggy software: frustration, helpdesk overload, documenting and escalating, and having to release an unscheduled update.
Code must be maintainable. Source code should be simple and easily understandable. Good programmers write simple code. Bad programmers write complicated code. Five years from now there may be another developer working on your code, do your best to make a good impression.
The goal is to keep helpdesk interaction at a minimum to reduce costs and maximize user satisfaction.
The helpdesk load measures the quality of the application. When the helpdesk receives a lot of calls about bugs, complaints and unclarities, the software was designed and written poorly. Failing managers, developers and programmers need to be replaced.
In my early twenties I was a partner in my father's software business in the Netherlands.
Apart from developing software, I was also responsible for manning the helpdesk for a medical billing system for physiotherapists.
Every unclarity and bug in that program generated loads of helpdesk calls. As I was passionate about writing code, and less enthousiast about answering the phone. I experienced each phone call as an interruption of my work. The calls were breaking my focus, and I wasn't happy with that.
After a long period of time, I got so fed up with the situation that I decided I was going rewrite the billing system from scratch. I swore to myself that the program was going to be so good, that helpdesk load would be reduced to an absolute minimum.
I approached the problem systematically, and realized I had to start by writing my own development tools first, and only then start coding the new medical billing system.
After a about a year the new billing software was ready, and upgrades were mailed to the customers. This was before the internet, and updates were delivered on floppy disks.
Everything worked out as planned, and the new software was a blazing success and helpdesk calls were reduced to the absolute minimum that I wanted.
At a young age I created a working formula for successful software development.