When I first began developing software applications, I used to make some novice mistakes. The yearning to get better led me to discover where I was going wrong and today I have gained an understanding of some best practices for effective software development and I am super excited to share it here. I am confident that after reading this post you'll like it too. I have broken down these practices into the following headings: Requirements Analysis, Software Design, Implementation, User Interface Design and Project Management.
What should you do when gathering the requirements of your project and writing out your specification? Here are some three key principles or guidelines to keep in mine. Going into the details of software requirements is beyond the scope of this post.
1. Be unambiguous and concise
Your requirements should be brief and to the point. Avoid listing requirements that are uncertain and difficult to understand. Note that your role in a project could be to design an SRS document for some developers to use and so you would not want developers calling you up to explain one or more requirements.
2. Be precise
A requirement such as “The system should be fast” is not precise enough. The question coming up is “How fast should it be?”. A better way would be to state that “The system should operate at the speed of light” or “The application should return search results within 5s”. By being precise, during testing it can easily be checked if the requirement is fulfilled.
3. Avoid BRUF (Big Requirements Up Front)
Software development is a continual process. Requirements change and new requirements up come. Clients usually do not even know all what they want at the outset of a project. I was working with a client ones and in each meeting, he had new requirements for his app. Trying to have an exhaustive list of requirements before moving to the next phase of a project can be a real time killer (waterfall model discouraged). Therefore, your first set of requirements just have to be good enough and evolved over time. Once you've specified your first set of requirements, you can move on to the next phase of the project and work in iterations.
Your software requirement specification is used as input in this phase. Below are a few points to keep in mine specially if you are using an object-oriented approach.
1. Aim for low coupling/high cohesion
In developing your class diagrams, aim for low coupling/high cohesion. Coupling is a measure of independence of a module or object. Loose coupling means that different system objects have loose or less reliance upon each other. Hence, changes in one object would have a limited effect on other objects. Cohesion refers to the level that a class contains focused and related behaviors. This means that if some kind of change is required in the software, all the related pieces are found in one place.
2. Model only features that really need modeling
Is it every aspect of the software that you need to model? no. Do you need to draw sequence diagrams for every possible scenarios and even for the simplest features? no. The purpose of design is to improve clarity and understanding. So in order not to waste so much time in this phase, focus on the main features and each time you need clarity add some more models.
3. Take advantage of the power of object orientation by making use of paradigms such as abstraction, polymorphism, inheritance and encapsulation (APIE) where necessary.
If you want to dive deep into object-oriented analysis and design, I have included a listing of some great books in this post Good IT Books. Check course number 21 in the post.
Programming is fun. So what can you do to make it funner?
1. DRY (Don't Repeat Yourself)
Do not copy and paste unchanged blocks of code from one place to another. Try as much as possible to avoid duplication in code, database schema's, documentation etc. Implement a particular functionality ones and use anywhere else.
2. YAGNI (You Ain't Gonna Need It)
Don't write speculative code or implement some functionality you think may be needed in the future. Solve problems at hand and leave tomorrow's problem for tomorrow. Remove all unnecessary codes
3. Avoid very long methods
If you have a method that is already getting to 400 lines or even 1000, begin to think about breaking it down.
4. Avoid using very short (or long) identifiers
Your variables should be descriptive. A descriptive variable is self-explanatory and thus eliminates unnecessary comments. Also, avoid using very long names for variables. Shorter names are important for code readability and maintainability.
5. Avoid pointless comments
Don't include unnecessary comments in your codes. For example,
int buf; // This creates an array of integer called buf of size 10
The purpose of comments is to improve readability of your code and to help you remember what you did months after. Therefore, portions of codes that are obvious don't really need comments.
User Interface Design
When thinking about user interface design, it is important to keep the following guidelines in mine.
The interface should be relatively easy to use. I have found that users are happy if they can use your software without the need to read any documentation or help document. Sit back and take a look at your interface and imagine yourself to be some user around the world and examine how easy it is for you to use the application.
Affordance is a term used to refer to an attribute of an object that allows people to know how to use it. At a very simple level, to afford means “to give a clue.” icons should be designed to afford clicking, scroll bars to afford moving up and down, buttons to afford pushing. Using buttons for something else may turn to confuse users. For example, the typical pdf icons placed beside documents on the web usually tells the user that the document is a pdf. Using it to mean something else can lead to confusion
Ergonomics is traditionally the study of the physical characteristic of interaction. how the controls are designed, the physical environment in which the interaction takes place and the layout and physical qualities of the screen. Here, keep the following in mine:
- Arrangement of controls and displays should be appropriate. Inappropriate placement can lead to inefficiency and frustration.
- The use of fonts and color choices should be appropriate to improve readability and health issues. A good interface should not strain the user's eyes. The colors used should also correspond to common conventions and user expectation. Moreover, the interface should be flexible and customizable giving users the possibility to choose their font-sizes, color choices etc that suits their tastes.
If you want to become a user interface expert, I recommend you take a course on human computer interaction. Course definition according to ACM/IEEE is “Human-Computer Interaction is a discipline concerned with the design, evaluation and implementation of interactive computing systems for human use and with the study of major phenomena surrounding them”. I have included a listing of some good books in this post Good IT Books. Check course number 30 in the post.
It is very important to develop the habit of creating a project plan to manage your projects, whether it's your personal project or some client project. I have seen a lot of developers working without a plan which is not a good practice. Some benefits of a project plan include:
- They help track progress
- They focus the team on the objectives
- They help you get better
It is important to make your project plan as simple as possible. Actually the focus should not be on how detailed a plan is but on how effective it is to help you achieve your goals. The level of details of a particular plan depends on the project you're working on or organization you're working for. Going into the details of project management is beyond the scope of this article but as usual there are many good books out they that can bring you up to full speed.
I hope you found this post informative. It was really fun writing this post. Please share it with all your friends. Feel free to share your thoughts in the comments. Let's go agile. Cheers.