Yazılım mühendisliği ekiplerinde basitliğin genellikle göz ardı edildiği ve ödüllendirilmediği, aksine karmaşıklığın övüldüğü ve terfilere yol açtığı yaygın bir soruna dikkat çekiliyor. Edsger Dijkstra'nın "Basitlik büyük bir erdemdir, ancak elde etmek için çok çalışmayı ve takdir etmek için eğitimi gerektirir. Daha da kötüsü, karmaşıklık daha iyi satar" sözü, bu durumun temelini oluşturuyor. Bu kasıtlı bir durum olmasa da, şirketlerin işleri yanlış değerlendirmesi sonucunda ortaya çıkan bir sistem hatası olarak karşımıza çıkıyor.
Makale, bu durumu iki mühendis örneğiyle açıklıyor: Mühendis A, bir özelliği birkaç gün içinde basit ve bakımı kolay bir şekilde hayata geçirirken, Mühendis B benzer bir özellik için haftalar harcayarak yeni soyutlama katmanları, pub/sub sistemleri ve yapılandırma framework'leri ekleyerek daha "sağlam" bir yapı oluşturuyor. Terfi zamanı geldiğinde, Mühendis B'nin çalışması "ölçeklenebilir olay tabanlı mimari tasarladı ve uyguladı" gibi ifadelerle kolayca terfi dosyasına girerken, Mühendis A'nın daha üstün olan basit çözümü "X özelliğini uyguladı" gibi üç kelimeyle özetleniyor ve neredeyse görünmez kalıyor.
Bu teşvik sorunu sadece terfi dönemleriyle sınırlı değil, iş görüşmelerine kadar uzanıyor. Sistem tasarım mülakatlarında basit bir çözüm önerildiğinde, mülakatçılar genellikle ölçeklenebilirlik ve milyonlarca kullanıcı senaryolarını sorarak daha karmaşık çözümlere yönlendiriyor. Bu durum, mühendislerin karmaşıklığın insanları etkilediği ve ödüllendirildiği dersini almasına neden oluyor. Basit cevap yanlış olmasa da, yeterince "ilgi çekici" bulunmuyor ve bu ders kariyer boyunca taşınıyor, basitlikten ziyade karmaşık çözümler üretme eğilimini pekiştiriyor.
Mühendislik kültüründe basitliğin değeri yeterince anlaşılmadığı ve ödüllendirilmediği için, karmaşık çözümlerin tercih edilmesine yol açan sistemik bir sorun bulunmaktadır.