20 Golden Rules to Learn in Software Development

If you are a developer then you might have experienced a few things in your team…

• Sometimes it’s difficult for you to make small changes in code.
• You break the functionality of software due to the changes you made in your code.
• You introduce a new bug while fixing the other one.
• You implement some unnecessary code which is not required in your application.
• Adding a new feature is difficult for you because of the complicated code.
• The never-shipping product
• You remove some code from your application and rewrite it from scratch.

You may have wished to cry in these situations if any one of the above statements is true for you.

All the above problems are common that happens in most of the development team. 

There are a lot of small factors responsible for damaging the developer’s project. You won’t see the effect immediately and maybe not for a year or even more. Most of the time we do not pay attention to these small factors, and we consider that it won’t affect our project badly but these small factors can harm your project in the long-term. 

In development when you start working on a project everything seems to be working fine but as time goes on, the complexity of your project gets increases and you start ignoring some small factors in your application. Later these small factors create a big issue and your own project becomes a nightmare and a horror story for you. 

These issues can be avoided if you learn some fundamental laws of software and if you understand the mindset of great developers. We are going to discuss this topic in detail it will help you in taking the right decisions in your development journey. You will be able to keep your software manageable and as simple as possible. 

1. Understand the Purpose of Your Software

Before you start working on a project understand the main goal or the purpose of your software. What’s the purpose of your software??….to help people. If you look around yourself you will find many applications you are using in your day-to-day life and all these applications have a single purpose….to help people.

The purpose of the software is not to show off how intelligent you are.

-Max Kanat-Alexander, Code Simplicity

Always remember the above-written quote. Great developers never consider the purpose of software showing off how clever they are in writing the code for a project. You will be building a complex system or a bad application if you don’t understand the purpose of the software. A bad application doesn’t help people that much. 

When you start working on a project ask a single question to yourself “How can we help?” and then the answer will help you to understand the main goal of your application. Also, in this way, you will be able to prioritize feature requests in your application. 

2. Understand The Goals of Software Design

Keep in mind only two things to understand the aim of your software design. Your design should be as simple as possible and it should be helpful for other users. 

Many times in software development when it’s hard to create or modify something, developers shift their focus on making things “just work” and they spend less time focusing on helping users. Every programmer is a designer and being a developer you need to understand the goal of software design. 

The goal of software design is to make the developer’s job as easy as possible. This way, developers will be able to focus on other important things that matter in an application. Understanding the aim of your software design will help you to create an application that helps users and it will be continued for a long time. 

3. Understanding Your System and Your Work

Before you start working on a project make sure that you fully understand your system, its behavior, functionality, features, and tools you’re working with. If you don’t understand your system and it’s working properly then you will be making your job more difficult and you will be heading towards building a complex system.

Also, a misunderstanding leads to further misunderstanding and that becomes a vicious cycle in an application. These misunderstanding only increases complexity in your system and this complexity can harm your project very badly in the future. If a developer understands their system properly, they will also understand what they need to do in their application. 

Good developers know what they need to do in their application whereas bad developers don’t know what they’re doing in an application just because they don’t understand the system and its work properly. 

4. Follow Simplicity

Being a developer how would you feel if you need to work on a complex code where you don’t understand what a specific bunch of code is doing in the application. How would you continue with it and perform your own task if you don’t understand the code which is already implemented in the codebase? Surely it’s frustrating for any developer and also it’s difficult for them to work on these kinds of systems.

Being a developer your aim should be to reduce the complexity of the system not to create it, not to increase it. If you think that writing complex code makes you a smart and intelligent developer then you’re totally wrong. It’s a wrong mindset and you should never do this mistake in software development. A good developer always keeps the code as simple as possible so that other developers can understand it and work on it.

Remember that in software development complexity has nothing to do with intelligence, simplicity does. The simplicity of your code shows how good a developer you’re, not complexity. 

A good developer creates things that are easy to understand and easy to change. Remember that developers who are new to your code, they have to learn everything about it. So before you write some complex code just ask one question to yourself “Do I want other developers to understand this code, be happy and continue to work with it, or do I want them to be confused and frustrated?”.

Now you might be asking one question to yourself…“How simple do you have to be?”

The answer is…stupid, dumb simple.

5. Controlling The Complexity

In software development, most of the projects get failed due to the complexity of the system. You start with a simple project but as time goes on you keep adding features to it and after a couple of months when you look back at your own code you realize that you have written a lot of unnecessary code and you have built a much more complex system. You realize that you have expanded a few things in your software for no reason. 

Your problem doesn’t end here. Due to the complexity, you become the victim of a lot of bugs in your system. You start fixing these bugs without realizing that it’s badly affecting the other parts of your application. Fixing one bug is introducing a new bug and now you realize that it’s difficult to make even a small change in your system. 

In the end when you realize it’s time-consuming and things are now out of control. You make a final decision to fix everything: Rewrite the code from scratch. 

The above story is one of the most common horror stories in programming. Most of the developers face it and become victims of it. So the question is…how to avoid this problem?

