REFACTORY is a socially responsible technology project. It's about coding, but it is also about people.
Each time you show existing code to a developer, he or she always tends towards throwing it all away and restarting from scratch. For most developers it is neither easy nor enjoyable to work on someone else's code, to adapt to a different coding style. But rewriting is almost never the best choice; especially when the project, although it needs maintenance, is actually working.
We like working on existing code. We like decoding the underlying logic, which often exists - and it is quite sound - even when it's not that clear at the beginning. We like to improve iteratively, treating the project like a living organism which needs love and care to be able to grow and respond to new requirements. We feel this way of working shows respect for the project, for the original developers, and for the customer who should not have to suffer inconveniences or any additional costs due to developer’s laziness.
Make communication easier
The main problems encountered in developing a software project are not of a technical nature, but of a human one: they are caused by difficulties in communication. Most developers see users as "enemies" who always just complain about things. This is not the case: we are all people who love their job and try to improve it.
We enjoy finding solutions to make communication easier. Specifications should be short, funny, readable and understandable, so that they are a pleasure and not a chore to read. Physical or virtual meetings between the team and the customer should be frequent - every week, or two weeks at most - to discuss the progress and plan the next steps together. Documentation relating to the project should be simple, always updated, easy to access and shared with everyone involved so everyone knows where we are at any given time during the project's development..
Simplify the development
Many projects fail because they are too big. They grow too big for (the wrong) commercial reasons or - again - due to laziness that prevents one from learning details and extracting micro-tasks which can be completed quickly and bring immediate advantages.
We like to break down big projects into smaller projects, so that development can be iterative (first a tricycle, then a bike, then a scooter, then a car...) and the project can always evolve in the right direction.