The decision to rewrite

This account is true to the best of my memory - Douglas Webb, 2016-02-10

On or before 2015-10-03, a decision was made to write the yunity platform code-base from scratch (herein: rewrite) instead of adapting the existing Foodsharing.de code-base (herein: refactor). This decision has endured the test of time despite being made badly.

Pre-WuppDays (before 2015-10-20)

Several active members of Foodsharing.de were present throughout the WuppDays, some as developers and some non-developers. It had been informally decided before the WuppDays that the yunity project should not be too greatly influenced by Foodsharing.de and thus no presentation about the internal workings of Foodsharing.de or it's software was presented. The idea of writing the yunity platform from scratch was implicit. This was intended to allow the greatest creativity and agency of the WuppDays attendees over the project, especially as the yunity project is a distinct project from Foodsharing.de.

First days (2015-10-20 to 2015-10-22)

At the beginning of the first WuppDays, optimism was very high with several members of the group - including developers - having high hopes that a basic, working version of the proposed platform could be functional by the end of the 4 weeks. The first meeting of the developers was fairly relaxed and the open discussion of about 90 minutes resulted in an informal consent to write from scratch using an AngularJS front-end, Django back-end and Postgres database.

Next days (2015-10-23 to 2015-10-27)

Coding went quickly over the next days and working modules were created. Talks about data schema and other technical details continued. Tension began toward the end of the first week with developers finding it difficult to match what they were creating with the moving target of what the yunity platform should be. No detailed product specifications or requirement priorities had been given to the developers as these were simultaneously being discussed and created by other groups. At this point someone suggested the possibility of refactoring the Foodsharing.de code-base.

The refactoring proposal (2015-10-30)

About 10 days in, Kristijan M gave a talk to clarify the situation with the Foodsharing.de code-base. This led to extensive discussions about refactoring the Foodsharing.de code-base (cleaning it up, preparing it for future development) versus writing the platform from scratch. Reasons for refactoring included;

Large, used and usable code-base
Current Foodsharing.de development team familiar with PHP and existing code-base
More rapid improvements for existing foodsharing community in Germany

Reasons for writing from scratch included;

Being able to immediately open-source the code-base (release of the Foodsharing.de code-base at present could present data risks to users)
Moving away from PHP has benefits (easier security, cleaner code)
Starting from scratch could produce a clearer and better designed platform

Next days (2015-10-01 to 2015-10-02)

No decision was made to pursue the refactoring immediately, but the discussion continued. Developers lost some motivation to code with the insecurity of a potential refactor rendering their work meaningless.

Decision to write from scratch (2015-10-03)

Now two weeks into the WuppDays and with the 'refactor/rewrite' question being a major block in the work-flow, the realisation that launching a working model by the end of the period was unlikely. Frustration grew and enthusiasm dropped as no clear decision had been made as to how the development should continue. On or before 2015-10-03, a meeting was called to try and reach a decision the group could have confidence in. Approximately 15 minutes of debate in support of refactoring and rewriting was provided before having a vote. The voting system was influenced by 'systemic consensus', but more specifically;

Only the proposals for rewriting or refactoring were included (no '0' of 'further solutions' control votes were provided)
Each proposal was voted on with a resistance scale of 0 (no resistance) to 10 (high resistance)

Rewriting was decided upon, but the outcome was close with only a little more resistance for refactoring. The feeling in the room was not one of joy at having reached an outcome but melancholy and with a lot of tension in the air.

Since then (2015-10-04 til now [2016-02-10])

The decision to write from scratch has been honored and no one has further investigated the Foodsharing.de code-base to date (2016-02-10). Nothing prevents anyone from trying to explore the code base except for it not being open-source. The decision to write from scratch comes into discussion on a relatively frequent basis not because the decision is still a question, but because it was a great example of where the project could have used a better process and we must learn from it for future.

Learning outcomes

Setting lower expectations may reduce stress.
Providing as much relevant information at the outset is very important.
Decide on product specifications before creating products.
Use an improved systemic consensus method within a decision making framework (as outlined here -> link to framework).