Günlük işinizde “doğru yapın” ve “en kısa sürede yapın” arasında nasıl bir denge kurarsınız? [kapalı]

Kendimi zaman zaman tekrar tekrar bu sorunun üzerinde durmakta buluyorum. İşleri doğru şekilde yapmak istiyorum: bakımı kolay, temiz, anlaşılır ve doğru kodlar yazmak. Ancak, sonunda yaptığım şey bir yamanın üzerine yama yazmak; sadece zaman olmadığı için, müşteriler bekliyor, bir gecede bir hata düzeltilmeli, şirket bu konuda para kaybediyor, bir yönetici zorluyor vb.

Uzun zamandır bu yamalara daha fazla zaman harcayacağımı çok iyi biliyorum, ancak bu aylar süren çalışmalara rağmen, kimse umursamıyor. Ayrıca, yöneticilerimden birinin söylediği gibi: "Şimdi düzeltmezsek uzun vadenin olup olmayacağını bilemeyiz."

Bu sonsuz gerçek / ideal seçim döngüsüne giren tek kişi ben olmadığımdan eminim. Peki, siz benim program arkadaşlarım, bununla nasıl başa çıkıyorsunuz?

GÜNCELLEME: Bu ilginç tartışma için hepinize teşekkür ederim. Bu kadar çok insanın günlük olarak bir miktar ile kodlarının kalitesi arasında seçim yapması üzücü. Yine de, şaşırtıcı bir şekilde, insanlar bu savaşı kazanmanın mümkün olduğunu düşünüyor, bu yüzden bu teşvik için hepinize teşekkür ederim.

Aslında bu çok zor bir soru çünkü kesinlikle doğru bir cevap yok. Organizasyonumuzda daha iyi kod üretmek için daha iyi süreçler uyguluyoruz. Kodlama standartlarımızı, bir grup olarak kod yazmamızı yansıtacak şekilde güncelledik ve çok güçlü bir test / refactor / tasarım / kod döngüsü oluşturduk. Sürekli teslim ediyoruz ya da en azından deniyoruz. En azından, iki haftada bir paydaşlarımıza gösterecek bir şeylerimiz var. Yazılım ustaları olduğumuzu ve moralin yüksek olduğunu düşünüyoruz. Ancak, tüm bu kontrollere ve dengelere rağmen, yaptığınız aynı sorundan muzdaripiz.

Günün sonunda, ödeme yapan müşteriye bir ürün teslim ediyoruz. Bu müşterinin gerçekçi ya da gerçekçi olmayan ihtiyaçları ve beklentileri var. Genellikle satış ekibi sadece komisyon almak için başımızı belaya sokar. Bazen müşteri gerçek dışı bir beklenti ya da bir sözleşmemiz olmasına rağmen talepte bulunma beklentilerine sahiptir. Zaman çizelgeleri oluyor. PTO ve bir sprint sırasında kaybolan günler olabilir. “Doğru yapın” ya da “en kısa sürede yapın” bilmecesine zorladığımız bir durumda her tür küçük şey sonuçlanabilir. Neredeyse her zaman "en kısa sürede yapmak" zorundayız.

Yazılım ustaları, geliştiriciler, programcılar, bir işi kodlayan insanlar olarak - "doğru yapmak" bizim doğal eğilimimizdir. "En kısa zamanda yap", hayatta kalmaya çalışırken çoğumuzun yaptığı gibi olur. Denge zor.

Program, ekip ve yapılan çalışmaları savunmak için her zaman üst yönetime (Yazılım Geliştirme Direktörüyüm ve o gruptaki aktif bir geliştirici) yaklaşarak başlıyorum. Genellikle bu noktada müşteriye şimdi sahip olması ve çalışması gerektiği söylenir. Müzakere veya verme için yer olmadığını bildiğimde, hangi köşelerin kesilebileceğini görmek için ekiple birlikte çalışırım. Müşterinin en kısa sürede alma ihtiyacını iten özellikte kaliteden ödün vermeyeceğim, ancak bir şeyler olacak ve başka bir sprint içine itilecek. Bu neredeyse her zaman tamam.

Teslim edemediğiniz zaman, çok fazla hata var, kod kalitesi kötüleşiyor ve daha da kötüye gidiyor ve zaman çizelgeleri kısalıyor, o zaman tarif ettiğimden farklı bir durumdasınız. Bu durumda, mevcut veya geçmiş yanlış yönetim, düşük kod kalitesine neden olan kötü geliştirme uygulamaları veya diğer faktörler sizi ölüm yürüyüşüne götürebilir.

