ਹਰ ਨਵਾਂ ਪ੍ਰੋਜੈਕਟ ਇੱਕੋ ਜਿਹੀ ਲਾਲਚ ਦਿੰਦਾ ਹੈ: ਐਡੀਟਰ ਖੋਲ੍ਹੋ, ਇੱਕ ਫਰੇਮਵਰਕ ਚੁਣੋ, ਅਤੇ ਟਾਈਪ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰੋ। MaxOS ਲਈ, ਸਿਰਜਕ Max Paardekam ਨੇ ਉਸ ਖਿੱਚ ਨੂੰ ਬਹੁਤ ਡੂੰਘਾਈ ਨਾਲ ਮਹਿਸੂਸ ਕੀਤਾ। ਕੁਝ ਹਫ਼ਤੇ ਪਹਿਲਾਂ, ਇਹ ਪ੍ਰੋਜੈਕਟ ਸਿਰਫ਼ ਉਹਨਾਂ ਦੇ ਨੋਟਸ ਵਿੱਚ ਖਿੰਡੇ ਹੋਏ ਵਿਚਾਰਾਂ ਵਜੋਂ ਸੀ। ਉਹਨਾਂ ਦੀ ਤੁਰੰਤ ਪ੍ਰਤੀਕਿਰਿਆ Cursor ਦੇ ਅੰਦਰ TypeScript ਲਿਖਣ ਵਿੱਚ ਘੰਟੇ ਬਿਤਾਉਣਾ ਸੀ, ਤਾਂ ਜੋ muscle memory ਅਤੇ autocomplete ਦੀ ਮਦਦ ਨਾਲ ਗਤੀ ਬਣਾਈ ਜਾ ਸਕੇ। ਉਹਨਾਂ ਨੇ ਇਸ ਦਾ ਵਿਰੋਧ ਕੀਤਾ। ਐਪਲੀਕੇਸ਼ਨ ਕੋਡ ਦੇ ਬਜਾਏ, ਉਹਨਾਂ ਨੇ ਕੁਝ ਅਜਿਹਾ ਤਿਆਰ ਕੀਤਾ ਜੋ ਕਿ ਬਹੁਤ ਦੁਰਲੱਭ ਅਤੇ ਨਾਜ਼ੁਕ ਸੀ: ਇੱਕ ਮੁਕੰਮਲ architecture।

ਉਹ ਫੈਸਲਾ ਪਹਿਲਾਂ ਇੱਕ ਰੁਕਾਵਟ ਵਾਂਗ ਮਹਿਸੂਸ ਹੋਇਆ। ਜਦੋਂ ਟੂਲ ਤਿਆਰ ਹੋਣ ਅਤੇ boilerplate ਸਕਿੰਟਾਂ ਵਿੱਚ ਇੰਸਟਾਲ ਹੋ ਜਾਵੇ, ਤਾਂ ਡੱਬੇ ਅਤੇ ਤੀਰ ਬਣਾਉਣ ਲਈ ਰੁਕਣਾ ਬੇਤੁਕਾ ਲੱਗ ਸਕਦਾ ਹੈ। ਪਰ MaxOS ਕੋਈ ਹੋਰ ਸਧਾਰਨ Electron wrapper ਨਹੀਂ ਬਣ ਰਿਹਾ ਜੋ ਕਿਸੇ web view ਦੇ ਆਲੇ-ਦੁਆਲੇ ਹੋਵੇ। ਟੀਚਾ ਕੁਝ ਅਜਿਹਾ ਬਣਾਉਣਾ ਹੈ ਜੋ ਵਰਤੋਂ, refactoring, ਅਤੇ ਵਿਸਥਾਰ ਦੇ ਕਈ ਸਾਲਾਂ ਤੱਕ ਟਿਕ ਸਕੇ। ਇਸ ਤਰ੍ਹਾਂ ਦੀ ਉਮਰ ਵਾਲੇ ਸਿਸਟਮਾਂ ਨੂੰ ਤੇਜ਼ ਸ਼ੁਰੂਆਤ ਨਾਲੋਂ ਕੁਝ ਡੂੰਘੇ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਉਹਨਾਂ ਨੂੰ ਪਹਿਲੇ import statement ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਸੁਮੇਲਯੋਗ ਸੋਚ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

