23 ਦਸੰ 2025·8 ਮਿੰਟ
ਵੋਜ਼ਨਿਯੈਕ ਅਤੇ ਇਕੱਠੇ ਕੰਪਿਊਟਿੰਗ ਵਿੱਚ ਇੰਜੀਨੀਅਰਿੰਗ-ਪਹਿਲਾ ਸਭਿਆਚਾਰ
ਜਾਣੋ ਕਿ Steve Wozniak ਦੀ ਇੰਜੀਨੀਅਰਿੰਗ-ਪਹਿਲੀ ਸੋਚ ਅਤੇ ਹਾਰਡਵੇਅਰ–ਸਾਫਟਵੇਅਰ ਇਕਤ੍ਰਿਤਤਾ ਕਿਵੇਂ ਪ੍ਰਾਇਗਟਿਕ ਪਰਸਨਲ ਕੰਪਿਊਟਰ ਬਣਾਉਂਦੇ ਹੋਏ ਦਹਾਕਿਆਂ ਤੱਕ ਉਤਪਾਦ ਟੀਮਾਂ ਲਈ ਸਬਕ ਛੱਡ ਗਈ।
ਜਾਣੋ ਕਿ Steve Wozniak ਦੀ ਇੰਜੀਨੀਅਰਿੰਗ-ਪਹਿਲੀ ਸੋਚ ਅਤੇ ਹਾਰਡਵੇਅਰ–ਸਾਫਟਵੇਅਰ ਇਕਤ੍ਰਿਤਤਾ ਕਿਵੇਂ ਪ੍ਰਾਇਗਟਿਕ ਪਰਸਨਲ ਕੰਪਿਊਟਰ ਬਣਾਉਂਦੇ ਹੋਏ ਦਹਾਕਿਆਂ ਤੱਕ ਉਤਪਾਦ ਟੀਮਾਂ ਲਈ ਸਬਕ ਛੱਡ ਗਈ।
ਇੱਕ ਇੰਜੀਨੀਅਰਿੰਗ-ਪਹਿਲਾ ਉਤਪਾਦ ਸਭਿਆਚਾਰ ਨੂੰ ਸੰਖੇਪ ਵਿਚ ਇਸ ਤਰ੍ਹਾਂ ਬਿਆਨ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ: ਫੈਸਲੇ ਇਸ ਸਵਾਲ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ — “ਅਸੀਂ ਕੀ ਕੁਝ ਭਰੋਸੇਯੋਗ, ਸਸਤੀ ਅਤੇ ਦੋਹਰਾਈ ਜਾ ਸਕਣ ਵਾਲੀ ਤਰ੍ਹਾਂ ਬਣਾਈ ਸਕਦੇ ਹਾਂ?” — ਅਤੇ ਫਿਰ ਹੀ ਆਉਂਦਾ ਹੈ “ਅਸੀਂ ਇਸ ਨੂੰ ਕਿਵੇਂ ਪੈਕ ਅਤੇ ਸਮਝਾਵਾਂ?”
ਇਸ ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ ਸੁੰਦਰਤਾ ਮਹੱਤਵਸ਼ੀਨ ਨਹੀਂ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਟੀਮ ਸੀਮਾਵਾਂ—ਲਾਗਤ, ਭਾਗਾਂ ਦੀ ਉਪਲਬਧਤਾ, ਪਾਵਰ, ਮੈਮੋਰੀ, ਗਰਮੀ, ਨਿਰਮਾਣ ਉਤਪਾਦਕਤਾ, ਸਹਾਇਤਾ—ਨੂੰ ਪਹਿਲੀ ਕਲਾਸ ਇਨਪੁਟ ਮੰਨਦੀ ਹੈ, ਨਾ ਕਿ ਬਾਅਦ ਦੀ ਸੋਚ।
ਫੀਚਰ-ਪਹਿਲਾ ਟੀਮਾਂ ਅਕਸਰ ਇੱਕ ਇੱਛਾ-ਸੂਚੀ ਨਾਲ ਸ਼ੁਰੂ ਕਰਦੀਆਂ ਹਨ ਅਤੇ ਤਕਨੋਲੋਜੀ ਨੂੰ ਉਸ ਦੇ ਅਨੁਸਾਰ ਠੋਸ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੀਆਂ ਹਨ। ਇੰਜੀਨੀਅਰਿੰਗ-ਪਹਿਲਾ ਟੀਮਾਂ ਹਕੀਕਤੀ ਭੌਤਿਕੀ ਅਤੇ ਬਜਟ ਨਾਲ ਸ਼ੁਰੂ ਕਰਦੀਆਂ ਹਨ, ਫਿਰ ਉਤਪਾਦ ਨੂੰ ਉਹਨਾਂ ਸੀਮਾਵਾਂ ਵਿੱਚ ਵਰਤੋਂਯੋਗ ਬਣਾਉਂਦੀਆਂ ਹਨ।
ਨਤੀਜਾ ਅਕਸਰ ਸਤਹ 'ਤੇ “ਸਾਦਾ” ਲੱਗਦਾ ਹੈ, ਪਰ ਇਹ ਇਸ ਲਈ ਹੁੰਦਾ ਹੈ ਕਿ ਕਿਸੇ ਨੇ ਪਹਿਲਾਂ ਹੀ ਮੁਸ਼ਕਲ ਕੰਮ ਕੀਤਾ ਹੁੰਦਾ ਹੈ—ਟਰੇਡ-ਆਫ਼ ਚੁਣੇ ਜਾਂਦੇ ਹਨ ਅਤੇ ਉਨਾਂ 'ਤੇ ਕਾਇਮ ਰਹਿੰਦੇ ਹਨ।
ਸ਼ੁਰੂਆਤੀ ਪੀਸੀਜ਼ ਕੜੀਆਂ ਹੱਦਾਂ ਹੇਠਾਂ ਰਹਿੰਦੇ ਸਨ: ਘੱਟ ਮੈਮੋਰੀ, ਹੌਲੀ ਸਟੋਰੇਜ, ਮਹਿੰਗੇ ਚਿਪ, ਅਤੇ ਉਪਭੋਗੀ ਜੋ ਮੁੜ-ਮੁੜ ਅਪਗਰੇਡ ਨਹੀਂ ਕਰ ਸਕਦੇ। ਹਾਰਡਵੇਅਰ–ਸਾਫਟਵੇਅਰ ਇਕਤ੍ਰਿਤਤਾ ਇਸ ਲਈ ਮਹੱਤਵਪੂਰਕ ਸੀ ਕਿ ਮਸ਼ੀਨ ਨੂੰ ਕਾਬਲ-ਏ-ਕਾਰ ਬਣਾਉਣ ਲਈ ਸਰਕਿਟ ਤੈਰ-ਤਰੀਕੇ ਅਤੇ ਸਾਫਟਵੇਅਰ ਫੈਸਲੇ ਇੱਕਠੇ ਕੀਤੇ ਜਾਣੇ ਲਾਜ਼ਮੀ ਸਨ।
ਜਦੋਂ ਦੋਹਾਂ ਪਾਸਿਆਂ 'ਤੇ ਇੱਕੋ ਸੋਚ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ:
ਇਹ ਲੇਖ Wozniak ਦੇ ਕੰਮ ਨੂੰ ਉਤਪਾਦ ਟੀਮਾਂ ਲਈ ਇੱਕ ਪ੍ਰਯੋਗੀ ਕੇਸ ਸਟਡੀ ਵਜੋਂ ਵਰਤਦਾ ਹੈ: ਕਿਵੇਂ ਇਕਤ੍ਰਿਤ ਫੈਸਲੇ ਵਰਤੋਂਯੋਗਤਾ, ਲਾਗਤ ਅਤੇ ਲੰਬੇ ਸਮੇਂ ਦੀ ਲਚਕੀਲਾਪਣ ਨੂੰ ਰੂਪ ਦਿੰਦੇ ਹਨ।
ਇਹ ਰੋਮਾਂਚਕ ਪੁਰਾਤਨੀਆਂ ਦਾ ਵਰਣਨ ਨਹੀਂ ਹੈ। ਨਾ ਹੀ ਹੀਰੋ ਵਾਰਸ਼ਿਪ, ਨਾ “ਜਿਨੀਅਸ ਸਭ ਕੁਝ ਇਕੱਲਾ ਕੀਤਾ” ਵਾਲੀ ਕਹਾਣੀ, ਅਤੇ ਨਾ ਹੀ ਇਤਿਹਾਸ ਨੂੰ ਕਿਸੇ ਪ੍ਰੇਰਣਾਦਾਇਕ ਪੋਸਟਰ ਅਨੁਸਾਰ ਮੁੜ ਲਿਖਣਾ। ਲਕੜੀ ਯੋਗਤਾ ਇਹ ਹੈ ਕਿ ਮਾਡਰਨ ਉਤਪਾਦਾਂ 'ਤੇ ਲਾਗੂ ਕਰਨ ਯੋਗ ਹੀ ਸਮਝਦਾਰ ਪਾਠ ਮਿਲਣ। ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਤੁਸੀਂ ਕਠੋਰ ਇਕਤ੍ਰਿਤ ਸਿਸਟਮ ਅਤੇ ਮੋਡਿਊਲਰ, ਮਿਲਾ-ਜੁਲਾ ਆਕੀਟੈਕਚਰ ਵਿੱਚੋਂ ਚੋਣ ਕਰ ਰਹੇ ਹੋ।
1970 ਦੇ ਮੱਧ ਵਿੱਚ ਪੀਸੀ ਬਣਾਉਣਾ ਮਤਲਬ ਸੀਖੀਆਂ ਹੱਦਾਂ ਵਿੱਚ ਡਿਜ਼ਾਈਨ ਕਰਨਾ: ਭਾਗ ਮਹਿੰਗੇ ਸਨ, ਮੈਮੋਰੀ ਥੋੜੀ ਸੀ, ਅਤੇ “ਚੰਗਾ-ਹੁੰਦਾ” ਫੀਚਰ ਜਦੋਂ ਤੁਸੀਂ ਵਾਧੂ ਚਿਪਾਂ ਦੀ ਕੀਮਤ ਜੋੜਦੇ ਤਾਂ ਅਸੰਭਵ ਬਣ ਜਾਂਦਾ।
ਸ਼ੁਰੂਆਤੀ ਮਾਇਕ੍ਰੋਪ੍ਰੋਸੈਸਰ ਇਕ ਇਨਕਲਾਬ ਸਨ, ਪਰ ਉਹਨਾਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਦੀਆਂ ਚੀਜ਼ਾਂ ਵੀ ਤੇਜ਼ੀ ਨਾਲ ਮਹਿੰਗੀਆਂ ਹੋ ਜਾਂਦੀਆਂ—RAM ਚਿਪ, ROM, ਵੀਡੀਓ ਸਰਕਿਟਰੀ, ਕੀਬੋਰਡ, ਪਾਵਰ ਸਪਲਾਈ। ਬਹੁਤ ਸਾਰੇ ਕੰਪੋਨੇਟਾਂ ਦੀ ਉਪਲਬਧਤਾ ਅਸਥਿਰ ਰਹਿੰਦੀ ਸੀ, ਅਤੇ ਇੱਕ ਭਾਗ ਦੂਜੇ ਨਾਲ ਬਦਲਣ ਨਾਲ ਡਿਜ਼ਾਈਨ ਨੂੰ ਮੁੜ ਤਿਆਰ ਕਰਨਾ ਪੈ ਸਕਦਾ ਸੀ।
ਜੇ ਕਿਸੇ ਫੀਚਰ ਲਈ ਕੁਝ ਹੋਰ ਇੰਟੀਗ੍ਰੇਟਡ ਸਰਕਿਟ ਵੀ ਲੋੜ ਪੈਂਦੇ, ਤਾਂ ਉਹ ਕੇਵਲ ਤਕਨੀਕੀ ਚੋਣ ਨਹੀਂ ਸੀ; ਇਹ ਬਜਟ ਦਾ ਫੈਸਲਾ ਸੀ।
ਮੈਮੋਰੀ ਦੀਆਂ ਸੀਮਾਵਾਂ ਖ਼ਾਸ ਤੌਰ 'ਤੇ ਕੜੀਆਂ ਸਨ। ਕੇਵਲ ਕੁਝ ਕਿਲੋਬਾਈਟਸ ਦੇ ਨਾਲ, ਸਾਫਟਵੇਅਰ ਸ਼ੁਭ ਧਾਰਨਾ ਵਾਲੇ ਬਫਰ, ਵਿਸਥਾਰਤ ਕੋਡ, ਜਾਂ ਪਰਤਾਂ ਵਾਲੀ ਅਬਸਟਰੈਕਸ਼ਨ فرض ਨਹੀਂ ਕਰ ਸਕਦਾ ਸੀ। ਹਾਰਡਵੇਅਰ ਪਾਸੇ ਵਧੇਰੇ ਲਾਜ਼ਿਕ ਦਾ ਮਤਲਬ ਹੋਰ ਚਿੱਪ, ਹੋਰ ਬੋਰਡ ਜਗ੍ਹਾ, ਵੱਧ ਪਾਵਰ ਖਪਤ, ਅਤੇ ਵੱਧ ਫੇਲਤਰਿੰਦਾ ਨੁਕਤੇ।
ਇਹ ਦਬਾਅ ਉਹਨਾਂ ਟੀਮਾਂ ਨੂੰ ਇਨਾਮ ਦਿੰਦਾ ਸੀ ਜੋ ਇਕ ਤੱਤ ਨੂੰ ਦੁਹਰਾ ਕੰਮ ਦੇ ਸਕਦੀਆਂ:
ਜਦੋਂ "ਹੋਰ ਜੋੜੋ" ਵਿਕਲਪ ਨਹੀਂ ਹੁੰਦਾ, ਤੁਹਾਨੂੰ ਹੋਰ ਤੇਜ਼ੀ ਨਾਲ ਸਵਾਲ ਪੁੱਛਣੇ ਪੈਂਦੇ:
ਇਹ ਸੋਚ ਸਪਸ਼ਟ, ਉਦੇਸ਼ਪੂਰਕ ਡਿਜ਼ਾਈਨਾਂ ਨੂੰ ਜਨਮ ਦਿੰਦੀ ਹੈ ਬਜਾਏ ਅਧ-ਕੰਮ ਕੀਤੇ ਵਿਕਲਪਾਂ ਦੇ ਢੇਰ ਦੇ।
ਇਹਨਾਂ ਸੀਮਾਵਾਂ ਦਾ ਪ੍ਰਾਇਕਟਿਕ ਨਤੀਜਾ ਸਿਰਫ਼ ਇੰਜੀਨੀਅਰਿੰਗ ਘਮੰਡ ਹੀ ਨਹੀਂ ਸੀ। ਘੱਟ ਭਾਗਾਂ ਨਾਲ ਕੀਮਤ ਘਟ ਸਕਦੀ ਸੀ, ਇੱਕ ਬਣਾਉਣਯੋਗ ਉਤਪਾਦ ਮਿਲਦਾ ਸੀ, ਅਤੇ ਘੱਟ ਚੀਜ਼ਾਂ ਚੈੱਕ ਕਰਨੀਆਂ ਪੈਂਦੀਆਂ। ਤੰਗ, ਖਪਤ ਕਰਨ ਵਾਲਾ ਸਾਫਟਵੇਅਰ ਸੀਮਤ ਹਾਰਡਵੇਅਰ 'ਤੇ ਤੇਜ਼ ਪ੍ਰਤੀਕਿਰਿਆ ਦਿੰਦਾ।
ਉਪਭੋਗੀ ਲਈ, ਜੇ ਸੀਮਾਵਾਂ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸੰਭਾਲੀਆਂ ਜਾਣ, ਤਾਂ ਕੰਪਿਊਟਰ ਅਹੁੰਦੇ ਹਨ ਜੋ ਵੱਧ ਪਹੁੰਚਯੋਗ, ਵੱਧ ਭਰੋਸੇਯੋਗ, ਅਤੇ ਜੀਵਨ-ਭਰ ਵਰਤੋਂ-ਯੋਗ ਹੁੰਦੇ ਹਨ।
Steve Wozniak ਅਕਸਰ ਸ਼ੁਰੂਆਤੀ ਸੁੰਦਰ ਕੰਪਿਊਟਰਾਂ ਨਾਲ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ, ਪਰ ਜ਼ਿਆਦਾ ਲਾਭਕਾਰੀ ਸਬਕ ਉਹ ਸੋਚ ਹੈ ਜੋ ਉਨ੍ਹਾਂ ਦੇ ਕੰਮ ਦੇ ਪਿੱਛੇ ਸੀ: ਜੋ ਲਾਭਕਾਰੀ ਹੋ, ਉਹ ਬਣਾਓ; ਇਸ ਨੂੰ ਸਮਝਣ ਯੋਗ ਰੱਖੋ; ਅਤੇ ਉੱਥੇ ਮੇਹنت ਕਰੋ ਜਿੱਥੇ ਇਸਦਾ ਨਤੀਜਾ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਬਦਲਦਾ ਹੈ।
ਪ੍ਰਾਇਕਟਿਕ ਇੰਜੀਨੀਅਰਿੰਗ ਕਿਸੇ ਨਾਅਰੇ ਵਾਂਗ "ਘੱਟ ਵਿੱਚ ਵੱਧ ਕਰਨਾ" ਨਹੀਂ ਹੈ—ਇਹ ਹਰ ਭਾਗ, ਫੀਚਰ ਅਤੇ ਵਰਕਅਰਾਉਂਡ ਨੂੰ ਉਸ ਦੀ ਜਗ੍ਹਾ ਕਿਸੇ ਪ੍ਰਾਈਸ ਦੇ ਨਾਲ ਕਮਾਉਣ ਦੀ ਮੰਗ ਕਰਦੀ ਹੈ। ਕੁਸ਼ਲਤਾ ਇਨ੍ਹਾਂ ਰੂਪਾਂ ਵਿੱਚ ਦਿਸਦੀ ਹੈ:
ਇਹ ਫੋਕਸ ਅਕਸਰ ਉਤਪਾਦ ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਉਪਭੋਗੀ ਲਈ ਸਧਾਰਨ ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ, ਭਾਵੇਂ ਅੰਦਰੂਨੀ ਫੈਸਲੇ ਬਰੀਕੀ ਨਾਲ ਅਨੁਕੂਲ ਕੀਤੇ ਜਾਣ।
ਇੰਜੀਨੀਅਰਿੰਗ-ਪਹਿਲਾ ਸਭਿਆਚਾਰ ਮੰਨਦਾ ਹੈ ਕਿ ਹਰ ਜਿੱਤ ਦੀ ਕੀਮਤ ਹੁੰਦੀ ਹੈ। ਚਿੱਪ ਗਿਣਤੀ ਘਟਾਓ ਤਾਂ ਸਾਫਟਵੇਅਰ ਜ਼ਿਆਦਾ ਜਟਿਲ ਹੋ ਸਕਦਾ ਹੈ। ਗਤੀ ਵਧਾਓ ਤਾਂ ਕੀਮਤ ਵੱਧ ਸਕਦੀ ਹੈ। ਲਚਕੀਲਾਪਣ ਮਿਲਾਓ ਤਾਂ ਫੇਲ ਮੋਡ ਵੱਧ ਸਕਦੇ ਹਨ।
ਪ੍ਰਾਇਕਟਿਕ ਚਾਲ ਇਹ ਹੈ ਕਿ ਟਰੇਡ-ਆਫ਼ ਸ਼ੁਰੂ ਵਿੱਚ ਸਪਸ਼ਟ ਕੀਤੇ ਜਾਣ:
ਜਦ ਟੀਮਾਂ ਟਰੇਡ-ਆਫ਼ ਨੂੰ ਸਾਂਝੇ ਫੈਸਲੇ ਵਜੋਂ ਲੈਂਦੀਆਂ ਹਨ — ਨਾ ਕਿ ਛੁਪੇ ਤਕਨੀਕੀ ਚੋਣਾਂ — ਤਾਂ ਉਤਪਾਦ ਦੀ ਦਿਸ਼ਾ ਤੇਜ਼ ਹੋ ਜਾਂਦੀ ਹੈ।
ਹੱਥ-ਉੱਤੇ ਤਰੀਕਾ ਪ੍ਰੋਟੋਟਾਈਪ ਅਤੇ ਮਾਪਯੋਗ ਨਤੀਜਿਆਂ ਨੂੰ ਬੇਤੁਕੀਆਂ ਚਰਚਿਆਂ 'ਤੇ ਤਰਜੀਹ ਦਿੰਦਾ ਹੈ। ਕੁਝ ਛੋਟਾ ਬਣਾਓ, ਇਸਨੂੰ ਅਸਲ ਕਾਰਜਾਂ ਦੇ ਖਿਲਾਫ ਟੈਸਟ ਕਰੋ, ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਦੁਹਰਾਓ।
ਇਹ ਚੱਕਰ "ਵਰਤੋਂਯੋਗਤਾ" ਨੂੰ ਕੇਂਦਰ ਵਿੱਚ ਰੱਖਦਾ ਹੈ। ਜੇ ਕੋਈ ਫੀਚਰ ਕੰਮ ਕਰਨ ਵਾਲੇ ਮਾਡਲ ਵਿੱਚ ਆਪਣੀਵੈਲਯੂ ਸਾਬਤ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਤਾਂ ਉਹ ਸਧਾਰਨ ਕਰਨ ਜਾਂ ਹਟਾਉਣ ਲਈ ਉਮੀਦਵਾਰ ਹੈ।
Apple I ਕੋਈ ਨਿੱਘੀ-ਤਿਆਰ ਉਪਭੋਗਤਾ ਉਪਕਰਣ ਨਹੀਂ ਸੀ। ਇਹ ਉਨ੍ਹਾਂ ਲੋਕਾਂ ਲਈ ਇੱਕ ਸ਼ੁਰੂਆਤੀ ਕੰਪਿਊਟਰ ਵਾਂਗ ਸੀ ਜੋ ਜੋੜਨ, ਅਨੁਕੂਲ ਕਰਨ ਅਤੇ ਸਿੱਖਣ ਲਈ ਤਿਆਰ ਸਨ। ਮਕਸਦ ਇਹ ਸੀ: Wozniak ਨੇ ਕੁਝ ਐਸਾ ਬਣਾਇਆ ਜੋ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਕਮਪਿਊਟਰ ਵਜੋਂ ਵਰਤ ਸਕੋ—ਬਿਨਾਂ ਲੈਬ ਜਾਂ ਇੰਜੀਨੀਅਰਿੰਗ ਟੀਮ ਦੀ ਲੋੜ।
ਉਸ ਸਮੇਂ ਬਹੁਤ ਸਾਰੇ ਹੋਬੀ ਕੰਪਿਊਟਰ ਖ਼ਾਲੀ ਆਈਡੀਆ ਵਾਂਗ ਆਉਂਦੇ ਸਨ ਜਾਂ ਵੱਡੀ ਤਰ੍ਹਾਂ ਤਾਰਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਸੀ। Apple I ਨੇ 6502 ਪ੍ਰੋਸੈਸਰ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਸਰਕਿਟ ਬੋਰਡ ਦੇ ਕੇ ਉਸ ਰੁਕਾਵਟ ਨੂੰ ਘਟਾ ਦਿੱਤਾ।
ਇਸ ਵਿੱਚ ਅੱਜ ਜਿਹੜੀਆਂ ਚੀਜ਼ਾਂ ਆਮ ਹਨ (ਕੇਸ, ਕੀਬੋਰਡ, ਡਿਸਪਲੇ) ਨਹੀਂ ਸਨ, ਪਰ ਇਸਨੇ ਇਕ ਵੱਡੀ ਰੁਕਾਵਟ ਹਟਾਈ: ਤੁਹਾਨੂੰ ਮੁੱਖ ਕੰਪਿਊਟਰ ਨੂੰ ਸ਼ੁਰੂ ਤੋਂ ਬਣਾਉਣ ਦੀ ਲੋੜ ਨਹੀਂ ਸੀ।
ਅਮਲੀ ਰੂਪ ਵਿੱਚ, “ਵਰਤੋਂਯੋਗ” ਦਾ ਮਤਲਬ ਸੀ ਕਿ ਤੁਸੀਂ ਇਸਨੂੰ پاور ਕਰਕੇ ਮਾਨਵ-ਸੰਬੰਧਤ ਤਰੀਕੇ ਨਾਲ ਇੰਟਰੈਕਟ ਕਰ ਸਕਦੇ—ਖਾਸ ਕਰਕੇ ਉਹਨਾਂ ਵਿਕਲਪਾਂ ਨਾਲ ਤੁਲਨਾ ਵਿੱਚ ਜੋ ਪਹਿਲਾਂ ਇਲੈਕਟ੍ਰਾਨਿਕ ਪ੍ਰੋਜੈਕਟ ਵਾਂਗ ਮਹਿਸੂਸ ਹੁੰਦੇ ਸਨ ਅਤੇ ਕੰਪਿਊਟਰ ਦੂਜੇ ਨੰਬਰ ਤੇ ਆਉਂਦੇ ਸਨ।
Apple I ਦੌਰ ਵਿੱਚ ਇਕਤ੍ਰਿਤਤਾ ਦਾ ਮਤਲਬ ਸਭ ਕੁਝ ਇੱਕ ਸਾਫ਼-ਸੁਥਰੇ ਉਤਪਾਦ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰ ਦੇਣਾ ਨਹੀਂ ਸੀ। ਇਸਦਾ ਮਤਲਬ ਸੀ ਕਿ ਇਨ੍ਹਾਂ ਮੁੱਖ ਹਿੱਸਿਆਂ ਨੂੰ ਐਨਾ ਇਕੱਠਾ ਕਰੋ ਕਿ ਸਿਸਟਮ ਤਰਤੀਬਵਾਰ ਕੰਮ ਕਰੇ:
ਇਹ ਜੋੜ-ਜੋੜ ਮਹੱਤਵ ਰੱਖਦੀ ਹੈ: ਬੋਰਡ ਸਿਰਫ਼ ਇੱਕ ਕੰਪੋਨੇਟ ਨਾ ਸੀ—ਇਹ ਇਕ ਐਸਾ ਕੋਰ ਸੀ ਜੋ ਪੂਰਾ ਕਰਨ ਲਈ ਸੱਦਦਾ ਸੀ।
ਕਿਉਂਕਿ ਮਾਲਕਾਂ ਨੂੰ ਅਖੀਰਲੇ ਹਿੱਸੇ ਨੂੰ ਪੂਰਾ ਕਰਨਾ ਪੈਂਦਾ ਸੀ, Apple I ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਦਿਖਾਂਦਾ ਸੀ ਕਿ ਕੰਪਿਊਟਰ ਇਕੱਠੇ ਕਿਵੇਂ ਬਣਦੇ ਹਨ। ਤੁਸੀਂ ਸਿਰਫ਼ ਪ੍ਰੋਗ੍ਰਾਮ ਨਹੀਂ ਚਲਾਉਂਦੇ—ਤੁਸੀਂ ਇਹ ਸਿੱਖਦੇ ਹੋ ਕਿ ਮੈਮੋਰੀ ਕੀ ਕਰਦੀ ਹੈ, ਕਿਉਂ ਸਥਿਰ ਪਾਵਰ ਲਾਜ਼ਮੀ ਹੈ, ਅਤੇ I/O ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ। ਉਤਪਾਦ ਦੀਆਂ “ਕਿਨਾਰੀਆਂ” ਜਾਣ-ਪਛਾਣ ਯੋਗ ਤੱਥ-ਭਰੇ ਹੁੰਦੀਆਂ ਸਨ।
ਇਹ ਛੋਟੀ-ਅਦੈਅ ਸਤਰ 'ਤੇ ਇੰਜੀਨੀਅਰਿੰਗ-ਪਹਿਲਾ ਸਭਿਆਚਾਰ ਹੈ: ਇੱਕ ਘੱਟੋ-ਘੱਟ ਇਕਤ੍ਰਿਤ ਨੀਂਹ ਭੇਜੋ ਜੋ ਕੰਮ ਕਰਦੀ ਹੋਵੇ, ਫਿਰ ਅਸਲ ਉਪਭੋਗੀਆਂ ਨਾਲ ਪਤਾ ਲਗਾਉ ਕਿ ਅਗੇ ਕੀ ਸੁਧਾਰ ਕਰਨੇ ਹਨ।
Apple I ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਿਰਪੱਖ ਹੋਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕਰ ਰਿਹਾ ਸੀ। ਇਹ ਅਸਲ ਹੋਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਸੀ—ਅਤੇ ਇਹ ਪਰਾਇਕਟਿਕਤਾ ਉਤਸ਼ੁਕਤਾ ਨੂੰ ਡੈਸਕ 'ਤੇ ਕੰਪਿਊਟਰ ਵਿੱਚ ਤਬਦੀਲ ਕਰਨ ਵਿੱਚ ਮਦਦਗੀਰ ਰਹੀ।
Apple II ਸਿਰਫ਼ ਉਹ ਹੋਬੀਸਟਾਂ ਨੂੰ ਨਹੀਂ ਖਿੱਚਦਾ ਜੋ ਬਣਾਉਣ ਅਤੇ ਸੋਧਣਾ ਪਸੰਦ ਕਰਦੇ ਸਨ। ਇਹ ਉਹ ਸਮੱਗਰੀ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦਾ ਸੀ ਜੋ ਤੁਸੀਂ ਡੈਸਕ 'ਤੇ ਰੱਖ ਕੇ ਬਿਜਲੀ ਚਾਲੂ ਕਰਕੇ ਵਰਤ ਸਕਦੇ—ਬਿਨਾਂ ਪਹਿਲਾਂ ਇਲੈਕਟ੍ਰਾਨਿਕ ਟੈਕਨੀਸ਼ੀਅਨ ਬਣਨ ਦੀ ਲੋੜ।
ਇਹ “ਪੂਰਨਤਾ” ਇੰਜੀਨੀਅਰਿੰਗ-ਪਹਿਲਾ ਸਭਿਆਚਾਰ ਦੀ ਇੱਕ ਪ੍ਰਮੁੱਖ ਨਿਸ਼ਾਨੀ ਹੈ: ਡਿਜ਼ਾਈਨ ਚੋਣਾਂ ਨੂੰ ਇਸ ਮਾਪ 'ਤੇ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਕਿ ਕੀ ਉਹ ਪਾਵਰ-ਸਵਿੱਚ ਦੇ ਦੂਜੇ ਪਾਸੇ ਖੜੇ ਵਿਅਕਤੀ ਲਈ ਕੰਮ ਘਟਾਉਂਦੀਆਂ ਹਨ।
Apple II ਦੀ ਵੱਡੀ ਪ੍ਰਗਟਿਆ ਇਸ ਵਿੱਚ ਸੀ ਕਿ ਉਸਦੇ ਹਿੱਸਿਆਂ ਨੂੰ ਇਕੱਠੇ ਕੰਮ ਕਰਨ ਦੀ ਉਮੀਦ ਸੀ। ਵੀਡੀਓ ਆਉਟਪੁੱਟ ਇੱਕ ਵਿਕਲਪਤ ਸੋਚ ਨਹੀਂ ਸੀ—ਤੁਸੀਂ ਡਿਸਪਲੇ ਨਾਲ ਜੋੜ ਸਕਦੇ ਸਨ ਅਤੇ ਨਿਰਭਰਯੋਗ ਟੈਕਸਟ ਅਤੇ ਗ੍ਰਾਫਿਕਸ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਸਨ।
ਸਟੋਰੇਜ ਲਈ ਵੀ ਇੱਕ ਸਪਸ਼ਟ ਰਾਹ ਸੀ: ਸ਼ੁਰੂ ਵਿੱਚ ਕੈਸੈੱਟ, ਫਿਰ ਡਿਸਕ ਵਿਕਲਪ ਜੋ ਲੋਕਾਂ ਨੂੰ ਉਹ ਕਰਨ ਲਈ ਮਦਦ ਕਰਦੇ ਸਨ ਜੋ ਉਹ ਕਰਨਾ ਚਾਹੁੰਦੇ ਸਨ (ਪ੍ਰੋਗ્રਾਮ ਲੋਡ ਕਰਨਾ, ਕੰਮ ਸੇਵ ਕਰਨਾ, ਸਾਫ਼ਟਵੇਅਰ ਸ਼ੇਅਰ ਕਰਨਾ)।
ਜਿੱਥੇ ਮਸ਼ੀਨ ਖੁਲੀ ਰਹੀ, ਬੇਸਲਾਈਨ ਤੌਰ 'ਤੇ ਅਨੁਭਵ ਅਜੇ ਵੀ ਵਧੀਆ ਪਰਿਭਾਸ਼ਿਤ ਸੀ। ਵਿਕਾਸ ਸਲਾਟਾਂ ਨਾਲ ਉਪਭੋਗੀ ਖੁਦ ਦੀਆ ਸਮਰੱਥਾਵਾਂ ਵਧਾ ਸਕਦੇ ਸਨ, ਪਰ ਬੇਸਲਾਈਨ ਸਿਸਟਮ ਆਪਣੇ ਆਪ ਵਿੱਚ ਅਰਥਪੂਰਨ ਸੀ।
ਇਹ ਸੰਤੁਲਨ ਮਹੱਤਵਪੂਰਕ ਹੈ: ਖੁੱਲ੍ਹਾ ਪਨ ਸਭ ਤੋਂ ਵਧੀਆ ਉਸ ਵੇਲੇ ਕੀਮਤੀ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਇਹ ਇੱਕ ਸਥਿਰ ਬੁਨਿਆਦ ਨੂੰ ਵਧਾਉਂਦਾ ਹੈ ਨਾ ਕਿ ਗੁੰਮ ਹੋਈਆਂ ਜ਼ਰੂਰਤਾਂ ਨੂੰ ਕਵਰੇਜ ਕਰਦਾ ਹੋਵੇ।
ਕਿਉਂਕਿ Apple II ਨੂੰ ਇੱਕ ਸਮੱਗਰੀ ਪ੍ਰਣਾਲੀ ਵਜੋਂ ਪ੍ਰਭਾਵੀ ਤੌਰ 'ਤੇ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਗਿਆ ਸੀ, ਸਾਫਟਵੇਅਰ ਲੇਖਕ ਕੁਝ ਚੀਜ਼ਾਂ ਦੀ ਉਮੀਦ ਕਰ ਸਕਦੇ ਸਨ: ਇੱਕਸਾਰ ਡਿਸਪਲੇ ਵਿਹਾਰ, ਪੂਰੇ-ਸਹਿਜ I/O, ਅਤੇ "ਤੁਰੰਤ ਚਲਾਉਣ ਯੋਗ" ਵਾਤਾਵਰਨ ਜੋ ਕਿ ਵਿਸ਼ੇਸ਼ ਵਾਇਰਿੰਗ ਜਾਂ ਅਜਿਹੇ ਸੈੱਟਅਪ ਦੀ ਲੋੜ ਨਹੀਂ ਰੱਖਦਾ।
ਇਹ ਉਮੀਦਾਂ ਖਰੀਦਣ ਅਤੇ ਕੀਮਤ ਪਾਉਣ ਦੇ ਵਿਚਕਾਰ ਦੀ ਖਾਈ ਨੂੰ ਘਟਾਉਂਦੀਆਂ ਹਨ।
ਇਹ ਸਭ ਤੋਂ ਵਧੀਆ ਤਰ੍ਹਾਂ ਇਕਤ੍ਰਿਤਤਾ ਹੈ: ਸਭ ਕੁਝ ਬੰਦ ਕਰ ਦਿ and ਨਹੀਂ, ਪਰ ਕੋਰ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਰੂਪ ਦਿੰਦੀ ਹੈ ਕਿ ਡਿਫ਼ਾਲਟ ਅਨੁਭਵ ਭਰੋਸੇਯੋਗ, ਸਿੱਖਣਯੋਗ ਅਤੇ ਦੁਹਰਾਓਯੋਗ ਹੋ—ਅਜੇ ਵੀ ਵਧਣ ਦੀ ਜਗ੍ਹਾ ਛੱਡਦਿਆਂ।
ਇਕਤ੍ਰਿਤ ਕੰਪਿਊਟਰਾਂ ਵਿੱਚ ਹਾਰਡਵੇਅਰ ਅਤੇ ਸਾਫਟਵੇਅਰ ਅਲੱਗ ਦੁਨੀਆਵਾਂ ਨਹੀਂ ਹਨ—ਉਹ ਇਕ ਗੱਲਬਾਤ ਹਨ। ਤੁਸੀਂ ਜਿਹੜੇ ਭਾਗ ਚੁਣਦੇ (ਜਾਂ afford ਕਰ ਸਕਦੇ) ਹੋ ਉਹ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ ਕਿ ਸਾਫਟਵੇਅਰ ਕੀ ਕਰ ਸਕਦਾ ਹੈ। ਫਿਰ ਸਾਫਟਵੇਅਰ ਦੀਆਂ ਮੰਗਾਂ ਨਵੇਂ ਹਾਰਡਵੇਅਰ ਚਾਲਾਂ ਨੂੰ ਜ਼ੋੜ ਸਕਦੀਆਂ ਹਨ ਤਾਂ ਕਿ ਅਨੁਭਵ ਪੂਰਾ ਮਹਿਸੂਸ ਹੋਵੇ।
ਇੱਕ ਸਧਾਰਣ ਉਦਾਹਰਨ: ਮੈਮੋਰੀ ਮਹਿੰਗੀ ਅਤੇ ਸੀਮਤ ਹੈ। ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਸਿਰਫ਼ ਥੋੜ੍ਹੀ ਮੈਮੋਰੀ ਹੈ, ਤਾਂ ਸਾਫਟਵੇਅਰ ਨੂੰ ਫਿਟ ਹੋਣ ਲਈ ਲਿਖਿਆ ਜਾਣਾ ਚਾਹੀਦਾ—ਘੱਟ ਫੀਚਰ, ਤੰਗ ਕੋਡ, ਅਤੇ ਚਤੁਰ ਬਫਰ ਦੁਬਾਰਾ ਵਰਤੋਂ।
ਪਰ ਉਲਟ ਵੀ ਸੱਚ ਹੈ: ਜੇ ਤੁਸੀਂ ਇੱਕ ਨਰਮ ਇੰਟਰਫੇਸ ਜਾਂ ਧਨੀ ਗ੍ਰਾਫਿਕਸ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਹਾਰਡਵੇਅਰ ਨੂੰ ਮੁੜ ਡਿਜ਼ਾਈਨ ਕਰ ਸਕਦੇ ਹੋ ਤਾਂ ਕਿ ਸਾਫਟਵੇਅਰ ਹਰ ਬਾਈਟ ਅਤੇ ਸਾਈਕਲ ਲਈ ਜੰਗ ਨਾ ਕਰੇ।
ਸ਼ੁਰੂਆਤੀ ਪੀਸੀਜ਼ 'ਤੇ ਤੁਸੀਂ ਅਕਸਰ ਜੋੜੀ ਨੂੰ "ਮਹਿਸੂਸ" ਕਰ ਸਕਦੇ ਸੀ ਕਿਉਂਕਿ ਇਹ ਸਕ੍ਰੀਨ 'ਤੇ ਕੀ ਦਿਖਦਾ ਹੈ ਅਤੇ ਕਦੋਂ ਦਿਖਦਾ ਹੈ ਨੂੰ ਪ੍ਰਭਾਵਤ ਕਰਦਾ ਸੀ।
ਇਸ ਕਠੋਰ ਫਿੱਟ ਦਾ ਅਨੁਪਾਤ ਸਪਸ਼ਟ ਹੈ: ਗਤੀ (ਘੱਟ ਓਵਰਹੈਡ), ਘੱਟ ਲਾਗਤ (ਘੱਟ ਚਿੱਪ ਅਤੇ ਪਰਤਾਂ), ਅਤੇ ਅਕਸਰ ਇੱਕ ਹੋਰ ਇਕਸਾਰ ਉਪਭੋਗੀ ਅਨੁਭਵ।
ਨੁਕਸਾਨ ਵੀ ਗੰਭੀਰ ਹੈ: ਅਪਗਰੇਡ ਮੁਸ਼ਕਲ ਹੋ ਸਕਦੀਆਂ ਹਨ (ਹਾਰਡਵੇਅਰ ਬਦਲੋ ਅਤੇ ਪੁਰਾਣੀ ਸਾਫਟਵੇਅਰ ਟੁੱਟ ਸਕਦੀ ਹੈ), ਅਤੇ ਛੁਪੀ ਜਟਿਲਤਾ (ਸਾਫਟਵੇਅਰ ਵਿੱਚ ਹਾਰਡਵੇਅਰ ਅਨੁਮਾਨ ਹੁੰਦੇ ਹਨ ਜੋ ਫੇਲ ਹੋਣ 'ਤੇ ਹੀ ਸਪਸ਼ਟ ਹੁੰਦੇ ਹਨ)।
ਇਕਤ੍ਰਿਤਤਾ ਆਪੋ-ਅਪਣੇ ਵਧੀਆ ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ ਜਾਣਬੂਝ ਕੇ ਕੀਤੀ ਚੋਣ ਹੈ: ਲਚਕੀਲਾਪਣ ਦੇ ਬਦਲੇ ਕੁਸ਼ਲਤਾ ਅਤੇ ਸੰਗਠਨ ਲਈ ਟਰੇਡ-ਆਫ਼—ਤੇ ਸਫਲ ਹੋਣ ਲਈ ਟੀਮ ਨੂੰ ਇਹ ਸਵੀਕਾਰ ਕਰਨਾ ਪੈਂਦਾ ਕਿ ਉਹ ਕੀ ਲਾਕ-ਇਨ ਕਰ ਰਹੀ ਹੈ।
ਇਕਤ੍ਰਿਤਤਾ ਇੱਕ ਅੰਦਰੂਨੀ ਇੰਜੀਨੀਅਰਿੰਗ ਚੋਣ ਦੀ ਤਰ੍ਹਾਂ ਲੱਗਦੀ ਹੈ, ਪਰ ਉਪਭੋਗੀ ਇਸਨੂੰ ਗਤੀ, ਭਰੋਸੇਯੋਗਤਾ, ਅਤੇ ਸ਼ਾਂਤੀ ਵਜੋਂ ਮਹਿਸੂਸ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਹਾਰਡਵੇਅਰ ਅਤੇ ਸਾਫਟਵੇਅਰ ਇੱਕ ਪ੍ਰਣਾਲੀ ਵਜੋਂ ਡਿਜ਼ਾਈਨ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਮਸ਼ੀਨ ਅਕਸਰ ਮਿਲਾਪ-ਅਨੁਕੂਲਤਾ ਸੋਚਣ ਦੀ ਬਜਾਏ ਤੁਹਾਡੇ ਆਦੇਸ਼ ਨੂੰ ਨਿਭਾਉਣ 'ਤੇ ਧਿਆਨ ਕੇਂਦ੍ਰਿਤ ਕਰ ਸਕਦੀ ਹੈ।
ਇੱਕ ਇਕਤ੍ਰਿਤ ਸਿਸਟਮ ਸਮਝਦਾਰੀ ਨਾਲ ਛੋਟੇ-ਛੋਟੇ ਸ਼ਾਰਟਕਟ ਲੈ ਸਕਦਾ ਹੈ: ਜਾਣੇ-ਪਛਾਣ ਵਾਲੇ ਡਿਸਪਲੇ ਟਾਈਮਿੰਗ, ਜਾਣੇ-ਪਛਾਣ ਵਾਲੇ ਇਨਪੁੱਟ ਡਿਵਾਈਸ, ਜਾਣੇ-ਪਛਾਣ ਵਾਲੀ ਮੈਮੋਰੀ-ਮੈਪ, ਜਾਣੇ-ਪਛਾਣ ਵਾਲਾ ਸਟੋਰੇਜ ਵਿਹਾਰ। ਇਹ ਪੇਸ਼ਗੋਈ ਪਰਤਾਂ ਅਤੇ ਵਰਕਅਰਾਉਂਡ ਘਟਾਉਂਦਾ।
ਨਤੀਜਾ ਇਹ ਹੈ ਕਿ ਇੱਕ ਕੰਪਿਊਟਰ ਤੇਜ਼ ਲੱਗਦਾ ਹੈ ਭਾਵੇਂ ਰੋ-ਮੁੱਖ ਹਿੱਸੇ ਬਹੁਤ ਜ਼ਿਆਦਾ ਵੱਖਰੇ ਨਾ ਹੋਣ। ਪ੍ਰੋਗਰਾਮ ਇੱਕ ਨਿਰਭਰ ਤਰੀਕੇ ਨਾਲ ਲੋਡ ਹੁੰਦੇ ਹਨ, ਪਰਿਫੇਰਲ ਉਮੀਦ ਮੁਤਾਬਕ ਵਰਤੋਂ ਕਰਦੇ ਹਨ, ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਉਸ ਸਮੇਂ ਤੇ ਬੜੀ ਭਿੰਨਤਾ ਨਹੀਂ ਦਿਖਾਉਂਦਾ ਜਿਸ ਤਰ੍ਹਾਂ ਕਿਸੇ ਤੀਜੀ-ਪੱਖੀ ਭਾਗ ਦੇ ਚੋਣ 'ਤੇ ਨਿਰਭਰ ਹੋਵੇ।
ਉਪਭੋਗੀ ਅਕਸਰ ਇਹ ਨਹੀਂ ਦੇਖਦਾ ਕਿ ਕਿਉਂ ਕੁਝ ਟੁਟਿਆ—ਉਹ ਇਸ ਗੱਲ ਦੀ ਫਿਕਰ ਕਰਦਾ ਹੈ ਕਿ ਕੌਣ ਠੀਕ ਕਰੇਗਾ। ਇਕਤ੍ਰਿਤਤਾ ਸਪਸ਼ਟ ਸਹਾਇਤਾ ਸਰਹੱਦ ਬਣਾਉਂਦੀ ਹੈ: ਸਿਸਟਮ ਨਿਰਮਾਤਾ ਪੂਰੇ ਅਨੁਭਵ ਦਾ ਮਾਲਕ ਹੁੰਦਾ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਆਮ ਤੌਰ 'ਤੇ ਘੱਟ "ਤੁਹਾਡੀ ਪ੍ਰਿੰਟਰ ਕਾਰਡ ਹੋਣੀ ਚਾਹੀਦੀ" ਵਾਲੀ ਹਾਲਤਾਂ ਅਤੇ ਵਧ ਘੱਟ ਉੱਪਰ-ਉਹ-ਮੀਦਾਨੀ ਇਸ਼ਾਰਿਆਂ।
ਸਥਿਰਤਾ ਛੋਟੀਆਂ ਚੀਜ਼ਾਂ ਵਿੱਚ ਵੀ ਨਜ਼ਰ ਆਉਂਦੀ ਹੈ: ਕਿਵੇਂ ਟੈਕਸਟ ਸਕ੍ਰੀਨ 'ਤੇ ਦਿਖਦਾ ਹੈ, ਕਿਵੇਂ ਕੀਜ਼ ਦੁਹਰਾਉਂਦੀਆਂ ਹਨ, ਕਿਵੇਂ ਆਵਾਜ਼ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਜਦੋਂ ਤੁਸੀਂ ਮਸ਼ੀਨ ਚਾਲੂ ਕਰਦੇ ਹੋ ਤਾਂ ਕਿਵੇਂ ਵਰਤਾਰਾ ਹੁੰਦਾ ਹੈ। ਜਦੋਂ ਇਹ ਮੂਲਭੂਤ ਤੱਤ ਸਥਿਰ ਹੁੰਦੇ ਹਨ, ਲੋਕ ਤੇਜ਼ੀ ਨਾਲ ਭਰੋਸਾ ਬਣਾਉਂਦੇ ਹਨ।
ਡੀਫ਼ਾਲਟਸ ਉਹ ਥਾਂ ਹਨ ਜਿੱਥੇ ਇਕਤ੍ਰਿਤਤਾ ਉਤਪਾਦ ਲਾਭ ਬਣਦੀ ਹੈ। ਬੂਟ ਵਿਹਾਰ ਭਵਿਸ਼ਵਨੀਯ ਹੁੰਦਾ ਹੈ। ਬੰਨ੍ਹੇ ਟੂਲਾਂ ਮੌਜੂਦ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਪਲੇਟਫਾਰਮ ਮਾਲਕ ਕੁਝ ਯੋਗਤਾਵਾਂ ਦੀ ਅਪੇਖਾ ਕਰ ਸਕਦਾ ਹੈ। ਸੈੱਟਅਪ ਕਦਮ ਘੱਟ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਸਿਸਟਮ ਮਾੜਾ-ਸੋਚ ਚੁੱਕ ਕੇ ਜ਼ਰੂਰੀ ਚੋਣਾਂ ਪਹਿਲੇ ਤੋਂ ਕਰ ਸਕਦਾ ਹੈ।
ਇਸਦਾ ਮੁਕਾਬਲਾ ਉਹਨਾਂ ਮਿਸ-ਮੇਲਡ ਕੰਪੋਨੈਂਟਾਂ ਨਾਲ ਕਰੋ: ਇੱਕ ਮਾਨੀਟਰ ਜੋ ਖ਼ਾਸ ਟਾਈਮਿੰਗ ਮੰਗਦਾ ਹੈ, ਇੱਕ ਡਿਸਕ ਕੰਟਰੋਲਰ ਜਿਸਦੇ ਅਜੀਬ ਖ਼ਾਸੀਅਤਾਂ ਹਨ, ਇੱਕ ਮੈਮੋਰੀ ਐਕਸਪੈਨਸ਼ਨ ਜੋ ਵਿਹਾਰ ਬਦਲ ਦਿੰਦਾ ਹੈ, ਜਾਂ ਸਾਫਟਵੇਅਰ ਜੋ ਵੱਖ-ਵੱਖ ਸੰਰਚਨਾਵਾਂ ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ। ਹਰ ਮਿਲਾਪ ਘਰੜੀ ਵਧਾਉਂਦਾ—ਵਧ ਮੈਨੁਅਲ, ਵਧ ਟਵੀਕ, ਵਧ ਫੇਲ ਹੋਣ ਦੇ ਮੌਕੇ।
ਇਕਤ੍ਰਿਤਤਾ ਸਿਰਫ਼ ਮਸ਼ੀਨਾਂ ਨੂੰ "ਚੰਗਾ" ਮਹਿਸੂਸ ਕਰਵਾਉਂਦੀ ਨਹੀਂ; ਇਹ ਉਨ੍ਹਾਂ ਨੂੰ ਭਰੋਸੇਯੋਗ ਬਣਾਉਂਦੀ ਹੈ।
ਡਿਜ਼ਾਈਨ ਟਰੇਡ-ਆਫ਼ ਇੱਕ ਜਾਣਬੂਝ ਕੇ ਚੋਣ ਹੈ ਜਿਸ ਵਿੱਚ ਇੱਕ ਪੱਖ ਨੂੰ ਬਿਹਤਰ ਕਰਨ ਲਈ ਕਿਸੇ ਹੋਰ ਪੱਖ 'ਤੇ ਕੀਮਤ ਮਨਜ਼ੂਰ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਇਹ ਉਤਪਾਦ ਟੀਮਾਂ ਹਰ ਵੇਲੇ ਕਰਦੀਆਂ ਹਨ—ਭਾਵੇਂ ਉਹ ਇਸਨੂੰ ਮੰਨਦੇ ਹੋਣ ਜਾਂ ਨਹੀਂ।
ਸ਼ੁਰੂਆਤੀ ਪੀਸੀਜ਼ ਵਿੱਚ, “ਸਧਾਰਨ” ਇਕ ਸਟਾਇਲ ਪ੍ਰਿਫਰੈਂਸ ਨਹੀਂ ਸੀ; ਇਹ ਸਖਤ ਸੀਮਾਵਾਂ ਦਾ ਨਤੀਜਾ ਸੀ। ਭਾਗ ਮਹਿੰਗੇ ਸਨ, ਮੈਮੋਰੀ ਸੀਮਿਤ ਸੀ, ਅਤੇ ਹਰ ਵਾਧੂ ਚਿੱਪ ਨਾਲ ਕੀਮਤ, ਅਸੈਂਬਲੀ ਸਮਾਂ, ਅਤੇ ਫੇਲ ਦੇ ਬਿੰਦੂ ਵਧਦੇ।
ਸਿਸਟਮ ਨੂੰ ਪਹੁੰਚਯੋਗ ਬਣਾਈ ਰੱਖਣਾ ਮਤਲਬ ਸੀ ਕਿ ਤੁਸੀਂ ਸੋਚੋ ਕਿ ਕੀ ਛੱਡਣਾ ਹੈ।
ਫੀਚਰ ਜੋੜਨਾ ਗਾਹਕ-ਮਿੱਤਰ ਹੋ ਸਕਦਾ ਹੈ ਜਦ ਤੱਕ ਤੁਸੀਂ ਬਿਲ ਆਉਟ ਨਹੀਂ ਕਰਦੇ। ਟੀਮਾਂ ਨੂੰ ਪੁੱਛਣਾ ਪੈਂਦਾ:
"ਕਾਫ਼ੀ" ਫੀਚਰਾਂ ਚੁਣਨਾ — ਉਹ ਜੋ ਅਸਲ ਵਰਤੋਂ ਖੋਲ੍ਹਦੇ ਹਨ — ਅਕਸਰ ਸਭ ਕੁਝ ਤੇchnਿਕੀ ਤੌਰ 'ਤੇ ਸੰਭਵ ਪੈਕ ਕਰਨ ਨਾਲ ਬਿਹਤਰ ਹੁੰਦਾ ਹੈ।
ਖੁੱਲ੍ਹੇ ਸਿਸਟਮ ਟਿੰਕਰਿੰਗ, ਵਿਸਥਾਰ ਅਤੇ ਤੀਜੀ-ਪੱਖੀ ਨਵੀਨਤਾ ਨੂੰ ਆਮੰਤਰਿਤ ਕਰਦੇ ਹਨ। ਪਰ ਖੁੱਲ੍ਹਾ-ਪਨ ਵੀ ਗੁੰਝਲਦਾਰ ਚੋਣਾਂ, ਅਨੁਕੂਲਤਾ ਸਮੱਸਿਆਵਾਂ ਅਤੇ ਵੱਧ ਸਹਾਇਤਾ ਬੋਝ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ।
ਇੱਕ ਸਧਾਰਾ, ਵਧ ਇਕਤ੍ਰਿਤ ਦ੍ਰਿਸ਼ਟੀ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦੀ ਹੈ, ਫਿਰ ਵੀ ਇਹ ਪਹਿਲੀ ਵਾਰ ਦਾ ਅਨੁਭਵ ਸੁਚੱਜਾ ਕਰ ਦਿੰਦਾ ਹੈ।
ਸਪਸ਼ਟ ਸੀਮਾਵਾਂ ਇੱਕ ਛਾਣ-ਨਿਕਾਸ ਵਾਂਗ ਕੰਮ ਕਰਦੀਆਂ ਹਨ। ਜੇ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਨਿਸ਼ਚਤ ਕੀਮਤ, ਮੈਮੋਰੀ ਛੱਤ, ਅਤੇ ਨਿਰਮਾਣ ਜਟਿਲਤਾ ਯੋਗਤਾ ਜਾਣਦੇ ਹੋ, ਤਾਂ ਬਹੁਤ ਚਰਚਾ ਖਤਮ ਹੋ ਜਾਂਦੀ ਹੈ।
ਬਜਾਏ ਅਨੰਤ ਆਇਡੀਏ-ਸੂਚੀ ਦੇ, ਟੀਮ ਉਨ੍ਹਾ ਹੱਲਾਂ 'ਤੇ ਧਿਆਨ ਕਰਦੀ ਹੈ ਜੋ ਫਿੱਟ ਹੁੰਦੇ ਹਨ।
ਆਧੁਨਿਕ ਟੀਮਾਂ ਲਈ ਸਬਕ ਇਹ ਹੈ ਕਿ ਪਹਿਲਾਂ ਸੀਮਾਵਾਂ ਚੁਨੋ — ਬਜਟ, ਪ੍ਰਦਰਸ਼ਨ ਟਾਰਗੇਟ, ਇਕਤ੍ਰਿਤਤਾ ਪੱਧਰ, ਅਤੇ ਟਾਈਮਲਾਈਨ — ਅਤੇ ਉਨਾਂ ਨੂੰ ਫੈਸਲਾ ਕਰਨ ਵਾਲੇ ਔਜ਼ਾਰ ਸਮਝੋ।
ਟਰੇਡ-ਆਫ਼ ਤੇਜ਼ ਅਤੇ ਵਾਧੂ ਪਰਦਰਸ਼ੀ ਬਣ ਜਾਂਦੇ ਹਨ, ਅਤੇ "ਸਧਾਰਨ" ਹੁਣ vague ਬ੍ਰਾਂਡਿੰਗ ਨਹੀਂ ਰਹਿੰਦਾ; ਇਹ ਇੱਕ ਇੰਜੀਨੀਅਰ ਕੀਤਾ ਨਤੀਜਾ ਬਣ ਜਾਂਦਾ ਹੈ।
ਇੰਜੀਨੀਅਰਿੰਗ-ਪokuqala ਟੀਮਾਂ ਬੇਝਿੱਝਕ ਨਹੀਂ ਕਾਮ ਕਰਦੀਆਂ ਅਤੇ ਫਿਰ ਕਹਾਣੀ ਪੋਲਿਸ਼ ਨਹੀਂ ਕਰਦੀਆਂ। ਉਹ ਫੈਸਲੇ ਪਬਲਿਕ ਤਰੀਕੇ ਨਾਲ ਲੈਂਦੀਆਂ ਹਨ, ਸੀਮਾਵਾਂ ਲਿਖ ਕੇ ਰੱਖਦੀਆਂ ਹਨ, ਅਤੇ ਪੂਰੇ ਸਿਸਟਮ (ਹਾਰਡਵੇਅਰ + ਸਾਫਟਵੇਅਰ) ਨੂੰ ਉਤਪਾਦ ਵਜੋਂ ਦੇਖਦੀਆਂ ਹਨ—ਨਾ ਕਿ ਵੱਖ-ਵੱਖ ਭਾਗਾਂ ਵਜੋਂ।
ਇੱਕ ਹਲਕਾ ਫੈਸਲਾ ਲੌਗ ਟੀਮਾਂ ਨੂੰ ਇੱਕੋ-ਜਿਹੀਆਂ ਚਰਚਾਂ ਦੁਹਰਾਉਣ ਤੋਂ ਰੋਕਦਾ ਹੈ। ਸਧਾਰਨ ਰੱਖੋ: ਹਰ ਫੈਸਲੇ ਲਈ ਇੱਕ ਪੰਨਾ ਜਿਸ ਵਿੱਚ ਸੰਦਰਭ, ਸੀਮਾਵਾਂ, ਵਿਚਾਰੇ ਗਏ ਵਿਕਲਪ, ਤੁਸੀਂ ਕੀ ਚੁਣਿਆ, ਅਤੇ ਕੀ ਜਾਣ-ਬੁਝ ਕੇ ਅਣ-ਆਪਟੀਮਾਈਜ਼ ਕੀਤਾ ਗਿਆ ਹੈ।
ਚੰਗੀ ਇੰਜੀਨੀਅਰਿੰਗ-ਪਹਿਲਾ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਵਿਸ਼ੇਸ਼ ਹੁੰਦੀ ਹੈ:
ਕੰਪੋਨੈਂਟ ਟੈਸਟ ਜ਼ਰੂਰੀ ਹਨ, ਪਰ ਇਕਤ੍ਰਿਤ ਉਤਪਾਦ ਸਰਹੱਦਾਂ 'ਤੇ ਫੇਲ ਹੁੰਦੇ ਹਨ: ਟਾਈਮਿੰਗ, ਅਨੁਮਾਨ, ਅਤੇ "ਮੇਰੇ ਬੈਂਚ ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ" ਖਾਈ।
ਇੱਕ ਇੰਜੀਨੀਅਰਿੰਗ-ਪਹਿਲਾ ਟੈਸਟਿੰਗ ਸਟੈਕ ਆਮ ਤੌਰ 'ਤੇ ਸ਼ਾਮਿਲ ਕਰਦਾ ਹੈ:
ਦਿਸ਼ਾ-ਨਿਰਦੇਸ਼: ਜੇ ਉਪਭੋਗੀ ਨਿਰਦੇਸ਼ਿਤ ਵਰਕਫਲੋ ਫੋਲੋ ਕਰੇ, ਕੀ ਉਹ ਲਗਾਤਾਰ ਮਨਚਾਹਾ ਨਤੀਜਾ ਪਾਵੇਗਾ?
ਇਕਤ੍ਰਿਤ ਸਿਸਟਮ ਲੈਬ ਤੋਂ ਬਾਹਰ ਵੱਖ-ਵੱਖ ਤਰੀਕਿਆਂ ਨਾਲ ਵਰਤਦੇ ਹਨ—ਵੱਖ ਪਰਿਫੇਰਲ, ਪਾਵਰ ਗੁਣਵੱਤਾ, ਤਾਪਮਾਨ, ਅਤੇ ਉਪਭੋਗੀ ਆਚਰਨ। ਇੰਜੀਨੀਅਰਿੰਗ-ਪਹਿਲਾ ਟੀਮਾਂ ਤੇਜ਼ ਫੀਡਬੈਕ ਲੱਭਦੀਆਂ ਹਨ:
ਰਿਵਿਊਜ਼ ਨੂੰ ਵਿਸ਼ੇਸ਼ ਬਣਾਓ: ਵਰਕਫਲੋ ਡੈਮੋ ਕਰੋ, ਮਾਪ ਦਰਸਾਓ, ਅਤੇ ਦੱਸੋ ਕਿ ਪਿਛਲੇ ਰਿਵਿਊ ਤੋਂ ਕੀ ਬਦਲਿਆ।
ਇੱਕ ਉਪਯੋਗੀ ਅਜੰਡਾ:
ਇਹ “ਇੰਜੀਨੀਅਰਿੰਗ-ਪਹਿਲਾ” ਨੂੰ ਨਾਅਰੇ ਵਜੋਂ ਰਹਿਣ ਤੋਂ ਰੋਕਦਾ ਹੈ—ਅਤੇ ਇਸਨੂੰ ਦੁਹਰਾਏ ਜਾਣਯੋਗ ਟੀਮ ਰਵੱਈਏ ਵਿੱਚ ਪ bad ਰਦਾ ਹੈ।
Apple II ਵਰਗੀਆਂ ਇਕਤ੍ਰਿਤ ਡਿਜ਼ਾਈਨਾਂ ਨੇ ਇੱਕ ਢਾਂਚਾ ਸੈੱਟ ਕੀਤਾ ਜੋ ਬਾਅਦ ਦੀਆਂ ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਨੇ ਅਧਿਐਨ ਕੀਤਾ: ਕੰਪਿਊਟਰ ਨੂੰ ਇੱਕ ਪੂਰੇ ਅਨੁਭਵ ਵਜੋਂ ліку, ਨਾ ਕਿ ਅਨੁਕੂਲ ਭਾਗਾਂ ਦੇ ਢੇਰ ਵਜੋਂ।
ਉਹ ਸਬਕ ਹਰ ਭਵਿੱਖੀ ਮਸ਼ੀਨ ਨੂੰ ਇਕ ਪ੍ਰਭਾਵਵਾਨ ਨਿਯਮ ਨਹੀਂ ਬਣਾਉਂਦਾ, ਪਰ ਇਹ ਇੱਕ ਨਜ਼ੀਰ ਰੱਖਦਾ ਹੈ—ਜਦੋਂ ਇੱਕ ਟੀਮ স্টैक ਦਾ ਵੱਧ ਹਿੱਸਾ ਨਿਯੰਤਰਿਤ ਕਰਦੀ ਹੈ, ਤਾਂ ਪੂਰੇ ਅਨੁਭਵ ਨੂੰ ਮਨਜ਼ੂਰਯੋਗ ਬਣਾਉਣਾ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ।
ਜਿਵੇਂ ਹੀ ਪਰਸਨਲ ਕੰਪਿਊਟਰ ਫੈਲੇ, ਕਈ ਕੰਪਨੀਆਂ ਨੇ ਕੀਬੋਰਡ-ਪਾਸੇ ਘਟਾਉਣ ਦਾ ਵਿਚਾਰ ਅਪਣਾਇਆ: ਕਮਿ0 ਰੁਕਾਵਟਾਂ, ਘੱਟ ਮਿਲਾਪ-ਸਮੱਸਿਆਵਾਂ, ਅਤੇ ਸਪਸ਼ਟ "ਇਸਨੂੰ ਕਿਵੇਂ ਵਰਤਣਾ ਹੈ" ਡਿਫ਼ਾਲਟ।
ਇਸਦਾ ਅਕਸਰ ਮਤਲਬ ਸੀ ਕਿ ਹਾਰਡਵੇਅਰ ਚੋਣਾਂ (ਪੋਰਟ, ਮੈਮੋਰੀ, ਸਟੋਰੇਜ, ਡਿਸਪਲੇ) ਅਤੇ ਉਪਰ ਉਸਤੇ ਬਣੇ ਸਾਫਟਵੇਅਰ ਅਨੁਮਾਨਾਂ ਵਿਚ ਦਰੁਸਤ ਤਾਲਮੇਲ ਹੋਵੇ।
ਉਸੇ ਸਮੇਂ ਉਦਯੋਗ ਨੇ ਵਿippi
(ਨੋਟ: ਇਸ ਹਿਸੇ ਵਿੱਚ ਮੂਲ ਪੋਸਟ ਨੇ ਜ਼ਿਕਰ ਕੀਤਾ ਕਿ ਉਦਯੋਗ ਨੇ ਵੱਧ ਮੋਡਿਊਲਰਤਾ ਦੀ ਵੀ ਸਿੱਖਿਆ ਲਈ — ਮੈਸੇਜ ਨੂੰ ਇੰਗਲਿਸ਼ ਤੋਂ ਪ੍ਰਭਾਵਤ ਕੀਤਾ ਗਿਆ ਹੈ)
ਘਰੇਲੂ ਕੰਪਿਊਟਿੰਗ ਵਿੱਚ, ਇਕਤ੍ਰਿਤ ਸਿਸਟਮਾਂ ਨੇ ਉਮੀਦਾਂ ਨੂੰ ਮਜ਼ਬੂਤ ਕੀਤਾ ਕਿ ਇੱਕ ਕੰਪਿਊਟਰ ਨੂੰ ਜਲਦੀ ਤਿਆਰ ਮਹਿਸੂਸ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਲਾਗੂ ਸਾਫਟਵੇਅਰ ਨਾਲ ਆਉਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਨਿਰਧਾਰਿਤ ਤਰੀਕੇ ਨਾਲ ਵਰਤਣਾ ਚਾਹੀਦਾ ਹੈ।
"ਇੰਸਟੈਂਟ-ਅਨ" ਮਹਿਸੂਸ ਅਕਸਰ ਇੱਕ ਭ੍ਰਮ ਹੁੰਦਾ ਹੈ ਜੋ ਸਮਾਰਟ ਇੰਜੀਨੀਅਰਿੰਗ — ਤੇਜ਼ ਬੂਟ ਰਾਹ, ਸਥਿਰ ਸੰਰਚਨਾ, ਅਤੇ ਘੱਟ ਅਣਜਾਣੀਆਂ — ਨਾਲ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ।
ਇਕਤ੍ਰਿਤਤਾ ਦੇ ਨਮੂਨੇ ਵੱਖ-ਵੱਖ ਸ਼੍ਰੇਣੀਆਂ ਵਿੱਚ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ: ਕੰਸੋਲਜ਼ ਜਿਨ੍ਹਾਂ ਨੇ ਸਖ਼ਤ ਹਾਰਡਵੇਅਰ ਟਾਰਗੇਟਾਂ ਨੂੰ ਨਿਯੰਤਰਤ ਕੀਤਾ, ਲੈਪਟਾਪ ਜੋ ਬੈਟਰੀ ਅਤੇ ਥਰਮਲ ਸੀਮਾ ਅਨੁਸਾਰ ਡਿਜ਼ਾਈਨ ਕੀਤੇ गए, ਅਤੇ ਆਧੁਨਿਕ PC ਜੋ ਫਰਮਵੇਅਰ, ਡਰਾਇਵਰ ਅਤੇ ਯੂਟਿਲਿਟੀ ਨੂੰ ਇਕੱਠੇ ਪੈਕੇਜ ਕਰਦੇ ਹਨ ਤਾ ਕਿ ਬਾਕਸ ਤੋਂ ਬਾਹਰ ਤਜਰਬਾ ਸੁਘੜ ਹੋਵੇ।
ਲਫ਼ਜ਼ ਅਲੱਗ ਹੋ ਸਕਦੇ ਹਨ, ਪਰ ਲਕੜੀ ਇਕੋ ਹੈ: ਪ੍ਰਾਇਕਟਿਕ ਕੰਪਿਊਟਿੰਗ ਜੋ ਲੋਕਾਂ ਦੀ ਉਮੀਦ ਮੂਤਾਬਕ ਕੰਮ ਕਰਦੀ ਹੈ, ਬਿਨਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਪਹਿਲਾਂ ਟੈਕਨੀਸ਼ਨ ਬਣਨ ਦੀ ਜ਼ਰੂਰਤ ਹੋਵੇ।
Wozniak ਦੇ ਸਮੇਂ ਨੇ ਤੰਗ ਜੁੜਾਈ ਨੂੰ ਇਨਾਮ ਦਿੱਤਾ ਕਿਉਂਕਿ ਇਸ ਨਾਲ ਭਾਗ, ਲਾਗਤ ਅਤੇ ਫੇਲ-ਬਿੰਦੂ ਘੱਟ ਹੋ ਰਹੇ ਸਨ। ਉਹੀ ਤਰਕ ਅਜੇ ਵੀ ਲਾਗੂ ਹੁੰਦੀ ਹੈ—ਸਿਰਫ਼ ਹਿੱਸੇ ਵੱਖਰੇ ਹਨ।
ਇਕਤ੍ਰਿਤਤਾ ਨੂੰ ਪਰਤਾਂ ਦਰਮਿਆਨ ਦੇ ਦਰਾਰੇ ਡਿਜ਼ਾਈਨ ਕਰਨ ਵਾਂਗ ਸੋਚੋ ਤਾਂ ਕਿ ਉਪਭੋਗੀ ਉਨਾਂ ਨੂੰ ਮਹਿਸੂਸ ਨਾ ਕਰੇ। ਆਮ ਉਦਾਹਰਨਾਂ ਵਿੱਚ ਫਰਮਵੇਅਰ ਜੋ OS ਨਾਲ ਹੱਥ-ਮਿ and ਕੰਮ ਕਰਦਾ ਹੈ, ਕੁਝ ਮੁੱਖ ਕਾਰਜਾਂ ਨੂੰ ਤੇਜ਼ ਕਰਨ ਵਾਲੇ ਕਸਟਮ ਚਿਪ, ਧੁਰੇ-ਤੌਰ 'ਤੇ ਤਿਆਰ ਕੀਤੇ ਡਰਾਇਵਰ, ਅਤੇ ਬੈਟਰੀ/ਪ੍ਰਦਰਸ਼ਨ ਟਿਊਨਿੰਗ ਜੋ ਪਾਵਰ, ਥਰਮਲ ਅਤੇ ਪ੍ਰਤੀਕਿਰਿਆ ਨੂੰ ਇੱਕ ਸਿਸਟਮ ਸਮਝਦਾ ਹੈ।
ਜਦੋਂ ਇਹ ਚੰਗਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਘੱਟ ਅਚਨਚੇਤੀਆਂ ਮਿਲਦੀਆਂ ਹਨ: sleep/wake ਅਨੁਭਵ ਪੂਰਨ ਹੁੰਦਾ ਹੈ, ਪਰਿਫੇਰਲ "ਸਿਰਫ਼ ਕੰਮ" ਕਰਦੇ ਹਨ, ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਹਕੀਕਤੀ ਵਰਕਲੋਡਾਂ ਹੇਠਾਂ ਗਿੱਧੇ ਨਹੀਂ ਹੁੰਦਾ।
ਇੱਕ ਆਧੁਨਿਕ ਸਾਫਟਵੇਅਰ ਸਮਾਨਤਉ ਉਦਾਹਰਨ ਉਹ ਹੈ ਜਦੋਂ ਟੀਮਾਂ ਜਾਣ-ਬੁਝ ਕੇ ਉਤਪਾਦ ਇਰਾਦਾ ਅਤੇ ਐਮਪਲਿਮੈਂਟੇਸ਼ਨ ਦਰਮਿਆਨ ਦੀ ਦੂਰੀ ਨੂੰ ਘਟਾਉਂਦੀਆਂ ਹਨ। ਉਦਾਹরণ ਲਈ, ਪਲੇਟਫਾਰਮਾਂ ਜਿਵੇਂ Koder.ai ਇੱਕ ਚੈਟ-ਚਲਾਇਤ ਵਰਕਫਲੋ ਵਰਤਦੇ ਹਨ ਜੋ ਪੂਰਾ-ਸਟੈਕ ਐਪਸ (React ਵੈਬ, Go + PostgreSQL ਬੈਕਐਂਡ, Flutter ਮੋਬਾਈਲ) ਤਿਆਰ ਕਰਨ ਲਈ ਯੋਜਨਾ ਅਤੇ ਰੋਲਬੈਕ ਟੂਲ ਦਿੰਦਾ ਹੈ। ਚਾਹੇ ਤੁਸੀਂ ਪਾਰੰਪੜਿਕ ਕੋਡਿੰਗ ਵਰਤੋਂ ਜਾਂ vibe-coding ਪਲੇਟਫਾਰਮ, "ਇੰਜੀਨੀਅਰਿੰਗ-ਪਹਿਲਾ" ਬਿੰਦੂ ਇੱਕੋ ਰਹਿੰਦਾ ਹੈ: ਪਹਿਲਾਂ ਸੀਮਾਵਾਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ (time-to-first-success, ਭਰੋਸੇਯੋਗਤਾ, ਚਲਾਉਣ ਦੀ ਲਾਗਤ), ਫਿਰ ਇੱਕ ਇਕਤ੍ਰਿਤ ਰਾਹ ਬਣਾਓ ਜਿਸ ਨੂੰ ਉਪਭੋਗੀ ਦੁਹਰਾਉ ਸਕੇ।
ਇਕਤ੍ਰਿਤਤਾ ਲਾਭਕਾਰੀ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਉਪਭੋਗੀ-ਦਿੱਖ ਵਾਲਾ ਫਾਇਦਾ ਸਪਸ਼ਟ ਹੋ ਅਤੇ ਜਟਿਲਤਾ ਕੰਟਰੋਲਯੋਗ ਹੋਵੇ:
ਜਦੋਂ ਵਿਭਿੰਨਤਾ ਅਤੇ ਬਦਲਾਅ ਹੀ ਮੱਕਸਦ ਹੋਵੇ ਮੋਡਿਊਲਰਟੀ ਚੰਗੀ ਚੋਣ ਹੁੰਦੀ ਹੈ:
ਪੂਛੋ:
ਜੇ ਤੁਸੀਂ ਉਪਭੋਗੀ-ਦੇਖਣ ਯੋਗ ਜੀਤ ਨਹੀਂ ਨਾਮ ਲੈ ਸਕਦੇ, ਤਾਂ ਡੀਫਾਲਟ ਤੌਰ 'ਤੇ ਮੋਡਿਊਲਰ ਰਹੋ।
Wozniak ਦਾ ਕੰਮ ਯਾਦ ਦਿਵਾਉਂਦਾ ਹੈ ਕਿ “ਇੰਜੀਨੀਅਰਿੰਗ-ਪਹਿਲਾ” ਕਿਸੇ ਤਕਨੀਕੀ ਚਮਕ ਦੀ ਸੇਵਾ ਨਹੀਂ ਹੈ। ਇਹ ਜਾਣਬੁਝ ਕੇ ਟਰੇਡ-ਆਫ਼ ਕਰਨ ਬਾਰੇ ਹੈ ਤਾਂ ਕਿ ਉਤਪਾਦ ਜਲਦੀ “ਵਰਤੋਂਯੋਗ” ਤੱਕ ਪਹੁੰਚੇ, ਸਮਝਣਯੋਗ ਰਹੇ, ਅਤੇ ਇਕ ਜੁੱਟ ਰੂਪ ਵਿੱਚ ਭਰੋਸੇਯੋਗ ਕੰਮ ਕਰੇ।
ਟੀਮਾਂ ਨੂੰ ਇਨ੍ਹਾਂ ਫੈਸਲਿਆਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਸਹਮਤੀ ਲਈ ਇੱਕ ਹਲਕਾ-ਫੁਲਕਾ ਤਰੀਕਾ ਚਾਹੀਦਾ ਹੈ, ਉਸ ਬਾਰੇ ਦੇਖੋ /blog/product-culture-basics.
ਇੱਕ ਇੰਜੀਨੀਅਰਿੰਗ-ਪਹਿਲਾ ਉਤਪਾਦ ਸਭਿਆਚਾਰ ਉਹ ਹੈ ਜੋ ਸੀਮਾਵਾਂ ਨੂੰ ਡਿਜ਼ਾਈਨ ਇਨਪੁਟ ਮੰਨਦਾ ਹੈ: ਲਾਗਤ, ਭਾਗਾਂ ਦੀ ਉਪਲਬਧਤਾ, ਪਾਵਰ/ਥਰਮਲ ਸੀਮਾਵਾਂ, ਮੈਮੋਰੀ ਬਜਟ, ਨਿਰਮਾਣ ਫਲਦਾਇਕਤਾ ਅਤੇ ਸਹਾਇਤਾ ਦਾ ਬੋਝ। ਟੀਮ ਪਹਿਲਾਂ ਇਹ ਪڇਦੀ ਹੈ ਕਿ ਕੀ ਕੁਝ ਭਰੋਸੇਯੋਗ ਅਤੇ ਲਗਾਤਾਰ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ, ਫਿਰ ਇਸ ਨੂੰ ਕਿਸ ਤਰ੍ਹਾਂ ਪੈਕੇਜ ਅਤੇ ਸੰਪ੍ਰੇਸ਼ਿਤ ਕੀਤਾ ਜਾਵੇ।
ਇਹ ਦਾ ਮਤਲਬ ਨਹੀਂ ਕਿ "ਇੰਜੀਨੀਅਰ ਸਭ ਕੁਝ ਫੈਸਲਾ ਕਰਦੇ ਹਨ"; ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਸਿਸਟਮ ਨਿਰਮਾਣਯੋਗ, ਟੈਸਟਯੋਗ ਅਤੇ ਸਮਰਥਿਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਫੀਚਰ-ਪਹਿਲਾ ਕੰਮ ਅਕਸਰ ਇੱਕ ਵਿਸ਼ਲਿਸਟ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ ਅਤੇ ਤਕਨੋਲੋਜੀ ਨੂੰ ਉਸ ਦੇ ਅਨੁਸਾਰ ਠੋਸ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ। ਇੰਜੀਨੀਅਰਿੰਗ-ਪਹਿਲਾ ਕੰਮ ਹਕੀਕਤ — ਭੌਤਿਕੀ ਹਦਾਂ ਅਤੇ ਬਜਟ — ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ ਅਤੇ ਉਤਪਾਦ ਨੂੰ ਉਹਨਾਂ ਸੀਮਾਵਾਂ ਦੇ ਅੰਦਰ ਵਰਤਣਯੋਗ ਬਣਾਉਂਦਾ ਹੈ।
ਅਮਲੀ ਤੌਰ 'ਤੇ, ਇੰਜੀਨੀਅਰਿੰਗ-ਪਹਿਲਾ ਟੀਮਾਂ:
ਸ਼ੁਰੂਆਤੀ PCs ਘੱਟ ਸਰੋਤਾਂ 'ਤੇ ਬਣੇ ਸਨ: ਮਹਿੰਗੇ ਚਿੱਪ, ਘੱਟ RAM, ਹੌਲੀ ਸਟੋਰੇਜ, ਸੀਮਿਤ ਬੋਰਡ ਜਗ੍ਹਾ ਅਤੇ ਉਪਭੋਗੀ ਜੋ ਘਣੀ ਅਪਗਰੇਡ ਨਹੀਂ ਕਰ ਸਕਦੇ ਸਨ। ਜੇ ਹਾਰਡਵੇਅਰ ਅਤੇ ਸਾਫਟਵੇਅਰ ਅਲੱਗ-ਅਲੱਗ ਬਣਾਏ ਜਾਂਦੇ, ਤਾਂ ਮਿਲਾਪ-ਗਲਤੀਆਂ (ਟਾਈਮਿੰਗ, ਮੈਮੋਰੀ-ਮੈਪ, ਅਜਿਹਾ I/O) ਹੋ ਸਕਦੀਆਂ ਸਨ।
ਇਕਤ੍ਰਿਤਤਾ ਟੀਮਾਂ ਨੂੰ ਯੋਗ ਬਣਾਉਂਦੀ सी:
ਉਪਭੋਗੀ ਅਕਸਰ ਇਕਤ੍ਰਿਤਤਾ ਨੂੰ ਘੱਟ “ਇਹ ਨਿਰਭਰ ਕਰਦਾ ਹੈ” ਪਲਾਂ ਵਜੋਂ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ:
ਭਾਵੇਂ ਕਿ ਸਪੈਕਸ ਹਮੇਸ਼ਾ ਬਹੁਤ ਵਧੀਆ ਨਾ ਹੋਣ, ਇਕਤ੍ਰਿਤ ਸਿਸਟਮ ਤੇਜ਼ ਲੱਗ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਉਹ ਵਾਧੂ ਪਰਤਾਂ, ਤਜਵੀਜ਼ਾਂ ਅਤੇ ਸੰਰਚਨਾ-ਛੇੜਛਾੜ ਤੋਂ ਬਚਦਾ ਹੈ।
ਮੁੱਖ ਖਤਰੇ ਘੱਟ ਲਚਕੀਲਾਪਣ ਅਤੇ ਛੁਪੀ ਹੋਈ ਜੋੜੀ ਹਨ:
ਇਕਤ੍ਰਿਤਤਾ तਬ ਹੀ ਲਾਭਕਾਰੀ ਹੈ ਜਦੋਂ ਉਪਭੋਗੀ-ਦਿੱਖ ਵਾਲਾ ਫਾਇਦਾ ਸਪਸ਼ਟ ਹੋਵੇ ਅਤੇ ਤੁਸੀਂ ਅੱਪਡੇਟਾਂ ਨੂੰ ਜਾਰੀ ਰੱਖ ਸਕੋ।
ਮੋਡਿਊਲਰਟੀ ਅਕਸਰ ਜਿੱਤਦੀ ਹੈ ਜਦੋਂ ਵਿਭਿੰਨਤਾ, ਅਪਗ੍ਰੇਡ ਅਤੇ ਤੀਜੀਆਂ-ਪਾਰਟੀ ਨਵੀਨਤਾ ਮੂਲ ਬਿੰਦੂ ਹੋਣ:
ਜੇ ਤੁਸੀਂ ਨਾਂ ਹੀ ਦੱਸ ਸਕਦੇ ਕਿ ਇਕਤ੍ਰਿਤਤਾ ਕਿਸ ਉਪਭੋਗੀ ਦਰਦ ਨੂੰ ਦੂਰ ਕਰੇਗੀ, ਤਾਂ ਅਕਸਰ ਮੋਡਿਊਲਰ ਰਹਿਣਾ ਸੁਰੱਖਿਅਤ ਚੋਣ ਹੈ।
ਟਰੇਡ-ਆਫ਼ ਉਹ ਚੋਣਾਂ ਹਨ ਜਿੱਥੇ ਇੱਕ ਚੀਜ਼ ਵਧਾਉਣ ਦਾ ਖ਼ਰਚ ਕਿਸੇ ਹੋਰ ਚੀਜ਼ 'ਤੇ ਪੈਂਦਾ ਹੈ (ਗਤੀ ਵਿਰੁੱਧ ਲਾਗਤ, ਸਾਦਗੀ ਵਿਰੁੱਧ ਖੁੱਲ੍ਹਾ ਪਨ). ਇੰਜੀਨੀਅਰਿੰਗ-ਪਹਿਲਾ ਟੀਮਾਂ ਇਹ ਟਰੇਡ-ਆਫ਼ ਸ਼ੁਰੂ ਵਿੱਚ ਸਪਸ਼ਟ ਕਰਦੀਆਂ ਹਨ ਤਾਂ ਕਿ ਉਤਪਾਦ ਬੇਕਾਰੇ ਜਟਿਲਤਾ ਵੱਲ ਨਾ ਭਟਕੇ।
ਇਕ ਪ੍ਰਯੋਗੀ ਤਰੀਕਾ: ਹਰ ਟਰੇਡ-ਆਫ਼ ਨੂੰ ਇਕ ਸੀਮਾ (ਕੀਮਤ ਸੀਲਿੰਗ, ਮੈਮੋਰੀ ਬਜਟ, ਭਰੋਸੇਯੋਗਤਾ ਹਦ) ਅਤੇ ਇਕ ਉਪਭੋਗੀ ਨਤੀਜੇ (ਪਹਿਲੀ ਸਫਲਤਾ ਤੱਕ ਸਮਾਂ, ਘੱਟ ਸੈਟਅਪ ਕਦਮ) ਨਾਲ ਜੋੜੋ।
ਇੱਕ ਹਲਕਾ-ਫੁਲਕਾ ਫੈਸਲਾ ਲੌਗ ਦੁਬਾਰਾ ਚਰਚਾ ਰੋਕਦਾ ਹੈ ਅਤੇ ਸੰਦਰਭ ਬਚਾਉਂਦਾ ਹੈ। ਹਰ ਫੈਸਲੇ ਲਈ ਇਕ ਪੰਨਾ ਰੱਖੋ ਜਿਸ ਵਿੱਚ:
ਇਕਤ੍ਰਿਤ ਸਿਸਟਮਾਂ ਵਿੱਚ ਇਹ ਖਾਸ ਕਰਕੇ ਜ਼ਰੂਰੀ ਹੈ ਕਿਉਂਕਿ ਸਾਫਟਵੇਅਰ, ਫਰਮਵੇਅਰ ਅਤੇ ਹਾਰਡਵੇਅਰ ਅਨੁਮਾਨ ਪਹਿਲੀ ਟੀਮ ਤੋਂ ਬਾਅਦ ਵੀ ਜੀਵਤ ਰਹਿ ਸਕਦੇ ਹਨ।
ਇਕਤ੍ਰਿਤ ਉਤਪਾਦ ਅਕਸਰ ਸੀਮਾਵਾਂ 'ਤੇ ਹੀ ਫੇਲ ਹੁੰਦੇ ਹਨ, ਨਾ ਕਿ ਹਿੱਸਿਆਂ 'ਤੇ। ਟੈਸਟਿੰਗ ਵਿੱਚ ਸ਼ਾਮਿਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ:
ਇੱਕ ਲਾਭਕਾਰੀ ਮਾਪਦੰਡ: ਜੇ ਉਪਭੋਗੀ ਨਿਰਦੇਸ਼ ਕੀਤੇ ਵਰਕਫਲੋ ਨੂੰ ਇੱਕ ਸਾਫ਼ ਮਾਹੌਲ ਵਿੱਚ ਅਨੁਸਰਦਾ ਹੈ, ਕੀ ਉਹ ਭਰੋਸੇਯੋਗ ਨਤੀਜਾ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ?
ਲਿਖੋ ਇਕ ਇੱਕ-ਪੰਨੀ "ਸਿਸਟਮ ਵਾਅਦਾ": ਉਹ ਕੀ ਹੈ ਜੋ ਉਪਭੋਗੀ ਲਈ ਹਮੇਸ਼ਾਂ ਸਚ ਹੋਣਾ ਚਾਹੀਦਾ (ਗਤੀ, ਬੈਟਰੀ, ਬੂਟ ਸਮਾਂ, ਰਿਕਵਰੀ, ਅਨੁਕੂਲਤਾ).