Buradaki fikrim, şirketinizi siperlerinizden çekmeye başlamak için iyi kodu ve en iyi uygulamaları savunmak için elinizden gelenin en iyisini yapmaktır. Grubu yönetime karşı dinlemeye ya da yarasa etmeye istekli bir meslektaş yoksa, yeni bir iş aramaya başlamanın zamanı gelebilir.

Sonunda, gerçek hayat her şeyi yutuyor. Eğer geliştirdiğiniz şeyi satmak isteyen bir şirket için çalışıyorsanız, günlük olarak bu takasla karşılaşacaksınız. Sadece iyi gelişim ilkelerine erken ulaşmak için çaba harcayarak kod kalitesi eğrisinin önünde kalmayı başardım.

Geliştiriciler ve satıcılar arasındaki itme ve çekme, bana bir şakayı hatırlatıyor. "Kullanılmış araba satıcısıyla yazılım satıcısı arasındaki fark nedir? En azından kullanılmış araba satıcısı yalan söylediğini bilir." Çenenizi yukarı kaldırın ve ilerledikçe "doğru olanı yapmaya" çalışın.

Kariyerimde farkettim bir şey, her zaman doğru yapmak için zaman olmasıdır. Evet, menajerin zorluyor olabilir. Müşteri sinirlenmiş olabilir. Fakat işlerin ne kadar süreceğini bilmiyorlar. Siz (dev ekibiniz) yapmazsanız, bu yapılmaz; tüm kaldıraç sende kalsın.

Eğer olacağını bilmek Çünkü gerçekten neden senin yöneticisi veya müşteriniz sinirli olmak itmek? Kötü kalite .

Bu, "Sonsuz Çatışma" olarak düşünmeye başladığım şeye (iş ve mühendislik arasında) kayıyor. Hiçbir zaman bitmeyen bir sorun olduğu için çözüme sahip değilim, ancak azaltmaya yardımcı olacak şeyler yapabilirsiniz.

• Değer iletişim

İnsanların çoğu zaman farketmedikleri şey, mühendisler olarak sadece "başarılı iş" sorununu her zaman verdiğimizin varsayılmasıdır. Kodumuzun iyi ve düzenli olmasını ve bakımını iyi yapmasını istiyoruz, böylece yeni özellikler ekleyebilir ve mevcut olanları hızlı bir şekilde ayarlayabiliriz ve daha iyi kodla engellenecek tuhaf saçak kılıfları keşfederek bizim için minimum kalite güvencesi sağlayan minimum müşterilerle. Müşterileri korumak ve özellikleri ve ustalığı ile rekabet üstünlüğünü korumak, hiç kimsenin yeterince hızlı üretemeyeceği, hem kazanç hem de iyi kodun doğrudan katkıda bulunduğu ve daha iyi kod istediklerimizin nedenini daha iyi kodlamak istediğimizden haberdar eden iş kazançlarıdır.

Yani heceleyerek. “Kod tabanımızda X yapmak istiyoruz çünkü Y nedeniyle işimizi olumsuz yönde etkilemezsek" veya "... çünkü yeni iyileştirmeler ve özellikleri daha hızlı döndürme yeteneğimizi geliştirerek rekabet gücünü artırabilir. ."

Ve iyileştirmelerin işe yaradığına dair somut kanıtlar almaya çalışın. Bir uygulamanın bazı alt kümelerini iyileştirmek daha hızlı özellik / iyileştirme ile sonuçlandıysa, kanıtı için kullandığınız herhangi bir biriktirme aracını kontrol edin ve uygun toplantılarda işaretleyin.

• Takımı Aynı Lanet Sayfada Bulun

Egos genellikle bir problemdir. Mühendislik ekiplerinin çok fazla ihtiyaç duyduğu bir şey, kendileri için daha iyi bildikleri için kendi fincanları olan Kool Aid d'jour'unu yapan herkes üzerinde belirli türdeki problemleri çözmek için tutarlı bir yaklaşım üzerinde anlaşmaya varılmış olma değerinin belirlenmesidir. Diğer adamın tercihinin seninkinden daha kötü olduğuna inanmak sorun değil, eğer yaklaşımı işe yararsa ve kazanamayacağın bir argümansa, daha doğru olma konusunda değer tutarlılığı. Tutarlılık uğruna uzlaşma anahtarıdır. İşler tutarlı olduğunda, bunları yanlış yapmak daha zordur, çünkü tutarlı yol, genellikle aynı zamanda en hızlı yol olacaktır.