IDE ਕਿਉਂ ਇੰਤਜ਼ਾਰ ਕਰ ਸਕਦਾ ਹੈ

ਆਧੁਨਿਕ ਡਿਵੈਲਪਮੈਂਟ ਵਾਤਾਵਰਣ ਯੋਜਨਾਬੰਦੀ ਅਤੇ ਅਮਲੀ ਰੂਪ ਦੇਣ ਵਿਚਕਾਰਲੇ ਫਰਕ ਨੂੰ ਮਿਟਾ ਦਿੰਦੇ ਹਨ। Cursor ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਦੇ AI-ਸਹਾਇਤਾ ਪ੍ਰਾਪਤ ਐਡੀਟਰ ਇੱਕ ਕਮੈਂਟ ਤੋਂ ਪੂਰੇ components ਤਿਆਰ ਕਰਨਾ ਸੰਭਵ ਬਣਾਉਂਦੇ ਹਨ। ਫੀਡਬੈਕ ਲੂਪ ਤੁਰੰਤ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਇੱਕ UI ਨੂੰ ਸਾਹਮਣੇ ਆਉਂਦੇ ਦੇਖਣ ਦਾ dopamine ਅਨੁਭਵ ਬੇਮਿਸਾਲ ਹੁੰਦਾ ਹੈ। Paardekam ਨੇ ਬਿਲਕੁਲ ਇਸੇ ਅਨੁਮਾਨ ਨਾਲ ਸ਼ੁਰੂਆਤ ਕੀਤੀ ਸੀ: ਉਹਨਾਂ ਦੀ ਜ਼ਿਆਦਾਤਰ ਸ਼ੁਰੂਆਤੀ ਊਰਜਾ ਸਿੱਧੇ ਤੌਰ 'ਤੇ TypeScript ਫਾਈਲਾਂ ਵਿੱਚ ਜਾਵੇਗੀ। ਫਿਰ ਵੀ, ਉਹਨਾਂ ਨੇ ਹੌਲੀ-ਹੌਲੀ ਉਹਨਾਂ ਦਿਨਾਂ ਨੂੰ ਸ਼ੁੱਧ ਡਿਜ਼ਾਈਨ ਕੰਮ ਵੱਲ ਮੋੜ ਦਿੱਤਾ।

ਕਿਸੇ ਵੀ ਇਕੱਲੇ ਬਣਾਉਣ ਵਾਲੇ (solo builder) ਲਈ ਇਹ ਇੱਕ ਮੁਸ਼ਕਲ ਮੋੜ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਹੀ ਆਪਣੀ ਪੂਰੀ ਇੰਜੀਨੀਅਰਿੰਗ ਟੀਮ ਹੁੰਦੇ ਹੋ, ਤਾਂ ਡਾਇਗ੍ਰਾਮ ਟੂਲ ਜਾਂ ਟੈਕਸਟ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਬਿਤਾਇਆ ਹਰ ਘੰਟਾ ਪ੍ਰੋਜੈਕਟ ਲਾਂਚ ਕਰਨ ਤੋਂ ਚੋਰੀ ਕੀਤਾ ਗਿਆ ਘੰਟਾ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ। ਪਰ ਸ਼ੁਰੂਆਤੀ ਕੋਡ ਅਕਸਰ ਤਰੱਕੀ ਦੇ ਰੂਪ ਵਿੱਚ ਇੱਕ ਦੇਣਦਾਰੀ (liability) ਹੁੰਦਾ ਹੈ। ਇੱਕ ਚੱਲਦੇ prototype ਦੀ ਨਵੀਨਤਾ ਜਲਦੀ ਖਤਮ ਹੋ ਜਾਂਦੀ ਹੈ ਜਦੋਂ ਹਰ ਨਵਾਂ ਫੀਚਰ ਪਹਿਲੀ ਦੁਪਹਿਰ ਦੌਰਾਨ ਬਣਾਏ ਗਏ ਅਨੁਮਾਨਾਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਕੰਮ ਕਰਨ ਦੀ ਮੰਗ ਕਰਦਾ ਹੈ। ਆਪਣੇ ਆਪ ਨੂੰ ਐਡੀਟਰ ਤੋਂ ਦੂਰ ਰੱਖ ਕੇ, Paardekam ਨੇ ਉਹ ਇਕਲੌਤੀ ਸੰਪਤੀ ਪ੍ਰਾਪਤ ਕੀਤੀ ਜੋ ਸਮੇਂ ਦੇ ਨਾਲ ਵਧਦੀ ਹੈ: ਸਪਸ਼ਟਤਾ।

