“ ตราบเท่าที่มันใช้งานได้” เป็นบรรทัดฐานหรือไม่? [ปิด]

ดูคำถามล่าสุดของฉัน: การเขียนโปรแกรมเป็นอาชีพในด้านล่างหรือไม่?

ร้านค้าสุดท้ายของฉันไม่มีกระบวนการ Agile เป็นหลักหมายความว่าพวกเขาไม่มีแผนเลยเกี่ยวกับวิธีการพัฒนาหรือจัดการโครงการของพวกเขา มันหมายความว่า "เฮ้นี่เป็นงานตันไปทำในสองสัปดาห์เราเร็วและว่องไว"

พวกเขาปล่อยสิ่งที่พวกเขารู้ว่ามีปัญหา พวกเขาไม่สนใจว่าจะเขียนสิ่งต่าง ๆ อย่างไร ไม่มีบทวิจารณ์โค้ด - แม้ว่าจะมีนักพัฒนาหลายคนก็ตาม พวกเขาเปิดตัวซอฟต์แวร์ที่พวกเขารู้ว่าเป็นรถม้าชนิดเล็ก

ที่งานก่อนหน้าของฉันผู้คนมีทัศนคติตราบเท่าที่ทำงานได้ดี เมื่อฉันขอให้เขียนรหัสที่ฉันเขียนใหม่ในขณะที่เราสำรวจสเป็คพวกเขาก็ปฏิเสธมัน ฉันต้องการเขียนรหัสใหม่เพราะมีการทำซ้ำรหัสในหลาย ๆ ที่ไม่มีการห่อหุ้มและใช้เวลานานในการเปลี่ยนแปลง

โดยพื้นฐานแล้วความประทับใจของฉันคือ: การเขียนโปรแกรมลดหลั่นลงไปที่:

1. อ่านหนังสือเกี่ยวกับเครื่องมือ / เทคโนโลยีล่าสุด
2. การขว้างรหัสเข้าด้วยกันโดยหลีกเลี่ยงการเขียนรหัสใด ๆ เพราะ บริษัท ไม่ต้องการที่จะ "คงรหัสไว้"
3. แสดงและย้ายไปยังสิ่งต่อไป "ตราบใดที่มันยังทำงานอยู่"

ฉันมักจะบอกตัวเองเสมอว่างานต่อไปฉันจะได้ร้านค้าที่ดีขึ้น มันไม่เคยเกิดขึ้น ถ้าเป็นแบบนี้ฉันจะรู้สึกติดขัด เทคโนโลยีเปลี่ยนแปลงอยู่เสมอ หากการพัฒนาทางด้านอาชีพเพียงอย่างเดียวที่นี่คือการอ่านหนังสือเทคโนโลยี MS Press ล่าสุดคุณมีสิ่งใดบ้างที่สร้างขึ้นใน 10 ปี แต่เป็นความรู้ชั้นเลิศเกี่ยวกับเทคโนโลยีต่างๆ ฉันกังวลเกี่ยวกับ:

1. วิธีที่ดีที่สุดในการมีมาตรฐานวิชาชีพ
2. วิธีการพัฒนาความรู้และประสบการณ์ที่มีความหมายในสถานการณ์นี้

คุณได้พบกับสิ่งที่ฉันคิดว่าเป็นกุญแจสำคัญในการเป็นนักพัฒนาที่ดี : โดยเฉพาะความสมดุลระหว่าง " ตราบเท่าที่มันใช้งานได้ " และโค้ดที่สง่างาม

เช่นเดียวกับในการเมืองมันง่ายกว่ามากในการวางตำแหน่งของคุณไว้ที่ปลายด้านหนึ่งของสเปกตรัมเมื่อเทียบกับตำแหน่งที่อยู่ในระดับกลาง นักพัฒนาส่วนใหญ่ที่ฉันพบเจอนั้นเป็นหนึ่งในสองประเภท: การเขียนรหัสคาวบอยแฮ็กและนักบินอวกาศด้านสถาปัตยกรรม ฉันพยายามที่จะสมดุลระหว่างทั้งสอง มันไม่ง่ายอย่างที่คิด

