Usually as developers we are forced to implement functionalities over legacy code that wasn’t ever designed to support them. We have time constraints, pressures and last minute changes that push us to make ugly code.  It is not always the fault of an external factor, sometimes we begin a project with a new technology, language program or just simply with an application that we do not know well enough, and we make big mistakes.

Mistakes are going to happen; bugs, architecture flaws, design limitations, these are present in any project. As developers we intend to minimize them by applying best practice techniques, collaborative work and so forth. But at the end of the day what works best against mistakes is experience.  Making mistakes is the best way to avoid them in the future.

At the end of the day what best works against mistakes is experience

It is common in the lasts steps of finishing a project to think something along the lines of: „I shouldn’t have done it this way, my life will be easier if I didn’t“. When working for an external client you must carry on and try to patch your mistake to finish the project, because you need something functional in short. But other times you are lucky and you can afford deep refactor or are able to throw away the mess you made and begin again from scratch, this time doing it right.

Working at PUSHTech™ had the opportunity to make mistakes, patch them and get rid of them through refactor, even reimplementing functionalities to better fit new requirements as the project grows. Applications shouldn’t just work, they need to work well, they need to be smooth, consistent and reliable. The source code needs to be clean and maintainable, it’s functionalities scalable and modular that is in the mind of the developers from the very beginning.

Some non-technical people try to measure how well a developer performs based on the amount of code that they are capable of generating, and the programmers response to this (with which I agree) is clear: “on a good day a good developer deletes code“. The requirements of our projects are so variable and marked driven nowadays that trying to predict what will be needed is very much like gambling. Developers just try to make the base architecture as feature agnostic as possible and then implement the currently required features over it. After a while new features are added to the application and build over the base or on top of other features. The new features are commonly just applied as patches to the previous ones, because of the feature agnostic architecture and the best practices used by programmers, these patches are integrated very smoothly and almost without consequences. Almost means that nothing is perfect and after adding a bunch of new features and removing old ones the code begins to be less clean and maintainable, When that happens it’s a call for refactor.

In a good day a good developer deletes code

Frequent refactor in the lifetime of a project means a consistent well formed code and helps to avoid the accumulation of bugs and limitations that come from difficult to maintain code. Most refactors consist of deleting code by making better abstractions of the features and implementing them in a more code reusable way.

In general, less code means less possibilities to generate bugs.

Sometimes a refactor comes from the release of a new library, which solves or helps to solve the same problem our application is trying to do. Using well tested third party libraries helps to avoid making mistakes. Letting a third party take care of the specifics of some common problems helps the developers focus on whatever makes their application different. With the Android and iOS SDKs PUSHTech™ tries to help developers to write better and more clean code in their apps, while we also use other well reputed libraries to ensure our code has the best quality standards.

With the Android and iOS SDKs PUSHTech™ ries to help developers

It’s really great that the PUSHTech™ philosophy lets us, the developers, prioritise the quality standards over „quick“ development. I think that this is the difference between a successful project made to endure and one doomed to sink in its bugs and limitations.

¿When was the last time you refactored your code?