ਫੀਚਰਸ ਨਹੀਂ, ਸਿਸਟਮਾਂ ਵਿੱਚ ਸੋਚਣਾ

ਇਹਨਾਂ ਹਫ਼ਤਿਆਂ ਦੌਰਾਨ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਤਬਦੀਲੀ ਤਕਨੀਕੀ ਨਹੀਂ ਸੀ। ਇਹ ਬੌਧਿਕ (cognitive) ਸੀ। ਸਾਫਟਵੇਅਰ architecture, ਜਦੋਂ ਇਸਨੂੰ ਗੰਭੀਰਤਾ ਨਾਲ ਲਿਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡੇ ਦੁਆਰਾ ਪੁੱਛੇ ਜਾਣ ਵਾਲੇ ਸਵਾਲਾਂ ਨੂੰ ਬਦਲ ਦਿੰਦਾ ਹੈ। Paardekam ਨੇ feature mindset ਨਾਲ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਦੇਖਣਾ ਬੰਦ ਕਰ ਦਿੱਤਾ। ਉਹ ਹੁਣ ਇਹ ਨਹੀਂ ਪੁੱਛ ਰਹੇ ਸਨ ਕਿ ਇੱਕ ਖਾਸ ਸਮਰੱਥਾ ਨੂੰ ਕਿਵੇਂ ਜੋੜਿਆ ਜਾਵੇ। ਇਸ ਦੀ ਬਜਾਏ, ਉਹਨਾਂ ਨੇ ਇੱਕ ਵਧੇਰੇ ਔਖੇ ਸਵਾਲ ਦਾ ਸਾਹਮਣਾ ਕੀਤਾ: ਕਿਹੜਾ ਅੰਡਰਲਾਈਂਗ ਢਾਂਚਾ ਹਰ ਭਵਿੱਖੀ ਸਮਰੱਥਾ ਨੂੰ ਜੋੜਨਾ ਆਸਾਨ ਬਣਾਏਗਾ?

ਉਹ ਫਰਕ ਮਹੱਤਵਪੂਰਨ ਹੈ। Feature mindset ਸਾਫਟਵੇਅਰ ਨਾਲ ਇੱਕ to-do ਲਿਸਟ ਵਾਂਗ ਸੋਚਦਾ ਹੈ। ਤੁਸੀਂ ਪਹਿਲਾਂ ਸਰਚ ਲਾਗੂ ਕਰਦੇ ਹੋ, ਫਿਰ ਨੋਟੀਫਿਕੇਸ਼ਨ, ਫਿਰ ਇੱਕ ਐਕਸਪੋਰਟ ਬਟਨ। ਇੱਕ systems mindset ਪੁੱਛਦਾ ਹੈ ਕਿ ਕਿਵੇਂ ਸਰਚ, ਨੋਟੀਫਿਕੇਸ਼ਨ ਅਤੇ ਐਕਸਪੋਰਟ ਇੱਕੋ data model, ਇੱਕੋ event bus, ਅਤੇ ਇੱਕੋ permission layer ਸਾਂਝੀ ਕਰ ਸਕਦੇ ਹਨ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਵਾਕ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਉਸਦੀ ਵਿਆਕਰਣ (grammar) ਨੂੰ ਡਿਜ਼ਾਈਨ ਕਰਨਾ। ਸ਼ੁਰੂਆਤੀ ਲਾਗਤ ਜ਼ਿਆਦਾ ਹੈ। ਇਨਾਮ ਇਹ ਹੈ ਕਿ ਭਵਿੱਖ ਦਾ ਕੰਮ assembly ਵਾਂਗ ਮਹਿਸੂਸ ਹੋਣਾ ਬੰਦ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ composition ਵਾਂਗ ਮਹਿਸੂਸ ਹੋਣ ਲੱਗਦਾ ਹੈ।