หากต้องการตอบคำถามของคุณโดยตรงฉันคิดว่า "ตราบใดที่ทำงาน" มักเป็นบรรทัดฐาน แต่ลองดูอีกวิธีหนึ่ง: คุณอยู่ในตำแหน่งที่ยอดเยี่ยมในการให้ความรู้แก่เพื่อนร่วมงานของคุณและพยายามแนะนำวิธีปฏิบัติที่ดีกว่า แต่อย่าไปมากและจำไว้ว่าทำไมเราถึงทำเช่นนี้เพื่อแก้ปัญหาของลูกค้า

>> ที่งานก่อนหน้าของฉันผู้คนมีทัศนคติที่ดีตราบใดที่มันใช้ได้

อาจเป็นฉันเป็นชนกลุ่มน้อยที่นี่ แต่ฉันมีทัศนคติเดียวกันและฉันเชื่ออย่างยิ่งว่าการเขียนบางสิ่งบางอย่างควรมีหลักฐานชัดเจนว่าทำไมเราถึงต้องการสิ่งนี้ และฉันไม่ได้หมายถึงบางสิ่งบางอย่างเช่น "uf ฉันไม่ชอบวิธีการเข้ารหัส" - นักพัฒนาทุกคนมีการตั้งค่าเกี่ยวกับรหัส ควรมีปัญหากับส่วนที่เราต้องการเขียนใหม่:

• ปัญหาประสิทธิภาพการทำงาน
• พบข้อบกพร่องมากกว่าในส่วนอื่น ๆ ของระบบ
• นักพัฒนาใช้เวลามากขึ้นเมื่อพวกเขาทำงานในส่วนนี้
• เป็นต้น

Agile จะไม่รับผิดชอบต่อการตัดสินใจของมนุษย์ที่จะปล่อยซอฟต์แวร์บั๊กกี้ มนุษย์นั้น

ที่กล่าวว่าคุณให้ความสำคัญกับคุณภาพและเป็นเรื่องดี ฉันแน่ใจว่าคุณเป็นพวกชอบความสมบูรณ์แบบและคุณมีความกังวลเกี่ยวกับคุณค่าของคุณเองหากคุณไม่ทันกับเทคโนโลยีล่าสุด

ปัญหาคือว่าอุดมคตินำไปสู่การผัดวันประกันพรุ่งและนำไปสู่การผัดวันประกันพรุ่งธรรมดา

นั่นเป็นเหตุผลที่ธุรกิจจะให้ความสำคัญกับวัตถุดิบเช่นเวลาในการทำตลาดและใช้ความคล่องตัวเพื่อส่งมอบคุณค่าได้อย่างรวดเร็วและเป็นไปตามคาดการณ์

เนื่องจากคุณไม่ได้อธิบายกลยุทธ์ทางธุรกิจของ บริษัท ของคุณฉันคิดว่าคุณควรเริ่มต้นด้วยการถามคำถามเกี่ยวกับเรื่องนี้กับผู้จัดการของคุณ

โดยการจัดให้สอดคล้องกับวัตถุประสงค์และแผนของพวกเขา (พวกเขาจ้างคุณเพื่อช่วยให้พวกเขาบรรลุเป้าหมาย) คุณจะอยู่ในตำแหน่งที่ดีขึ้นเพื่อทำความเข้าใจว่าคุณสามารถมีส่วนร่วมกับพวกเขาได้อย่างไรแทนที่จะมุ่งเน้นที่วัตถุประสงค์ส่วนตัวและส่วนตัวของคุณ

ฉันแน่ใจว่าโดยการลองใช้understandคุณค่าของพวกเขาคุณจะสามารถแบ่งปันของคุณและนั่นจะเป็นจุดเริ่มต้นของการทำงานร่วมกันที่ประสบความสำเร็จ

และถ้าคุณพบว่าพวกเขาไม่ได้รู้ว่าสิ่งที่พวกเขากำลังทำเพียงตัวเลือกเดียวของคุณจะถูกเลิก

ทุกอย่างขึ้นอยู่กับสิ่งที่คุณกำลังสร้าง หากคุณกำลังสร้างไซต์ไมโครไซต์ที่จะออนไลน์เพียงเดือนเดียวและคุณมีเวลาเก้าวันในการสร้าง: ใช่แล้วตราบใดที่การทำงานนั้นพอเพียง

หากคุณกำลังเขียนอัลกอริธึมแบบบินต่อสายสำหรับระบบ FA-18 ล่ะก็มันจะถูกสร้างให้ดีที่สุดเท่าที่จะเป็นไปได้

ดังนั้นเป็นกรณีที่มีคำตอบเทคโนโลยีส่วนใหญ่ ... ขึ้นอยู่