• Doğru Araçları Seçin

İki çerçeve / araç seti / kütüphane / her neyse vardır. "Bunun% 99'unu benim için ayarla, bu yüzden seni istemiyorum, yolumdan uzak dur, bilmiyorum / çok az şey yapmalıyım", ama gerçekte istediğim şeylerle çok hızlı ve tutarlı bir şekilde DIY yapmama yardım et "Çubuk prensibi yerine havuçta kullanmak." İkincisini tercih et. Esneklik ve granüler kontrol, hızlı geri dönüşün sunağında asla feda edilmemelidir, çünkü biz, “bunu yapamayız çünkü kendi araçlarımız bize izin vermez” asla kabul edilemez bir cevaptır ve soru her zaman önemsiz / tek kullanımlık ürün mühendisliği. Tecrübelerime göre, esnek olmayan araçlar neredeyse her zaman geniş bir şekilde açık tutulur ya da kararsız bir şekilde çalışır ve devasa ve sürdürülemez bir karışıklık yaratır. Olmamasından daha sık, Esnek / kolay değiştirilebilen çözümler, kısa vadede, ne kadar olursa olsun, hemen hemen aynıdır. Doğru aletlerle hızlı, esnek ve bakım yapılabilir.

• FFS, Mühendisler Karar Vermezlerse, Araçları Seçim Konusunda En Az Mühendisi Alın

Bunun geliştirici perspektifli bir soru olduğu fikrine kapılıyorum, ancak teknoloji kararlarının sıfır mühendis girdisi ile alındığı çok fazla durumdayım. Bu ne lan? Evet, birileri sonuçta son çağrıyı yapmak zorundadır, ancak teknik olmayan bir yönetici iseniz, bazı satış görevlilerinin veya demo sitelerinin kendi ürünleri hakkında söylediklerini değil, nitelikli görüşler almaları gerekir. Para biriktirmek için gelecek vaat eden herhangi bir şey, çünkü insanların zeki olmaları gerekmez veya geliştiricileri kendisinden korudukları için pis, kirli bir yalandır. Güvenebileceğiniz bir yetenek edinin. Hangi teknoloji grubuna atlayacağınıza karar vermeden önce bir yığın veya başka bir teknoloji çözümünden ne istediğinizi heceleyin ve girdilerini ciddiye alın.

• Tasarımın Uygulamaya Odaklanması

Araçlar uygulama içindir ve size yardımcı olabilirler, ancak öncelikli olarak o mimariyi inşa etmek için sahip olduğunuz oyuncak setinden bağımsız olarak mimarlık olmalıdır. Günün sonunda, KISS ve DRY ve bu konuda .NET, Java ya da belki bedava olan ya da emilmeyen bir şeyden daha çok şey yapan tüm mükemmel felsefeler.

• Endişelerinizi Kaydedin

Tarafınız sizi kötü bir şekilde yapmanıza ısrar ettiğinde, bu e-postayı, özellikle de size neden pahalıya mal olacağını söylediğiniz kısmı kaydedin. Tüm öngörüleriniz gerçek olduğunda ve ciddi iş zararlarına neden olan sorunlar ortaya çıktığında, o zaman mühendis endişelerini daha ciddiye almak için büyük bir tartışma dizisine sahipsiniz. Ama zaman işleri dikkatlice. Yanan cehennemin ortasında yangın kodunu takip eden "sana söylemiştim" için kötü bir zaman. Yangını söndürün ve önceden göz ardı edilen kaygılarınızı geçmişe dönük bir toplantıya / konuşmaya ekleyin ve açıklanamayan ve göz ardı edilen mühendislik kaygılarını ve neden gerçek sayıldığını, neden gerçek sayıldığını anlamaya çalışın. görmezden gelmeye karar verme. Sen bir mühendissin. Sorunlara devam edin, insanlara değil. " X ile ilgili endişelerini dile getirdik, çünkü Y sorunlarına yol açmasından korkuyorduk. Z'ye ve bununla başa çıkmak için bize söylendi. "

Sadece bir çözüm var. Yeniden projelendirme için proje / çalışma süresinin yaklaşık% 10-20'sini ayırın. Yönetimi haklı bir görev olduğuna ikna etmek zorsa, onlara tek gerçek argümanı verin: kod bakım maliyetini geri çevirmeden zamanla katlanarak artacaktır. Yönetici ile toplantı sırasında bu tezi yedeklemek için birkaç ölçüm / makale / araştırma sonucuna sahip olmak iyidir :)

