8 Coder Facts

Perfect is the enemy of good ~ Voltaire

We always strive for perfection. It’s in our blood, especially as a software developer. Perfection, however, is only an illusion.

Having being a software developer for many years, these are facts about being a developer that we all cannot avoid. The only exception to these facts are codes that are otherwise static and non-changed through time with no future development require. 

1. There are always untested codes

It has never mattered how many units tests you create, there will always be some parts of the code that remains untested. The amount of feature released and code being written is faster than a number of unit tests created. Test those that matter and are critical. Maintenance is at the utmost important for those that matter. As your code grows, the amount of untested code will become larger, and so does codes that are critical to the operation. 

Test those that matter and are critical. Maintenance is at the utmost important for those that matter. As your code grows, the amount of untested code will become larger, and so does codes that are critical to the operation. 

2. There are always un-executed codes

Developers follow a framework and template blindly without understanding reasons behind them, thereby failing to recognize different needs. The usual argument would be to make the code more readable as they look similar to other parts of the code. This, however, is a common pattern misuse. 

Different code and application require different needs. They require different design pattern and solution. Apply each pattern accordingly and when in doubt, ask the question, “which pattern is more useful?”. Document the reason for the pattern usage so that the future developer understood the reason behind the pattern and could change them with more confidence.

3. Documentation always incomplete

Part of the codes will always be questioned and part of it will never be understood without asking the original coder regardless the amount of code documentation. Users will find some parts of the application confusing and they will always ask the same questions regardless the amount of user manual. Management will try to push for time, undermining documentation. Document those that are deemed important and rely on collaboration and communication for the rest. Take notes those that are difficult to understand and common questions thrown by users. The agile methodology works best to help manage this.

Document those that are deemed important and rely on collaboration and communication for the rest. Take notes those that are difficult to understand and common questions thrown by users. The agile methodology works best to help manage this.

4. There are always better ways to refactor

An application architecture and design is a particular view and solution of a problem at a particular time. These views rely heavily on the understanding of the developer about the problem at the time, and the developer skills.

As time goes by, the understanding of the problem will change. A broader view of the problem may emerge. These factors are dynamic and ever changing. Better ways to refactor will always emerge. Instead, ask the question, “How is this model/architecture/pattern useful?” and weight accordingly. Pick the most useful design at the current time.

5. Your code now is the legacy of the future

Ten years from now (should the company still exists and use your code), your code will be seen as incomplete. The next junior developer looking at them will question ‘Why did they do it this way?’ whilst pulling his/her hair out trying to refactor your code as a new feature is to be implemented.

Understand what is valuable at the current time and use them accordingly. Do not dwell too much on one issue as those will change over time. Collaborate with the user to produce the value and find an understanding on what is important.

6. Any code written now is based on incomplete requirements

Requirements created at a point in time are often full of holes. All usage scenarios are never envisioned completely at inception. More scenarios will always be found during development or after code release.

Codes created and written now are based on these incomplete requirements. Use the agile methodology to manage expectations and liaise with your user as regular as possible.

7. Business rules are never complete

Businesses must adapt and change to survive, thrive and win. Create and adjust your code according to the business strategy. A business rule at a particular point in time is a particular solution from a specific point of view at that particular time.

The business environment is complex and changing. These rules will change, and business rules, in essence, were never complete in the first place. Design and architect your code according to your business strategy.

8. My code is better than yours

Software developers are very proud of their code. They tend to become defensive when their works were criticized. They are used to work and solving a problem alone. This is a common occurrence that must be handled before forming a real functional team.

Have a code review in your process.  Pair programming works well in helping junior developers grow. The most important aspect of any code is that for the code giving value to the user. Refer back to the requirement document or interview the user to get the answer. 

 

As developers, we have a responsibility to understand and manage these accordingly. Developers who avoid them will soon found themselves in a corner. They will damage the businesses capability to grow with excuses such as ‘It cannot be done that way, it must be done this way’ or ‘we cannot make that change’.

Each business differs in their strategy to grow. Code and strategize your application according to your business strategy. Never aim for perfection. Aim for good enough and push accordingly.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s