มันขึ้นอยู่กับ บริษัท อย่างไรก็ตามหลาย บริษัท มีการแข่งขันที่รุนแรงและกดดันเวลา นั่นเป็นหนึ่งในเหตุผลทั่วไป อีกประการหนึ่งจะเป็นภาระงานที่มีขนาดใหญ่อาจไม่มีพนักงานเพียงพอ (มีเหตุผลที่ดีบางอย่างสำหรับการเข้าใจผิดนั่นไม่จำเป็นต้องเป็นความผิดของ บริษัท ) กล่าวว่าบางองค์กรไม่สามารถจัดการทางของพวกเขาออกจากถุงกระดาษเปียก

ฉันคิดว่าใช้กฎ 80/20 ที่นี่ โดยทั่วไปคุณต้องทนกับเส็งเคร็ง 80% และทำงานเป็น 20% อย่างไรก็ตามทราบว่าแม้พวกเขาจะต้องทำการแลกเปลี่ยน ในธุรกิจมักจะไม่สำคัญว่าคุณจะถูกต้องอย่างแน่นอน มันสำคัญที่คุณมีมันตอนนี้

หากการพัฒนาทางด้านอาชีพเพียงอย่างเดียวที่นี่คือการอ่านหนังสือเทคโนโลยี MS Press ล่าสุดคุณมีสิ่งใดบ้างที่สร้างขึ้นใน 10 ปี แต่เป็นความรู้ชั้นเลิศเกี่ยวกับเทคโนโลยีต่างๆ

นั่นอาจจะเป็นเรื่องที่ค่อนข้างง่วง แต่อาจมีความล้มเหลวที่น่าสังเกตในทศวรรษนั้น ฉันเคยเห็นหลายสถานที่ที่ฉันสามารถจำสิ่งที่ค่อนข้างเฉพาะเจาะจงที่ฉันชอบเกี่ยวกับการทำงานที่นั่นหรือไม่สนุกและดังนั้นจึงมีคำถามว่ามีอีกครั้งในที่ทำงานใหม่ของฉัน บางครั้งอาจมีวิธีปฏิบัติใหม่ที่จะลองทำหาก บริษัท พยายามที่จะใช้ Scrum หรือนำวิธีการพัฒนาที่ขับเคลื่อนด้วยการทดสอบมาใช้ซึ่งอาจเป็นโอกาส แต่ไม่จำเป็นต้องมองว่าเป็นการพัฒนาวิชาชีพเนื่องจากไม่ได้อยู่ในห้องเรียนที่เป็นทางการ

ฉันรู้ว่าสถานที่ต่าง ๆ ที่ "ตราบใดที่มันทำงาน" เป็นเรื่องธรรมดาพร้อมกับกลยุทธ์การเข้ารหัสคาวบอยต่างๆ ในการเริ่มต้นสองสามครั้งฉันเห็นความคิดแบบนี้ซึ่งอาจสมเหตุสมผลถ้า บริษัท ยังเด็กมากจนพวกเขายังคงพยายามล้างความคิดว่าพวกเขากำลังพยายามทำอะไร ที่ บริษัท อื่น ๆ ที่ฉันเคยทำงานนั้นมีกระบวนการมากขึ้นและมีวุฒิภาวะที่ค่อนข้างดี แต่ไม่จำเป็นว่าฉันจะหาง่าย บางแห่งมีกระบวนการบางอย่างที่ฉันได้เห็นและไป "ฉันชอบที่ฉันจะจำได้ว่าสำหรับสถานการณ์การทำงานในภายหลัง" และอื่น ๆ ที่ฉันจะไป "ฉันไม่ชอบมันฉันจะทราบ พยายามหลีกเลี่ยงสิ่งนั้นในอนาคต "

ฉันทำงานที่ร้านค้าแบบนี้มาพักหนึ่งแล้วก็มาถึงจุดที่พวกเขาจับได้ มีแอปพลิเคชันอายุสองหรือสามปีที่มีข้อบกพร่องที่รู้จักซึ่งแท้จริงแล้วไม่สามารถแก้ไขได้ ลองนึกถึงการวนลูปยาว 4,000 บรรทัดพร้อมการคำนวณแบบวิ่งสำหรับความกว้างและความสูงของเลย์เอาต์ การแก้ไขโค้ดเพื่อแก้ไขปัญหาในอินสแตนซ์หนึ่งจะส่งผลให้เกิดปัญหายี่สิบเรื่องที่อื่น ๆ เนื่องจากนักพัฒนาซอฟต์แวร์ก่อนหน้านี้มีปัญหาคล้ายกันที่ใช้แบนด์ช่วยด้วยการปรับผลการคำนวณโดยใช้เลขอาถรรพ์ ไม่สามารถอธิบายรหัสได้ว่าเป็นสิ่งอื่นใดนอกจากความเป็นพิษ