Düzenleme: Bu teknik broşürde belirtilen "bakım onarımı vs artan bakım maliyetleri" konusunda birkaç iyi kaynak var: http://www.omnext.net/downloads/Whitepaper_Omnext.pdf

Ne zaman bir şeyi doğru yapmak için vaktiniz varsa kullanın - kullanabileceğiniz en iyi kodu yazın ve sürekli olarak iyileştirin. İhtiyacınız olmadığında işinizi özümseyerek ve teknik borç vererek zorlaştırmayın.

Ciddi bir hatayı düzeltmek için yapılan acil durum çağrıları, kendi başınıza kontrol edebileceğiniz hiçbir şey değildir, ortaya çıktığında ASAP'a tepki vermek zorundasınızdır, işte bu hayat. Elbette, tüm işinizin acil aramalardan oluştuğu izlenimindeyseniz ve işleri doğru yapmak için hiçbir zaman yeterli zamanınız yoksa, o zaman yanmak için bir yoldasın ve patronunuzla konuşmalısınız.

Bu işe yaramazsa, işleri doğru yapmak için yeterli zamanı elde etmek için hala "Scotty'nin stratejisi" vardır: tüm tahminlerinizi 4 katıyla çarpın:

http://blogs.popart.com/2007/07/what-scotty-from-star-trek-can-teach-us-about-managing-expectations/

İşimi, proje için izin verilen zaman kısıtlamaları dahilinde mümkün olan en kaliteli yazılımı sağlamak olarak görüyorum. Kalite seviyesinin düşük olacağından endişeleniyorsam, proje sahibini meşgul edeceğim. Endişelerimi açıklarım ve bu durumda yazılımı dağıtmanın olası risklerini tartışırım. Bu noktada 3 şeyden biri olacak:

1. Proje sahibi riskleri kabul etmek istemeyecek ve yazılım kalitesi üzerinde daha fazla zaman geçirmemize izin vermek için programı geri taşıyacaktır.

2. Proje sahibi riskleri kabul etmek istemeyecek ancak takvimi geri alamaz. Bu durumda, uygulamanın ana bölümleri için yazılım kalitesinde daha fazla zaman harcamak amacıyla, proje kapsamından hangi özelliklerin / işlevlerin kaldırılacağı konusunda pazarlık yapmamız gerekir.

3. Proje sahibi riskleri kabul edecek ve düşük kaliteli yazılım programa uygun olarak çıkacaktır. Bazen hiçbir şeyi dağıtmama (veya geç dağıtma) riski, düşük kaliteli yazılımı dağıtma riskinden çok daha fazladır ve yalnızca proje sahibi bu kararı verebilir.

Yazılım yazmak, portre çizmeye çok benzer. Bir portrenin "doğru" veya "mükemmel" olduğunu söylemek imkansızdır. Mükemmel olanın düşmanıdır. Kelimenin tam anlamıyla 1 ayını tek bir yöntem üzerinde çalışarak geçirebilirsiniz ve yine de bazıları tarafından "mükemmel" sayılmaz. Benim işim, müşterinin mutlu olduğu bir portre çizmektir.

Bu her durumda işe yaramayacak, ancak sorun acilen düzeltilmesi gereken kırılmış bir üretim sorunuysa, bu stratejiyi kullanırken bazı şansım oldu. Üretimin çalışmasını sağlamak için hızlı bir düzeltme yapmanın ve gelecek için kalite düzeltmelerinin yapılacağı zamanı tahmin edin. Tahminleri patronunuza / müşterinize sunun ve her ikisi için de onaylanan zamanı alın. Daha sonra, üretimin artmasını sağlamak için hızlı bir düzeltme ve acil zaman baskısı kapalı olduğunda hemen bir uzun vadeli düzeltme yapın. İşi doğru yapmak için bu zamana ihtiyacım olduğu gibi sunarsam, ancak bunu yapana kadar geçici bir düzeltme koyabilirim , müşterilerimin de bu yaklaşımı sevdiğini gördüm. Tekrar koşarken prod alır ve uzun vadede dikkat edilmesi gerekir.

En uygun denge, doğru şekilde yaparak ortadan kaldırdığınız hataları düzeltmek için harcayacağınız kadar doğru zaman harcamak olabilir. Altın çözeltisini kaplamaktan kaçının. Çoğu durumda Volkswagen çözümü doğru yapılır Cadillac çözümü kadar iyidir. Genellikle Cadillac'a ihtiyacınız olduğu kanıtlandığında daha sonra yükseltme yapabilirsiniz.