ਇਹ MaxOS ਵਰਗੇ ਪ੍ਰੋਜੈਕਟ ਲਈ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਜਿਸਦਾ ਉਦੇਸ਼ ਉਹਨਾਂ ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਜੋੜਨਾ ਹੈ ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਦਸ ਵੱਖ-ਵੱਖ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੇ ਅੰਦਰ ਹੁੰਦੇ ਹਨ। ਸਿਸਟਮੈਟਿਕ ਸੋਚ ਤੋਂ ਬਿਨਾਂ ਗੂੜ੍ਹਾ integration ਕਮਜ਼ੋਰ ਪੁਲਾਂ ਅਤੇ ਅਸੰਗਤ state ਦਾ ਇੱਕ ਦੁਸ਼ਵਪੁਣ ਬਣ ਜਾਂਦਾ ਹੈ। ਇਸ ਦੇ ਨਾਲ, workspace ਇੱਕ ਪੈਚ ਕੀਤੇ ਹੋਏ ਟੂਲਜ਼ ਦੇ ਸੰਘ ਵਜੋਂ ਨਹੀਂ, ਸਗੋਂ ਇੱਕ ਸਿੰਗਲ ਜੀਵ ਵਾਂਗ ਕੰਮ ਕਰਦਾ ਹੈ।

ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਨਹੀਂ, ਵਰਕਸਪੇਸ

Paardekam ਆਪਣੀ ਅਭਿਲਾਸ਼ ਦੀਆਂ ਸੀਮਾਵਾਂ ਬਾਰੇ ਸਪੱਸ਼ਟ ਰਹੇ ਹਨ। MaxOS Windows ਜਾਂ macOS ਦੀ ਜਗ੍ਹਾ ਨਹੀਂ ਲਵੇਗਾ। ਇਹ drivers, memory allocation, ਜਾਂ hardware abstraction layers ਨੂੰ ਪ੍ਰਬੰਧਿਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕਰਦਾ। ਟੀਚਾ ਕੁਝ ਵਧੇਰੇ ਨਿੱਜੀ ਹੈ: workspace।

ਜ਼ਿਆਦਾਤਰ knowledge workers ਇੱਕ ਟੁੱਟੇ ਹੋਏ ਮਾਹੌਲ ਵਿੱਚ ਰਹਿੰਦੇ ਹਨ। ਤੁਸੀਂ email client ਤੋਂ calendar 'ਤੇ, notes app ਤੋਂ terminal 'ਤੇ, design tool ਤੋਂ messaging platform 'ਤੇ ਜਾਂਦੇ ਹੋ। ਹ

Paardekam ਦੇ ਆਰਕੀਟੈਕਚਰ ਪੜਾਅ ਨੇ ਦੋ ਠੋਸ ਨਤੀਜੇ ਦਿੱਤੇ। ਪਹਿਲਾ, ਇੱਕ ਸਪਸ਼ਟ ਵਿਜ਼ਨ ਅਤੇ ਮਿਸ਼ਨ ਦੀ ਪਰਿਭਾਸ਼ਾ। ਇਹ ਕੋਈ ਮਾਰਕੀਟਿੰਗ ਦੀ ਫ਼ਾਲਤੂ ਗੱਲ ਨਹੀਂ ਹੈ। ਇੱਕ ਇਕੱਲੇ ਤਕਨੀਕੀ ਸੰਸਥਾਪਕ (solo technical founder) ਲਈ, ਇਹ ਸਕੋਪ ਗਾਰਡ (scope guard) ਵਜੋਂ ਕੰਮ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਇਹ ਫੈਸਲਾ ਲੈਣ ਦੀ ਸਥਿਤੀ ਵਿੱਚ ਹੁੰਦੇ ਹੋ ਕਿ ਚੈਟ ਸਾਈਡਬਾਰ ਜਾਂ ਪਲੱਗਇਨ ਮਾਰਕੀਟਪਲੇਸ ਜੋੜਨਾ ਹੈ ਜਾਂ ਨਹੀਂ, ਤਾਂ ਮਿਸ਼ਨ ਸਟੇਟਮੈਂਟ ਜਾਂ ਤਾਂ ਇਸ ਨੂੰ ਸਵੀਕਾਰ ਕਰਦੀ ਹੈ ਜਾਂ ਇਸ ਨੂੰ ਰੱਦ ਕਰ ਦਿੰਦੀ ਹੈ। ਦੂਜਾ, ਉਸਨੇ ਇੱਕ ਪੂਰਾ ਪ੍ਰੋਜੈਕਟ ਬਲੂਪ੍ਰਿੰਟ ਤਿਆਰ ਕੀਤਾ।

