I have been associated with software development for over 35 years. I wrote my first software using assembly language. Every thing that executed in our software in those days was written by us. We did not have libraries to link to or objects to include or API’s to call. I am not trying to imply that software development is easier now than it was before. The challenges faced by today’s developer are different than what we faced. Software written in those days accomplished less with more lines of codes than today’s software. The technologies, methods and many other aspects of software development may have changed but the basic rules that we followed those days still hold value.
Let me introduce you to those basic rules that I always followed. I call them the conservative values of software development.
Keep it simple:
One of my professors of assembly language programming gave us a challenge as our first assignment. We had to write a simple program to determine if a given number was prime using a pseudo language which contained only one executable statement and one declarative statement. It took us hundreds of lines of code to accomplish that simple task. The lecture that followed that assignment taught me a life long lesson: Simple programs are easy to debug, easy to follow, and usually more efficient to execute. Writing a complex line of code that can accomplish several tasks may make you feel good about your coding skills but pray that no one else has to debug or change that code some day, because they won’t agree that you’re a good coder. Accomplishing the same set of tasks in few simple lines of code will be better in the long run. Simple code is more readily reusable. I’m not preaching that you shouldn’t use all the tools at your disposal, just that you should remember to keep it simple.
Don’t lose focus on your target users:
This rule is more applicable to today’s developers because we use so many different apps in our day to day lives that using software becomes a second nature to us and we start developing our software to behave the way we want our software to behave, which can lead to many assumptions and prejudices of user requirements on our part. You’ll only work once to build the software but the user will use it many, many times to help them take care of some important business. Your number one goal should be to make sure that they can accomplish the tasks important to them in most efficient and simple steps. They might be wowed by fancy features the first few times they interact with your software but, in the long run, its efficiency and ease of use will be the only things that will matter.
Making your software mistake proof:
Making assumptions about a user’s requirements is as bad as assuming that all users of your software know what they are doing. Yes, they do know their business and probably know what they want to accomplish but you can’t expect them to always enter the right values in the right fields and chose the right action. But you shouldn’t attribute their mistakes to lack of knowledge, repetition can often create “slip-ups” and if little mistakes create a lot of “fix it” work, then failure isn’t just theirs but your software’s, as well. You know the business rules and you know what mistakes can corrupt the data or corrupt the process–put in the extra effort to edit for those mistakes. Your users may not realize it, or even appreciate it, but you’ll create a more efficient process for them and that should always be your goal.
Software Developers are like people who build roads. Basically, we’re providing a means to get from Point A to Point B in the most direct way, saving our users time and hassles. Remember not to build a scenic road, full of curves and bumps, if you’re building it for drivers who use it to get to work every day!