En iyi uygulamalara uymayan kodun düzeltilmesi çoğu zaman daha uzun sürer. Çağrı abcde () gibi göründüğünde boş olanın nereden geldiğini bulmaya çalışmak uzun zaman alabilir.

DRY uygulamak ve mevcut kodu tekrar kullanmak genellikle başka bir çözümü kodlamaktan ve test etmekten çok daha hızlıdır. Ayrıca, meydana geldiklerinde değişiklik yapılmasını kolaylaştırır. İki, üç veya yirmi değil, yalnızca bir kod kümesini değiştirmeniz ve test etmeniz gerekir.

Katı temel kodu hedefleyin. Mükemmel hale getirmeye çalışırken çok fazla zaman harcanabiliyor. Hızlı olan, ancak en hızlı şekilde olması gereken kodlara yol açan en iyi uygulamalar vardır. Bunun ötesinde, darboğazları tahmin etmeye ve kodu oluştururken optimize etmeye çalışmak zaman kaybettirilebilir. Daha da kötüsü, optimizasyon kodu yavaşlatabilir.

Mümkün olduğunda, asgari çalışma çözümü sağlayın. Altın kaplama çözümlerini boşa harcayan haftalar gördüm. Kapsam konusunda son derece dikkatli olun.

Altı ay sürmesi gereken proje üzerinde biraz zaman geçirdim. Katıldığımda bir buçuk senedir devam ediyordu. Proje lideri, proje yöneticisine başlangıçta bir soru sormuştu: "Doğru yapmamı mı yoksa yanıt vermemi mi istiyorsun?" Bir haftada, bir özellik pazartesi, çarşamba ve cuma; Salı ve Perşembe özelliği kaldırıldı.

EDIT: Kod tatmin edici bir seviyeye geldiğinde, bırakın. Bunu yapmak için daha iyi bir yol bulursanız, düzeltmek için geri dönmeyin. Kendine not almalısın. Değişiklik gerekirse, fikrinizi gözden geçirin ve hala mantıklıysa, uygulayın.

Gelecekteki özellikler için uzantıları uygulayabileceğiniz yerler varsa, uzantıları uygulamayın. Size değişiklikleri nerede yapabileceğinizi hatırlatmak için bir işaretleyici yorumu bırakabilirsiniz.

Çalışmasını sağlayın sonra mükemmel yapın

Bunun için biraz gevşeyebilirim - ama eğer zamanın özü varsa, asıl önceliğiniz bu şekilde işe yarayacak olmalıdır. Kodunuzdaki eksiklikler hakkında kapsamlı yorum yapın ve kullandığınız herhangi bir proje / zaman yönetimi yazılımında neler yaptığınızı not edin.

Umarım bu size bu sorunlara geri dönmeniz ve onları mükemmel hale getirmeniz için daha fazla zaman verecektir.

Açıkçası buna kesin ve doğru bir cevap yok, ama bu benim denediğim ve buna bağlı kaldığım bir cevap. Ancak mevcut çalışma tarzınıza uygun bulmayabilirsiniz. Beni alternatife götüren ...

Sadece sizin için işe yarayan bir yöntem bulun ; ve sonra buna yapış. Herkesin projelerle ilgilenme yolu vardır ve “herkese uyan tek bir boyut” yaklaşımı yoktur. Bir yaklaşım bul ve kendin yap.

“Doğru yapmak”, belirli bir durum için doğru travmaları yapmak anlamına gelir. Onlardan bazıları:

1. Geliştirme zamanı ve maliyeti
2. Kodu daha sonra okuma, hata ayıklama ve güncelleme kolaylığı (değişken adlarından mimariye kadar her şey)
3. Çözümün eksiksizliği (kenar davaları)
4. Yürütme hızı

Açıkçası, bir kod parçası bir kez kullanılacak ve atılacaksa, diğerlerinden herhangi biri için # 2 feda edilebilir. (Ancak dikkatli olun: onu atacağınızı düşünebilirsiniz , sonra kullanmaya ve bakım yapmaya devam etmeniz gerektiğini, bu noktada insanları “işe yarayan” bir şeyi geliştirmek için zaman vermeye ikna etmenin daha zor olacağını düşünebilirsiniz .)

Siz ve / veya ekibiniz bazı kodları kullanmaya ve güncellemeye devam edecekseniz, şimdi kısayollar almak, daha sonra kendinizi yavaşlatmanız anlamına gelir.

