Optimize Software Development: A Developer Perspective

Introduction

Software industry is very creative in developing methodologies and practicing them. And these methodologies create a good framework within which people can work with a discipline and develop quality software. But there are other elements, which can contribute to the quality of development and life of the programmer. It is the motivational side of the developer. You should have better practices to keep it in tact. People are creative when they are happy in what they are doing. Quality of the development work increases when a developer does it with a good mindset. Here we can think of some methods to improve the creativity of the developer. Following are the points I picked up from my software development experience.

1. Have small achievable targets and concentrate only on that during development

Big targets are achievable only through a sequence of small steps. When a developer takes a small step, he does not have to carry the burden of a big target (probably a manager can take it up). When you look at only on a small target, you are well focused to do it. When people target for a big delivery after 3 months, generally people will do relaxed work in the first month, a reasonably tight work during the second month, and over-loaded work in the last month. In a tight schedule, people might not be able to deliver a product with quality.

When you have small targets of 1 day/ half day / 1 hour, you will not be facing this kind of a scenario. These small targets should be self-planned. And you should achieve maturity in setting the correct targets in the course of time. After every schedule, check whether you could achieve the target. If not, have a lighter target next time. If you could achieve your goals in advance, have tighter targets for the next schedule. Have enough relaxation time between your schedules. At the end of the day, you analyze your performance and of course appreciate yourself for doing a great planned work.

2. Document knowledge achieved by a day and share it

This is the era of reusable components. We need to create reusable knowledge too. Even the smallest information you gained, key it down. At your free time, work on these notes and make reusable presentable documents. Share the presentable document with other developers. Appreciate yourself after creating a great reusable and presentable knowledge resource (this is a nice to have in every 3 months). This should be self-driven, and not manager driven.

3. Take the next step when you feel your previous step was correct

Let me explain this with an example. Take an example of compiling a C++ file xyz.cpp and building the application xyz. Let me assume most of the people do this activity in the following way:

1. Directly write the code thinking domain logic and coding logic together.
2. Compile the code.
3. Correct it seeing the code.
4. Build without errors.
5. Test it.
6. Fix the bugs and continue till it reaches a matured level.

Instead of this try doing this:

1. Write down logical steps first and have a clear picture in domain perspective.
2. Do the coding and get convinced that there are no logical or syntax errors.
3. Compile and see minimum (because you verified what you coded) errors.
4. Build & test and face minimum (because you analyzed well your domain requirements) problems.

Basic idea is don't get into a situation where your work is driven by errors. Instead concentrate on prevention of errors. It is something like the proverb "Prevention is better than cure”. While writing your code, assume that there is no testing and you are going to deploy the application directly after the build.

4. Understand domain and identify core requirements and develop test cases for that

After every change, be concerned about the backbone requirements. It is true that you cannot test everything after each change. Instead of that it is better to understand backbone requirements and be concerned about that. Spend some 15 minutes to create a test case.

5. Understand the code in a faster way

Lots of the people try to understand the code completely and later they feel it is very hard to grasp. Instead you need to understand the existing code in a more trickier way. Before you jump into an area, think for a while about "how the system could be?" (the more you can imagine, the more wonderful.. ). I bet most of the time what you imagined will be true in reality. In the beginning, take a small scenario (like view the orders of a particular client). Understand this scenario in the domain perspective. Just think for a while how this could be implemented. Now you are more fit to look at the code.

Second trick is “View the code in an object oriented way”. It can be like this. Pick up a concept from the domain. Look for a related class. Just have an imagination what all functionalities this class might be doing. Now look at the code and you may be wondering to see what you imagined (definitely there will be a lot of things more than your imagination). These things are better than learning code by digging through an ocean of functions. Basic idea is concepts should drive your learning of code instead of code drive your learning of concepts.

Understand small scenario/classes this way and become a master in the course of time.

6. Think in client perspective

Try to be creative and imaginative by seeing yourself in the client's place. By doing this you will be able to give the client a better suggestion when they trouble you with some tough requirements. Develop the ability to visualize things in a client's perspective, which will help you to guide your client in a better manner. If you can propose a better solution to the client's problems, you are placed in a respectable position.

7. Develop negotiating skills

It is good for everyone if you communicate problems/issues very well. Always have analytical figures to convince/negotiate with manager/client in terms of time required for the work. Your communication with statistics helps others to plan their business better. Finish your deal in win-win fashion (a win-win deal gives confidence to both parties to have another deal in the future.)

8. Achieve maturity in Estimation

Always have a buffer for risk factors while you estimate time. Analyze the failures in your estimation. Divide the task and estimate it.

9. Create a favorable environment

You are responsible for other people's behavior on you. This is a great skill to develop. You should be aware of what input will give what output on each people. Definitely you should work for the development of the people around you. You are richer when people around you are skillful. Encourage every good thing your neighbor does. This is how we should develop good culture in the group. Appreciate all good things. Congratulate people on their achievements even if it is small (small + small can be big).

10. Spend some time to analyze your work

Usually programmers never look at the code once they could build the application and could pass through the testing. But a second look might prove very much valuable sometimes. After a 4-hour work, it is ideal to spend 1 hour to find some alternative ways of doing things. Iterate through the code and try to minimize the size of the code. Most useful code in future will be the one with minimum number of lines and straightforward logic.

11. Don't create unnecessary hierarchy in the organization

Long hierarchy is a problem for a big organization. It can create unnecessary pressure on the end developer. As an example, assume a customer asks your CEO "Can you develop feature X in 2 months?" Through the hierarchy chain, it can appear to the developer like this: "You should finish feature X in 2 weeks. For a safer side, we should finish it in 7 days". This is because every person in the chain of hierarchy wants to keep some buffer days to avoid their risk.

12. Improve your listening skills

Listen well and digest the talk as sharp as possible. A patient listener will attract respect from the other side. If you have doubts, frame questions in such a way that you will get the best reply.

13. Use a second person's view

Tell others what you had planned to do and how you did it. Even a person junior to you can point to you some small mistake and their casual comments can be pointers to some hidden things. Similar things are applicable in pre-coding and on coding. Idea behind this is if you let others know about your view or work, it will only get fine-tuned.

14. Keep your words

This is the way you develop trust. Do not promise what you cannot do. Trust is the key for smooth teamwork. It generates a lot of reliability on commitments. Later it becomes the habit of the team. Express your trust in others so that it will encourage them to do things in a more trustable way.

Conclusion

Hope these things will help you to enjoy life with software development.

Happy coding!