ในที่สุดฉันก็ถูกส่งมอบโครงการใหม่ที่เจ้านายของฉันบอกว่าฉันสามารถใช้รหัสที่มีอยู่นี้เพื่อจัดการเลย์เอาต์ ยังไงก็เถอะฉันเชื่อว่าเขาจะให้ฉัน "แก้ไข" ดังนั้นเขาจึงให้เวลาฉันเพิ่มเติม ฉันใช้เวลาแทนการเขียนไลบรารีที่ออกแบบมาอย่างดีเพื่อช่วยในการจัดวาง ข้อบกพร่องในโครงการใหม่นี้ใช้เวลา 10 วินาทีในการแก้ปัญหา ฉันสามารถระบุปัญหาก่อนที่จะดูรหัสเพื่อดูว่ามีอะไรผิดพลาด

ฉันคิดว่าสิ่งนี้จะส่งผลให้จุดเปลี่ยนสำหรับผู้จัดการของฉัน แต่สิ่งที่ฉันได้รับคือการตบหลังและเขาก็บอกฉันว่า "วิธีการทำงานของคุณฉันก็เดาเหมือนกัน"

ฉันเริ่มทำงานกับร้านอื่นมาตั้งแต่ตอนนี้และสิ่งต่าง ๆ ดีกว่าที่นี่ ประเด็นคือคุณไม่สามารถเปลี่ยนใจ เพิ่งไปทำงานที่อื่น

ฉันยังมีความหวังว่าในทางเศรษฐกิจมีกระบวนการวิวัฒนาการที่ไม่ช้าก็เร็วทำให้ บริษัท ดังกล่าวเลิกกิจการ แต่บางทีความก้าวหน้าทางเทคโนโลยีระดับสูงอาจก่อให้เกิดนิชมากเกินไปดังนั้นแม้แต่คู่แข่งที่อ่อนแอก็ยังสามารถหา "อาหาร" ได้มากพอ

หากคุณต้องการเพิ่มโอกาสในการทำงานในสถานที่ที่ดีให้มองหา บริษัท ที่มีผลิตภัณฑ์ที่ขายให้กับลูกค้าจำนวนมากแทนที่จะเขียนสิ่งใหม่ทุกสองสามสัปดาห์ ควรมีความสนใจในการมีฐานรหัสที่ดีและสามารถเพิ่มคุณสมบัติใหม่โดยไม่ทำลายโค้ดที่มีอยู่ตลอดเวลา

เตือนฉันเกี่ยวกับเพื่อนสนิทของฉันจากวิทยาลัย เขากำลังเรียนการออกแบบ VLSI และสำหรับการบ้านครั้งแรกของเขาเกิดขึ้นกับส่วนประกอบที่อยู่ในคำสั่งของไมโครมิเตอร์กว้างและยาวหนึ่งไมล์ การจำลองผ่านไปอย่างสมบูรณ์แบบ

คำตอบของเขาที่มีต่อนักวิจารณ์ของเขาคือ: "สิ่งที่ฉันรู้ก็คืออึของฉันทำงานได้"

บรรทัดฐานที่ค่อนข้างดีคือหลักการ Pareto

ฉันมีประสบการณ์จากโครงการที่มีกฎ 80-20 และทำงานได้ดีมาก ฉันคิดว่าคำตอบสำหรับคำถามนี้"คุณวาดเส้นเพื่อความสมบูรณ์แบบของคุณได้ที่ไหน"ก็มีประโยชน์เช่นกัน