ਪੂਰੀ ਯੋਜਨਾ ਨੂੰ ਸ਼ੁਰੂ ਤੋਂ ਅੰਤ ਤੱਕ ਸਾਹਮਣੇ ਦੇਖਣ ਨਾਲ ਪ੍ਰੋਜੈਕਟ ਦੀ ਮਨੋਵਿਗਿਆਨਕ ਸਥਿਤੀ ਬਦਲ ਗਈ। ਨੋਟਬੁੱਕਾਂ ਵਿੱਚ ਵਿਚਾਰ ਕਲਪਨਾਤਮਕ ਲੱਗਦੇ ਹਨ। ਇੱਕ ਬਲੂਪ੍ਰਿੰਟ ਅਟੱਲ ਲੱਗਦਾ ਹੈ। ਇਹ ਉਹਨਾਂ ਕਮੀਆਂ ਨੂੰ ਉਦੋਂ ਹੀ ਸਾਹਮਣੇ ਲਿਆਉਂਦਾ ਹੈ ਜਦੋਂ ਉਹਨਾਂ ਨੂੰ ਸੁਧਾਰਨਾ ਸਸਤਾ ਹੁੰਦਾ ਹੈ। ਇਹ ਦੱਸਦਾ ਹੈ ਕਿ ਸਭ ਤੋਂ ਔਖੇ ਜੋਖਮ ਕਿੱਥੇ ਛੁਪੇ ਹੋਏ ਹਨ। ਇਸ ਪੜਾਅ 'ਤੇ, ਕੋਡ ਦੀਆਂ ਲਾਈਨਾਂ ਨਾਲੋਂ ਇੱਕ ਸਹੀ ਦਸਤਾਵੇਜ਼ ਵਾਕਈ ਜ਼ਿਆਦਾ ਮਹੱਤਵ ਰੱਖਦਾ ਹੈ। ਕੋਡ ਨੂੰ ਰੀਫੈਕਟਰ (refactor) ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ; ਪਰ ਇੱਕ ਉਲਝਿਆ ਹੋਇਆ ਅਧਾਰ (premise) ਤਕਨੀਕੀ ਕਰਜ਼ੇ (technical debt) ਵਿੱਚ ਜੰਮ ਜਾਂਦਾ ਹੈ ਜਿਸ ਨੂੰ ਰਾਤ ਦੇ ਕਿਸੇ ਵੀ ਡੀਬੱਗਿੰਗ (debugging) ਨਾਲ ਖਤਮ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ।

ਕਾਗਜ਼ ਤੋਂ ਮੋਨੋਰੇਪੋ (Monorepo) ਤੱਕ