First, you need to know the exact purpose of your software. Second, you need to be as simple as possible in every single piece of code you write. Third, when a new feature is requested, evaluate them based on your application purpose and question them. 

Also, being a developer your behavior should be resistant to change. Do not make any change or add some features until or unless it’s not much needed. You will prevent yourself from writing unnecessary code in your application. 

6. Maintenance

Most of the time developers do not pay attention to the maintenance of the code. They focus on quick coding and fast shipping of the product and ignore the importance of code maintenance. No matter how small or large applications you build, you will always have to implement a few changes in your application. 

Every feature you have built in your application and every change you have made in your application requires maintenance. So keep in mind that being a developer your job is not just implementing the features or changes in your application. You also need to pay attention to the future maintenance of code or changes in your application. 

Simplicity and complexity, both of the factors are mainly responsible for code maintenance. The more simple code you write for any piece of software the easier it would be to maintain it. A complex system requires more effort for maintenance. 

It is more important to reduce the effort of maintenance than it is to reduce the effort of implementation.

— Max Kanat-Alexander, Code Simplicity

7. Be Consistent

The simplicity of your system depends a lot on consistency. Inconsistent code is always hard to understand and developers need to put more effort into learning and understanding it. 

If you have followed a way to do something in one place then follow a similar way in every place. For example: In your application, if you name a variable ‘variableOne’ then all of your variables should be named that way (variableTwo, variableThree etc. not variable_three). 

8. Prioritizing

In your programming journey, you will have many options for a certain thing or a specific problem. There you will have to make a decision about choosing the best option. Now the question is… how to make a decision about your software? How to prioritize the things and what are some factors you need to consider making a better decision. 

In the book Code Simplicity, it is explained very well with some equation…

• The desirability of a change (D): Measurement of change you want in your system to happen (How much?)
• The value of a change (V): Measurement of value the change offers (How much?). How much does it help the users?
• Required efforts to perform the change (E): Measurement of work you need to do to fulfill this change (How much?)

Below is the equation to prioritize the thing and make the decision. 

D=V/E

The desirability of any change is directly proportional to the value of the change and inversely proportional to the effort involved in making the change. 

— Code Simplicity

The above line will help you to make a better decision. Choose the options that require less effort but bring a lot of value. Ignore the options that require more effort but bring a little value. 

9. Solving Problems

To solve the problem you need to first understand the problem. You should know what exactly is being asked and make sure that you clear all the confusion. 

You can follow the Feynman technique to understand a hard problem. In this technique, you need to explain your problem to someone else in simple terms.

If you can’t explain something in simple terms, you don’t understand it.

 — Richard Feynman

Once you understand the problem, make a plan, and take the action. 

Looking at the big whole problem can scare you, so it’s good to divide the problem into various small tasks. Once you divide the task, solve each sub-problem one by one, and then merge it to get the complete solution.

10.  Do Not Chase Too Much Perfection

One of the common mistakes most developers make is that they want to make everything too perfect in an application. Each and every feature they want to build with perfection and because of this, they tend to plan everything in detail from the beginning. Most of the time their focus gets shifted to making things perfect only instead of solving the problem and helping people with their software. 

“Perfect is the enemy of good.”

 — Voltaire

When developers start working on a project they start thinking about each and every small detail or feature they want to build in their system. Every time they make some assumptions, prediction, and they ask a single question to themselves “What if“. They think about their software from a future perspective, and they predict everything according to that. 

For any developer, the imagination of the project from a future perspective becomes the main reason to build everything too perfect. Developers think that their project has to be perfect as they imagined it. Developers do not pay attention to certain things but seeking too much perfection can be harmful to them. Being a developer, if you’re chasing too much perfection in your project then below are the things that can happen later with you…

• You will be writing unnecessary code, thinking from a future perspective.
• Complexity will be increased due to the unnecessary code.
• You will be too generic.
• You will be missing deadlines.
• The complexity of your project will introduce many bugs in your software.

None of the developers wants to face all the above things. So being a developer what you should do in this case…

Start small, improve it, then extend.

Let’s consider the example of implementing a calculator in a system…

1. Make a plan to build a system that does only addition and nothing else.
2. Work on your plan and implement it.
3. Make improvements in your existing system so that you can add other operations.
4. Now make a plan for subtraction and repeat steps 2 and 3.
5. Make a plan for multiplication and repeat steps 2 and 3.
6. Make a plan for division and repeat steps 2 and 3.

Do not chase too much perfection in your software. Good enough is fine. 

11. Predictions

Thinking from the future perspective we write a lot of unnecessary code and we become too generic in our application which is not good. In software development, you can’t predict the future, so no matter how generic your solution is, you won’t be able to fulfill the actual future requirements. 

Most of the time those requirements won’t be needed in the future and you will end up with writing unnecessary code and increasing the complexity of your system. A more complex system becomes a burden on a developer and also it can destroy your application as well.

So it’s good not to predict the future and implement something which isn’t needed yet. Be only as generic as you know you need to be right now.

12. Don’t Reinvent The Wheel.

Do not implement something, if it already exists.  