คำว่า "หลักการ Pareto" ยังสามารถอ้างถึงประสิทธิภาพของ Pareto หลักการ Pareto (หรือเรียกอีกอย่างว่ากฎ 80-20 กฎของผู้มีความสำคัญน้อยและหลักการของปัจจัยกระจัดกระจาย) ระบุว่าสำหรับเหตุการณ์ต่าง ๆ ประมาณ 80% ของผลกระทบมาจากสาเหตุ 20% นักคิดการจัดการธุรกิจ Joseph M. Juran แนะนำหลักการนี้และตั้งชื่อตามนักเศรษฐศาสตร์ชาวอิตาลี Vilfredo Pareto ซึ่งสังเกตในปี 2449 ว่า 80% ของที่ดินในอิตาลีเป็นเจ้าของ 20% ของประชากร; เขาพัฒนาหลักการโดยสังเกตว่า 20% ของฝักถั่วในสวนของเขาบรรจุถั่ว 80% มันเป็นกฎง่ายๆในการทำธุรกิจ เช่น "80% ของยอดขายมาจาก 20% ของลูกค้า" ในทางคณิตศาสตร์ที่มีบางสิ่งที่ใช้ร่วมกันในกลุ่มผู้เข้าร่วมที่มีขนาดใหญ่พอสมควรจะต้องมีหมายเลข k ระหว่าง 50 และ 100 ดังนั้น "k% จะถูกใช้โดย (100 - k)% ของผู้เข้าร่วม" หมายเลข k อาจแตกต่างจาก 50 (ในกรณีที่มีการแจกแจงเท่ากันนั่นคือ 100% ของประชากรมีส่วนแบ่งเท่ากัน) จนถึงเกือบ 100 (เมื่อมีผู้เข้าร่วมจำนวนเล็กน้อยคิดเป็นทรัพยากรเกือบทั้งหมด)ไม่มีอะไรพิเศษเกี่ยวกับตัวเลขทางคณิตศาสตร์ 80% แต่ระบบที่แท้จริงหลายแห่งมี k อยู่รอบ ๆ บริเวณที่มีความไม่สมดุลระดับกลางในการกระจาย หลักการของพาเรโตนั้นมีความสัมพันธ์เชิงสัมผัสกับประสิทธิภาพของพาเรโต้เท่านั้น Pareto พัฒนาแนวคิดทั้งสองในบริบทของการกระจายรายได้และความมั่งคั่งในหมู่ประชากร

เชื่อมโยงไปยังแหล่งที่มา

เมื่อฉันขอให้เขียนรหัสที่ฉันเขียนใหม่ในขณะที่เราสำรวจสเป็คพวกเขาก็ปฏิเสธมัน ฉันต้องการเขียนรหัสใหม่เพราะมีการทำซ้ำรหัสในหลาย ๆ ที่ไม่มีการห่อหุ้มและใช้เวลานานในการเปลี่ยนแปลง

ไม่มีความผิดใด ๆ แต่ในฐานะผู้จัดการฉันอ่านคำแถลงนั้นที่ไหนสักแห่งตามแนวของ:

"เมื่อฉันถูกขอให้จ่ายเงินสองครั้งเพื่อเขียนรหัสที่ฉันได้เขียนไปแล้ว บริษัท ของฉันไม่ต้องการจ่ายเงินฉันต้องการเงินพิเศษเพื่อล้างความยุ่งเหยิงที่ฉันทำเมื่อฉันเขียนมันเป็นครั้งแรกและของฉัน เพื่อนร่วมงานโกรธฉันที่ทำให้ชีวิตของพวกเขาลำบาก "

หากเป็นรหัสของคุณคุณกำลังบ่นเกี่ยวกับ - คุณไม่ต้องยืนมากนัก

UPDATE

ฉันเข้าใจว่า POV นี้ไม่เป็นที่นิยม แต่ฉันไม่คิดว่ามันจะเข้ากันไม่ได้กับความรับผิดชอบและทัศนคติของนักพัฒนามืออาชีพ

หากคุณเขียนโค้ดที่สะอาดเพื่อเริ่มต้นด้วย (และมีเหตุผลมากมายที่ต้องทำเช่นนี้ - ไม่ว่าคุณจะคิดว่ารหัสของคุณกำลังจะเห็นการใช้งานจริงหรือไม่ก็ตาม) คุณก็จะมีปัญหานี้น้อยลงเป็นประจำ

หากคุณใส่รหัสที่สะอาดและเวลาในการเปลี่ยนโครงสร้างในการประมาณของคุณคุณจะมีกำหนดเวลาที่จะทำให้ codebase เป็นระเบียบ หากเนื่องจากความกดดันด้านตารางเวลาคุณไม่ได้รับเวลาที่ต้องการ - การประเมินในอนาคตของคุณควรเพิ่มขึ้นเนื่องจากการจัดการกับหนี้ทางเทคนิคที่เกิดขึ้น