ਆਰਕੀਟੈਕਚਰ ਪੂਰਾ ਹੋਣ ਨਾਲ, ਅਗਲਾ ਪੜਾਅ ਸ਼ੁਰੂ ਹੋ ਗਿਆ ਹੈ। Paardekam ਦਸਤਾਵੇਜ਼ਾਂ ਤੋਂ ਕੋਡ ਵੱਲ ਵਧ ਰਿਹਾ ਹੈ, ਜਿਸ ਦੀ ਸ਼ੁਰੂਆਤ ਮੋਨੋਰੇਪੋ (monorepo) ਦੇ ਇਨੀਸ਼ੀਅਲਾਈਜ਼ੇਸ਼ਨ (initialization) ਨਾਲ ਹੋ ਰਹੀ ਹੈ। ਇਸ ਤਬਦੀਲੀ ਦੇ ਨਾਲ ਆਪਣੀ ਚਿੰਤਾ ਵੀ ਜੁੜੀ ਹੋਈ ਹੈ। ਇੱਕ ਬਲੂਪ੍ਰਿੰਟ ਇੱਕ ਵਾਅਦਾ ਹੈ। ਇੱਕ ਕੋਡਬੇਸ (codebase) ਇੱਕ ਸਬੂਤ ਹੈ। ਉਸਨੇ ਇਹ ਮੰਨਿਆ ਹੈ ਕਿ ਉਹ ਇਸ ਗੱਲ ਨੂੰ ਲੈ ਕੇ ਘਬਰਾਇਆ ਹੋਇਆ ਹੈ ਕਿ ਕੀ ਡਿਜ਼ਾਈਨ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ (implementation) ਦੇ ਦੌਰਾਨ ਟਿਕ ਸਕੇਗਾ। ਉਹ ਇਮਾਨਦਾਰੀ ਉਹਨਾਂ ਅਣਜਾਣੀਆਂ ਚੀਜ਼ਾਂ ਲਈ ਇੱਕ ਸਿਹਤਮੰਦ ਸਤਿਕਾਰ ਨੂੰ ਦਰਸਾਉਂਦੀ ਹੈ ਜੋ ਉਦੋਂ ਹੀ ਸਾਹਮਣੇ ਆਉਂਦੀਆਂ ਹਨ ਜਦੋਂ ਸਿਧਾਂਤ (theory) ਦਾ ਸਾਹਮਣਾ ਲਾਇਬ੍ਰੇਰੀ ਵਰਜ਼ਨਾਂ, ਐਜ ਕੇਸਾਂ (edge cases) ਅਤੇ ਕਰਾਸ-ਪਲੇਟਫਾਰਮ ਵਿਵਹਾਰ ਦੀਆਂ ਅਸਲੀਅਤਾਂ ਨਾਲ ਹੁੰਦਾ ਹੈ।

ਮੋਨੋਰੇਪੋ ਨੂੰ ਇਨੀਸ਼ੀਅਲਾਈਜ਼ ਕਰਨਾ ਸਿਰਫ਼ ਇੱਕ ਰਸਮੀ git init ਤੋਂ ਕਿਤੇ ਵੱਧ ਹੈ। ਇਹ ਉਹ ਭੌਤਿਕ ਢਾਂਚਾ ਤਿਆਰ ਕਰਦਾ ਹੈ ਜੋ ਤਰਕਸ਼ੀਲ ਆਰਕੀਟੈਕਚਰ (logical architecture) ਨੂੰ ਦਰਸਾਏਗਾ। ਪੈਕੇਜ ਕਿੱਥੇ ਰਹਿਣਗੇ, ਉਹ ਇੱਕ ਦੂਜੇ 'ਤੇ ਕਿਵੇਂ ਨਿਰਭਰ ਕਰਨਗੇ, ਅਤੇ ਲੇਅਰਾਂ (layers) ਵਿਚਕਾਰ ਦੀਆਂ ਸੀਮਾਵਾਂ ਕਿੱਥੇ ਹੋਣਗੀਆਂ, ਇਹ ਸਭ ਹਫ਼ਤਿਆਂ ਦੀ ਯੋਜਨਾਬੰਦੀ ਦਾ ਪ੍ਰਤੀਬਿੰਬ ਹੋਵੇਗਾ। ਜੇਕਰ ਇਹ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੀਤਾ ਗਿਆ, ਤਾਂ ਪਹਿਲਾ ਫੋਲਡਰ ਢਾਂਚਾ ਅਤੇ ਬਿਲਡ ਪਾਈਪਲਾਈਨ (build pipeline) ਭਵਿੱਖ ਦੇ ਯੋਗਦਾਨਾਂ ਦਾ ਮਾਰਗਦਰਸ਼ਨ ਕਰੇਗੀ। ਜੇਕਰ ਇਹ ਮਾੜੇ ਤਰੀਕੇ ਨਾਲ ਕੀਤਾ ਗਿਆ, ਤਾਂ ਇਹ ਸਾਲਾਂ ਤੱਕ ਹਰ ਉਸ ਡਿਵੈਲਪਰ ਨੂੰ ਚੁੱਪਚਾਪ ਸਜ਼ਾ ਦੇਵੇਗਾ ਜੋ ਇਸ ਪ੍ਰੋਜੈਕਟ 'ਤੇ ਕੰਮ ਕਰੇਗਾ।