A lot of developers spend their time building or creating something which already exists on the portal. This is one of the common mistakes and it just consumes the developer’s valuable time. Instead of reinventing the wheel, they can spend their time on something else which is more important. 

Now the question is…when it’s okay to reinvent the wheel? Below is the answer…

• Implement something which doesn’t exist yet.
• If all the existing “wheels” are built on bad technologies and it’s not capable to fulfill your needs.
• Lack of maintenance in existing “wheels”

13. Resistance

Say no to changing requests until or unless it’s not important. You will be making mistake if you will say ‘yes’ to each and every request and if you will start working on each one of them.

You will be adding more code to your application and that will increase the complexity of your system. So it’s good not to make unnecessary changes in your software.

Now the question is….which changing request we need to implement in our software?

Go back, remember your software purpose, and the simple equation in the prioritizing section.

14. Automate the Repetitive Tasks

One of the most frustrating things in software development is working on some repetitive tasks. The repetitive task just consumes your additional time and it’s a foolish thing to work on it again and again. When you realize that you are doing something, again and again, set them up, automate it and forget about them. If you can automate something and if it’s saving your valuable time then automate it.

15. Code Measurement

Do not measure the quality of software based on the number of lines of code. Writing more number of lines of code doesn’t make you a great developer. If you think that a thousand lines of code are always a sign of a big software or application then it’s not true in every case. In most cases, something goes wrong with the software design. 

If you pay attention carefully then you can solve a lot of problems in a little bunch of code. Most of the simple solutions in an application don’t require a lot of code. Less code makes your application simpler but you also need to remember that you do not write very fewer lines of code.

If you focus on writing very fewer lines of code then you may fall into the trap of writing clever code that is hard to understand for other developers. So you need to find a balance and you need to write only that much amount of code that is easy to understand and easy to read.

16. Productivity

A lot of developers measure their productivity with the number of lines of code they write in an application. Remember that in software development you can increase productivity if you throw unnecessary code from your codebase. 

Your goal shouldn’t be writing more code and increasing complexity. You should think about removing unnecessary code and making things as simple as possible. This golden rule is not just going to increase your productivity, but also it will increase the productivity of other developers.

17. Test Each Part of The Code

In software development always add logging in an early stage of implementation. You will be saving a lot of time and you will find the problems easily in your application. 

Now consider a scenario that you have written a simple if-else block in your application. You give the input to the software and that enters inside the if block. You test it and you commit the code to source control. From your end it’s done but what about the else block? When your software will be shipped to the production, it will generate an error. 

To avoid such kind of issue test your code properly. Execute all new lines at least once and test each and every part instead of testing the whole application in the end. Keep testing the parts of the application when you’re implementing it. You might be thinking that it’s time-consuming to test each part but if you really want to prevent yourself from a big issue and if you want to save your valuable time then surely you should test each part of the application during the implementation.   

When you see bugs in your application, reproduce it. Do not guess the source of the bug and fix it based on your assumption. Apply fixes when you see it with your own eyes. Be reliable and make sure that your code is properly tested before you commit that to the source control. 

18. Do Not Underestimate

Everything takes longer than you think. 

This is one of the most important and golden rules you should remember in software development. 

Most of the developers make one common mistake in software development. They underestimate the time and efforts needed to develop a small amount of code or implement a feature. You will be missing the deadlines if you underestimate both of the things. 

For correct estimation, you can break the big task into smaller tasks. Smaller tasks are easy to estimate and even if you guess it wrong then there will be only a slight difference between your own estimation and the correct estimation. This won’t affect your software badly. 

19. Documentation and Commenting

When most of the developers comment on a piece of code they think that they need to mention “what code is doing”. This is wrong. If you need to mention this then surely your code is not readable and you need to make it easier and simpler. 

When you’re unable to make code simpler then write the comment and explain the complexity of it. The real purpose of the comment is to mention “Why” you did something not “What” the code is doing. Commenting on the code help other programmers to continue with the software and work on it. If you don’t do this then developers can remove the important parts from your code. 

You also need to pay attention to the documentation. Your software’s architecture, module and its components everything should be mentioned in the documentation. Documentations are helpful to see the high level of a picture of your software and it would be easier for new developers to work on it if they understand the complete architecture of the software. They can make mistakes if they won’t have any clue about the different parts or the complete architecture of the application. 

20. Don’t Be a Superman

A lot of times it happens that we overestimate our potential to complete some task. It’s good to be confident about your potential but it’s not good to become overconfident. Many times it’s better to quit rather than being a superman and showing that you can do something. Instead of making things perfect and fulfilling your task, you will make blunder mistakes and you will screw up everything. 

Suppose you estimate that a task can be completed in two hours. You started working on it and it’s been four hours but you’re still only a quarter of the way done. Here you need to quit the task instead of thinking that “I shouldn’t give up, I have already spent four hours on it”

You are determined to complete the task but sometimes you really need to think practically and ask questions to yourself “is it better to quit the task with short damage or it’s better to continue with it making a blunder mistake in the end?”

Don’t be obsessive. Know when to quit and don’t hesitate to ask for help.