ในบางครั้งการประมาณการในอนาคตของคุณ (หรือความไม่แน่นอนรอบการประมาณของคุณ) จะทำให้คุณสามารถโต้เถียงเพื่อเขียนใหม่ (เมื่อผู้จัดการของคุณขอร้องให้คุณทำให้กระบวนการทำงานได้เร็วขึ้น) ถ้าไม่เช่นนั้นยอมรับว่าธุรกิจได้ยอมรับการประมาณการของคุณและจะจ่ายค่าใช้จ่ายอย่างต่อเนื่องมากกว่าการทดแทน นั่นเป็นการตัดสินใจทางธุรกิจล้วนๆ - ไม่ใช่เรื่องเทคนิค

โปรดจำไว้ว่าเวลาในการเจรจากำหนดเวลาคือก่อนที่คุณจะเขียนรหัส - ไม่ใช่หลังจาก หลังจากเขียนโค้ด (และ "งาน") แล้วลูกค้าผู้จัดการและผู้บริหารไม่ต้องการเห็นการเรียกเก็บเงินอีกครั้งสำหรับ "การบำรุงรักษา" ที่เข้าใกล้หรือเกินกว่าราคาเดิม หากคุณรู้สึกอย่างจริงจังกับสิ่งที่คุณคิดว่าธุรกิจควรทำคุณสามารถเขียนมันใหม่ได้ตามเวลาของคุณนั่นคือสิ่งที่คุณต้องการให้ธุรกิจทำ

จากมุมมองของผู้จัดการของคุณให้คุณกำหนดเวลาในการเขียนทำให้ตูดของเขาอยู่ในบรรทัด เมื่อคุณล้มเหลวในการส่งมอบหรือเพิ่มผลผลิตได้มากเท่ากับที่คุณพูด - จากนั้นเขาก็เหลือกระเป๋าไว้ เปรียบเทียบกับความไม่สะดวกเล็กน้อยในการฟังที่คุณบ่นลองเดาดูว่าเขาจะชอบแบบไหน

หากเป็นงานที่คุณสามารถทำได้เพียงมุ่งเน้นการเขียนโค้ดที่ดีขึ้นในแต่ละครั้งแทนที่จะกลับไปเขียนใหม่และเขียนรหัสเก่า ยังคงมีช่วงคุณภาพที่คุณสามารถย้ายเข้าไปอยู่ในขอบเขตของการติดกาวด้วยกันกับแพ็คเกจของบุคคลที่สาม

หากคุณมีเวลาและต้องการปรับปรุงรหัสของส่วนประกอบที่มีอยู่ที่คุณบำรุงรักษาคุณไม่สามารถทำได้โดยไม่ต้องขออนุญาตตราบใดที่คุณทำงาน แยกเวลาเป็นค่าประมาณของคุณสำหรับโครงการถัดไปที่ใช้องค์ประกอบ

สำหรับการเขียนโปรแกรมระดับต่ำกว่าถ้าคุณไม่สามารถเรียนรู้ความพึงพอใจจากการทำงานของคุณได้บางทีถึงเวลาที่จะดูโปรเจคโอเพ่นซอร์ส

คำถาม 3030 ฉันพบคำถามของคุณน่าสนใจและรู้สึกว่าคุณอาจพบว่าคำถามผู้เขียนโปรแกรมมีค่าต่อการอ่านเกี่ยวกับวิธีโน้มน้าวผู้จัดการเพื่อให้นักพัฒนาจัดการเรื่องหนี้สินทางเทคนิค

ฉันคิดว่าโดยทั่วไปใช่มันเป็นบรรทัดฐาน ทำความเข้าใจว่าซอฟต์แวร์ที่ใช้งานได้ แต่น้อยกว่าที่ดีที่สุดนั้นดีกว่าซอฟต์แวร์ที่ไม่ทำงาน นอกจากนี้ยังมีข้อโต้แย้งว่าคำนิยามของ "การทำงาน" อาจแตกต่างกันไปตามการรับรู้และอคติของแต่ละคน เมื่อคุณใช้ระบบใหม่จะมีใครบางคนที่จะบอกว่าพวกเขารู้สึกว่าระบบเก่าดีกว่า และเมื่อคุณพูดคุยกับนักพัฒนาเขาหรือเธอมีแนวโน้มที่จะลังเลที่จะยอมรับว่าได้ทำงานกับซอฟต์แวร์เส็งเคร็ง