Şu anda buggy kodunu veriyorsanız (# 4’te zayıf) ve bunu yapmak için uzun zaman alıyorsa (# 1’de zayıf) ve bunun nedeni # 2’de zayıf olan kodu güncellemeye çalışıyor olmanız. uygulamalarınızı değiştirmek için sağlam, pragmatik bir tartışma var.

Eğer bir hata varsa, en kısa zamanda yapın, eğer yeni bir özellikse, zaman ayırın.

Ve geliştirici işine saygı göstermeyen bir şirket için çalışıyorsanız, hızlı bir şekilde yapmaktan ve kaliteden ödün vermekten başka seçeneğiniz olmayabilir.

Projeden projeye geçen ve her şeyi hızlı bir şekilde yapabilen birkaç şirket için çalıştım. Sonuçta, her projede çok az başarı elde ettiler, çünkü uygulama (sadece programlama değil) ilerledi.

Oradaki en iyi şirketler iyi yazılımın zaman ve işçilik gerektirdiğini anlıyor.

Acil durumlarda yama çözümü oluşturun. Bunu izleyerek hata izlemede yeni bir hata oluşturun. Uygun zamanınız olduğunda doğru yapın.

Sanırım bu sektörde çalışıp sıkışmış herkesin yaptığını yapıyorum. Yapabildiğim kadar hızlı yapıyorum ve gelecekteki sorunları önlemeye ya da gelecekte sorun çözmeyi kolaylaştıracak bazı güzel şeyleri dışarıda bırakmak zorunda kalırsam, yaparım. Bu uygun bir durum değildir, ancak tahminlere dayanan tahminlere dayanan, son zamanlardaki bilinmeyen değişkenlere dayanan son tarihler ile sıkışıp kaldığınızda, yapabileceğiniz en iyi şey budur.

İşte iyi bir plan:

1. Doğru yaptığınız planı, en kısa zamanda yaptığınız zamana eşit miktarda uygulayın.
2. Ortamınız mutlu olana kadar yapmak için zamanınızı optimize edin; kaliteyi koru
3. ???
4. başarı

Çoğu şeyi rutin yoldan, akla gelen ilk yoldan yapıyorum. Bu hızlı ve iyi bir programcı olduğumu düşünmeyi seviyorum ve ilk denemede çoğu şeyi makul derecede iyi yapıyorum.

Her zaman ve sonra (Günde iki kez, ancak haftada iki kez daha fazla şey söylemek istiyorum), özellikle rutin şekilde yapmak için son derece sıkıcı bir şey bulduğumda, "Bunu yapmanın harika bir yol olacağını düşünüyorum. " ?" ve bunu yapmak için daha iyi bir yol bulmak veya icat etmek için fazladan zaman harcıyorum.

Bunu sık sık yapmaya devam edersem rutin kodlamam gelişmeye devam edecek, sanırım.

Yazılım garip şeyler ve yazılım geliştirme süreci garip.

Gerçek hayattaki çoğu şeyin aksine, ama bilgisayarlarla yapılacak çoğu şey gibi

Daha hızlı daha güvenilir

Bu, şu ana kadar size öğrettiğiniz her sezgiye aykırıdır, size çok iyi ayarlanmış arabalar standart olanlardan daha sık bozulur, hızlı bir şekilde inşa edilen evler daha çabuk dağılır, okul otobüsünün arkasına yapılan ev ödevleri yüksek not almaz.

Ancak yavaş metodik prosedürler daha iyi yazılım üretmez. İhtiyaç belgelerini harmanlayarak haftalarını harcayan çocuklar ve kod yazmadan önce sınıf diyagramlarındaki günleri daha iyi bir yazılım üretmezler. Temel gereksinimi alan, birkaç sorunu açıklayan, beyaz tahtada bir sınıf diyagramı çizen ve takım kodlamasını neredeyse her zaman daha güvenilir ve daha iyi bir yazılım üretecek ve aylar yerine birkaç gün içinde yapacak olan adam.

İş senin için uygun değil.

Düşük kaliteli kod yazılan "çünkü zaman yok, müşteriler bekliyor, bir gecede bir hata düzeltilmeli, şirket bu konuda para kaybediyor, bir yönetici zorluyor" kötü yönetilen bir şirketin belirtisidir.

Çalışmanızla gurur duymak ve yüksek kalitede kod yazmak istiyorsanız, yapılacak en iyi şey, bunu anlayan ve size ödeyecek olan bir işveren bulmaktır.