As a software developer, I’ve come across many horrors in coding over the years. It’s no secret that most developers code things fast and ugly to get stuff out the door. But something strange happened to me recently; I think I am finally becoming a better coder.
I’ve been developing an ERP/MRP/CRM by myself for the past 3+ years and I’m finally reaching the release date. I’ve been testing the product with two clients for the past year, and naturally, many bugs have popped up out of nowhere, many features have been requested, and so on. You know… the typical software development cycle plagued with inadequacies.
However, I’ve finally learned a valuable piece of information I’d like to share:
Features, not rules.
I went in with a bunch of rules for the last meeting I had with my clients. They had to follow these rules to use the new features in my system correctly. They needed to follow certain processes in an orderly manner, they needed to avoid placing certain characters at the start of some files, they needed to use the correct extensions, they needed to avoid using certain half-baked process, they needed to process files at the end of the month and not in-between, etc.
Naturally, they were a bit taken aback. They are not computer-savvy, and they have a hard time grasping new things. “Why?” kept comming up all the time. I tried to explain that this is natural in a system so big, there are certain rules you must learn to avoid entering bad data, or messing up parts of the system, etc.
Halfway through the training I realised I was doing things the wrong way. Whenever you have to write down more than 3 rules for a process, it is almost always better to make the system handle all possible exceptions instead, and inform the user appropriately when they have made a mistake. It is easy to do this with forms for example, you write down some regex rules (or use JQuery Validate), you add extra back-end validation, you use a “form/validation” class, etc. However, when the processing takes place in the back-end (e.g. a file parser that changes content in the database), it is easy to expect too much of the users.
I left the meeting with all the rules I had written down scratched out and a page full of tasks to be performed.
I think it is vital for us to embrace this. A system must be able to handle anything thrown at it, it must be able to validate incorrect data, file extensions, and any other exception you may think of. It seems natural, most of you are thinking “this is so obvious, why write a blog post about it?”. Why? Well, because I keep seeing these kinds of mistakes all over the place. I’m sure many developers out there still think “oh, I’ll just explain the user how to do it”. Then you get a ton of calls of users asking why this or that is not working, and you have to explain that there is a certain process to be followed.
The answer is simple: Think before you code, and make whatever you code “think”.