Büyük BT projeleri neden başarısız oluyor veya büyük maliyet / zaman aşımına uğraıyor? [kapalı]

Her zaman toplam veya neredeyse tamamen felaket olan büyük ölçekli dönüşüm veya entegrasyon projelerini okudum. Her ne kadar bir şekilde başarmayı başarabilseler de, patlamanın zamanlaması muazzamdır. Büyük projelerin arızalanmaya daha yatkın olmasının ardındaki asıl sebep nedir? Çevik bu tür projelerde kullanılabilir mi yoksa geleneksel yaklaşım hala en iyisidir.

Avustralya’dan bir örnek, projeyi sunmak için test başarı ölçütlerini değiştirdikleri Queensland Bordro projesidir.
Bu SO sorusunda daha fazla başarısız proje görün ( Wayback Makinesi'nde )

Paylaşacak kişisel bir tecrüben var mı?

Asıl sebep, “Pragmatik Programcı” kitabının şöyle tanımladığı kapsamdaki artış :

• özellik kabukları
• sürünen budizmcilik
• gereksinim sürünmesi

Haşlanmış kurbağa sendromunun bir yönüdür.

Çeşitli "çevik" yöntem fikri, geri bildirimi hızlandırmak ve - umarım - projenin zaman içindeki evrimini düzeltmektir.

Ancak diğer neden, yayın yönetimidir : projeyi serbest bırakmaya yönelik değilseniz (ancak kusurlu olabilir), şansınız başarısız olacaktır (çünkü çok geç serbest bırakılmış, çok fazla can sıkıcı özelliğe sahip ve düzeltmek / güncellemek zor / Yükselt).

Bu, sabit bir çıkış tarihine sahip olmanız gerektiği anlamına gelmez, ancak bu, test etmek / değerlendirmek / sınamak için her zaman programınızın çalışan bir sürümünü oluşturabilmeniz gerektiği anlamına gelir.

" Geç projeler bir kerede bir gün geç kaldı " blog yazısı daha pek çok örnek içeriyor:

Yapılması gereken 'Gerçek Olma' olayının kapsamı Flex ile başlatmak ve başlangıç ​​tarihini sabit tutmak olduğunu biliyorum, ancak zaman içinde tamamlanamayan işlevsellik konusunda karar verilirse bu işe yaramaz.

Bu yüzden özellikleri savunmuyoruz ya da “işlevsellik konusunda anlaştım” demiyoruz. Sorunun kökü bu - ilk piksel boyanmadan ya da kod satırının yazılmasından önce bile neye ihtiyacınız olduğuna ve nasıl uygulanacağına dair her şeyi bildiğinizi söyleyerek. .

Esnek bir hediye için sert bir gelecek öngördüğünde, başın derde girer. Sert gelecekler en tehlikeli şeyler arasında. Yeni kapılar açan keşif, ortaya çıkma ve hatalara yer bırakmazlar.

Genellikle karmaşıklık projenin hafife alınır .

Steve McConnell ("Code Complete" ününden) klasik hataların bir listesine sahiptir .

Bazı etkisiz gelişim uygulamaları sık sık, çoğu insan tarafından, “klasik hatalar” olarak adlandırmayı hak ettiği öngörülebilir, kötü sonuçları olan seçildi ...

Bu bölüm üç düzine klasik hatayı sıralamaktadır. Bu hataların her birini şahsen en az bir kere yaptım ve çoğunu kendim yaptım ...

Bu listedeki ortak payda, hatalardan kaçınmanız durumunda mutlaka hızlı bir gelişme elde etmeyeceğinizdir, ancak kaçınmazsanız kesinlikle yavaş bir gelişme elde edersiniz ...

Referans kolaylığı için, liste insanların, süreçlerin, ürünlerin ve teknolojinin gelişim hızı boyutlarına bölünmüştür.

İnsanlar

# 1: Yetersiz motivasyon ...

# 2: Zayıf personel ...

# 3: Kontrolsüz sorunlu çalışanlar ...

# 4: Kahramanlar ...

# 5: İnsanları geç bir projeye eklemek ...

# 6: Gürültülü, kalabalık ofisler ...

# 7: Geliştiriciler ve müşteriler arasındaki sürtünme ...

# 8: Gerçekçi olmayan beklentiler ...

9: Etkili proje sponsorluğu eksikliği ...

# 10: Paydaş katılımının olmaması ...

# 11: Kullanıcı girişi eksikliği ...

# 12: Politika madde üzerine yerleştirildi ...

# 13: Arzulu düşünme ...

süreç

# 14: Aşırı iyimser programlar ...

# 15: Yetersiz risk yönetimi ...

# 16: Yüklenici hatası ...

# 17: Yetersiz planlama ...

# 18: Baskı altında planlamanın bırakılması ...

# 19: Bulanık ön uç sırasında zaman kaybı. "Bulanık ön uç", projenin başlamadan önceki zamanı, normal olarak onay ve bütçeleme sürecinde harcanan zamandır ...

# 20: Kısa vadeli yukarı havza aktiviteleri ... "Kodlamaya atlamak" olarak da bilinir ...

# 21: Yetersiz tasarım ...

# 22: Kısa vadeli kalite güvencesi ...

# 23: Yetersiz yönetim kontrolü ...

# 24: Erken veya çok sık yakınsaklık. Bir ürünün piyasaya sürülmesinden kısa bir süre önce, ürünü piyasaya sürmeye hazırlamaya yönelik bir zorlama var - ürünün performansını artırın, nihai belgeleri yazdırın, son yardım sistemi kancalarını kullanın, kurulum programını parlatın, olmayacak işlevselliği saptayın zamanında hazır, vb ...

# 25: Tahminlerden gerekli görevleri yapmak ...

# 26: Daha sonra yetişmeyi planlıyoruz ...

# 27: Kod-cehennem programlama. Bazı kuruluşlar hızlı, gevşek, her şey yolunda kodlamanın hızlı gelişim için bir yol olduğunu düşünür ...

Ürün

# 28: Gereksinimler altın kaplama. Bazı projelerin en başından beri ihtiyaç duyduklarından daha fazla gereksinimi var ...

# 29: Özellik sürünmesi ...

# 30: Geliştirici altın kaplama. Geliştiriciler yeni teknolojilerden etkilenir ve bazen yeni özellikleri denemek için endişe duyarlar ... - ürünlerinde gerekip gerekmediği ...

# 31: Beni it, bana pazarlığı yap ...

# 32: Araştırma odaklı gelişme. Cray süper bilgisayarlarının tasarımcısı Seymour Cray, bir kerede ikiden fazla alanda mühendislik sınırlarını aşmaya çalışmadığını, çünkü başarısızlık riskinin çok yüksek olduğunu söylüyor (Gilb 1988). Birçok yazılım projesi Cray'den bir ders öğrenebilir ...

teknoloji

# 33: Gümüş mermi sendromu ...

# 34: Yeni araçlardan veya yöntemlerden fazla tahmin edilen tasarruflar ... Projeler önceki projelerden gelen kodları tekrar kullandıklarında fazla tahmin edilen özel bir durum ortaya çıkar ...

# 35: Bir projenin ortasındaki araçları değiştiriyorum ...

# 36: Otomatik kaynak kodu kontrolü eksikliği ...

Büyük Proje = Daha Karmaşıklık
Daha Karmaşıklık = Daha Belirsizlikler
Daha belirsizlikler = Harder Tahmininin için
Harder Tahmininin için = Kötü Tahminleri
Kötü Tahminler = Maliyet aşımları

Teklif sürecini suçluyorum. Anlaşmanın kağıt üzerinde en ucuz / en hızlı görünmesini sağlayabilecek grubu ödüllendirir.

Teklifleri bir araya getiren insanlar kazanma şansı yoksa zamanlarını boşa harcamak istemezler, bu yüzden normal tahminleri bekletilir. POE anahtarları yerine normal anahtarlar belirtenlerin, 80 dolardan tasarruf etmesini biliyorum. Fakat projenin POE'ye ihtiyacı vardı çünkü IP kameraları vardı. Bu 80 doların harcanması gerekiyor, ama şimdi şartnamenin dışında.

Ne kadar teklif alırsanız yapın, 2 aylık 2.000.000 dolarlık bir projenin hala 2 ay 2.000.000 dolar alacağına dair kesin bir inancım var. Doğru yapmanın pahalı olduğunu düşünüyorsanız, bekleyin ve yanlış yapmanın ne kadar pahalı olduğunu görün.

Muhtemel sebeplerden biri, tahminlerin daha küçük projelere dayanması, proje büyüklüğü ile maliyette doğrusal bir büyüme olduğu varsayılarak, aslında maliyet artışının örneğin artan karmaşıklık, ikinci proje süresi (gereklilik değişiklikleri için daha fazla zaman) vb. zor ve proje büyüdükçe, doğru tahmin etmek zorlaşır.

Diğer bir neden ise, optimizasyon yanlı tahminleridir: Teklifi kazanmak için fiyatı en iyi şekilde tahmin etmek için kullanılır. Proje ne kadar büyükse, en iyi durum senaryo o kadar düşüktür. Teklif verme kuralları, en iyimser teklif sahibinin kabul görmesini sağlar, böylece 5 satıcı gerçekçi bir tahmin yapsa ve 6'ncı iyimser olsa bile, iyimser teklifini kazanır ve başarısız olur. Yani bu bir çeşit olumsuz seçim.

Maliyet, yapılması gereken önemli bir ayrım olan 'yönetim' gözünde zamanlamayı engellemez. Bildiğimiz gibi, "dokuz kadın bir ayda bebek doğuramaz" , ancak kaç kişinin sorunların kendilerine atılan para miktarıyla ilgili olarak azaldığını düşündüğüne şaşıracaksınız. Kötü proje yönetimi, çoğu zaman mikro yönetim şeklinde kendini gösteren bir projedir (benim deneyimlerime göre) çoğu proje tanklamasının ana nedenidir. Mikro yönetim, 'yönetim' bir şeyin kontrolden çıktığını fark ettiğinde ortaya çıkar ve nedenleri hakkında ipucu yoktur.

Sebep olmadığında, projenin beklenen sonucu muhtemelen başlamayacak kadar büyük değildi. Tecrübelerime göre, eğer bir projenin zaman çerçevesi çok kısaysa, insanlar 'çifte iş' ile sonuçlanan hatalar yapmaktan hiç korkmazlar, hiç bir şey yapmazlar.

Bu nedenle, başarılı projeler üreten lider ekip geçmişine sahip deneyimli programcılarla yönetimin doldurulması gerekir. Böyle bir kişi olası gelire rağmen “Bunu sorumlu bir şekilde yapamazdık” diyebilir ve uzun süre yönetimde olmazdı, bu yüzden çoğumuz (nihayetinde) doktora yerine MBA'lere cevap veriyoruz.

Programcı olmayan bir programcının işe alınmasından sorumlu olduğu yerlerde çalıştığım şirket sayısını kaybettim. Bir zamanlar işe alım yöneticisinin hiçbir şey yapmak istemediği bir röportaj yaptım. Sorumlu olduğunuz kişi bir NFL antrenöründen Knuth'tan daha fazla ilham alırsa, proje aksa girecek.

Arada bir, iyi planlanmış, iyi anlaşılmış, gerçekçi ve görünüşte dümdüz bir şekilde karşılaşıyorsunuz. Her ne sebeple olursa olsun, altı ay gelişmeye, her şey kendini tersine çevirdi. Olur. Ancak, nadiren, bir projenin altında yatan nedenin yüceltilmiş bir domuz varili haline gelmesidir.

Yine de itiraf etmeliyim ki ... eğer haberleri izlerseniz, arada bir motosiklet kazası veya tren kazası göreceksiniz. Olay olmadan her gün zamanında gelen milyonlarca motosiklet veya treni asla duymazsınız. Aynı projelerle birlikte gider. Tabii, gerçekten, gerçekten kötü giden bir şeyin halka açık bir otopsisini görmek ilginç, ama neredeyse gerçekten iyi giden şeyleri hiç duymadınız. Tank edilmiş projelerin hala kural dışı olduğunu düşünüyorum.

Çoğu zaman aşağıdakilerden iki veya daha fazlasının bir kombinasyonu:

• bölümler arası işbirliği sorunu
• siyaset ... çok fazla siyaset ...
• yanlış takım
• gerçekçi olmayan zamanlama
• uygun metodoloji olmadan kapsamı değiştirmek
• eksik bilgiler

Konuyla ilgili güzel kitap: Death March .

İnsanlar bir yıl öncesindeki olayları ölçmeye ve tahmin etmeye çalışan, yazılım geliştirmenin öngörücü bir süreç olduğunu düşünme eğilimindedir. Bu mümkün değil! Yapı yazılımı cıvata üretimi değildir.

Aynı "trendin" ardından, tüm olasılıkları kapsayacaklarını düşünen ve daha sonra programcıyı sadece daktilolara dönüştüreceklerini düşünerek (yine bir yıl ileride) büyük bir analiz yapmaya çalışıyorlar. Birisi bunun işe yarayabileceğini nasıl düşünüyor? Bu tür davranışlar yalnızca kötü tahminlere ve çok fazla bürokrasiye yol açar.

Proje ne kadar büyük olursa, büyük bir kuruluş için çalışma olasılığınız o kadar artar. Kuruluş ne kadar büyük olursa yönetim o kadar fazla katman oluşturur. Ne kadar fazla yönetim katmanı olursa, o kadar zor bir haberdir (“alabileceğimiz şey için istediğimizi elde edemeyiz”) emir komuta zincirini oluşturmak için. Daha az kötü haber komuta zincirini oluşturabilir, bir fantezi planı kabul edilir ve daha sonra savunulamaz olduğu bilindikten uzun bir süre sonra tutulur.

Her boyuttaki yazılım projeleri "başarısız olma eğilimindedir" veya "maliyet aşımına uğramıştır". Sen köşeyi işyerinde maliyet taşması hakkında duymuyorum ama do FBI Sanal Vaka sistemi veya Denver Havaalanı bagaj taşıma sistemi gibi şeyleri duymak. Bu yüzden, tüm büyük sistemlerin arıza yapmadığını, ne de tüm büyük sistemlerin maliyet / zaman aşımına uğradığını iddia edeceğim.

Zamanında ortaya çıkan büyük projelerle karşılaştım (program proje sırasında bir kez ve yalnızca bir kez taşındı ) ve teknik özelliklerde (sadece birçok tedarikçiden 1 tanesi olduğumuz için bütçe bilgilerine erişimim yoktu). Beni hala etkileyen biri (ve bu sitede biraz yazdım), büyük bir (servet 500'ün ilk 100'ünde) finans müşterisi için büyük bir entegre müşteri yönetim sistemi idi. Konferans görüşmeleri sırasında insanların maaşları için günde yaklaşık bir yıl (100 yıldan fazla) harcadıklarını tahmin ediyorum.

Bagaj taşıma sistemi söz konusu olduğunda, yazılım yöneticileri "bu büyüklük ve karmaşıklıktaki projelere dayanarak, bu sistemin kurulması ve hata ayıklanması 4 yıl alacağını" söyledi. Satış ve üst düzey yöneticiler "havaalanı 2 yıl içinde açılıyor, müşteriye 2 yıl alacağını, dolayısıyla 2 yıl alacağınızı söyledim" dedi. Bir programcı veya yanlış menajer olup olmadığınızı görmek için yapılan test, şu sorunun basit bir cevabıdır: "Bagaj taşıma sistemi gecikmeli mi yoksa zamanında mı oldu?"

Müşteri ne istediğini tam olarak bilirse (ve çok az kişi yaparsa), maliyetleri ve zamanı kontrol altında tutma yolunda çok uzakta olacaklardır (ve bunlar oldukça iyi satış yapma eğiliminde olan insanlar). Projeniz, müşterilerinizin hayal bile edebileceği her olası özelliği yerine getirmek zorundaysa ve her bir departman, projeye evcil hayvanlarının tuğlaları eklendiğinde veto etme yetkisine sahipse, o zaman baştan başarısızlığa uğramayacaksınız (FBI’lar gibi). VCF projesi).

Gerçeklik Algısı

İşte şimdiye kadar bulduğum bu sorunun en iyi açıklaması. Tree Salıncak businessballs.com adresinden

Programlama kariyerimin başında "Gerçeklik Algısı" kavramı ile tanıştırıldım . Bunun için gerçekten minnettarım. Bunun sadece BT projeleri değil, herhangi bir projenin başarısız olmasının en büyük nedeni olduğuna inanıyorum .

Başarısızlıkların bir nedeni, büyük bir projenin genellikle yüksek profilli, iş için önemli bir proje olmasıdır. Projeler ve görevler yüksek olduğunda, insanları yalan söylemeye teşvik eder.

Patronunuz, tamamlanma durumunuzu yüksek tarafta tahmin etmenizi istiyor. Düşük taraftaki taşmaları ve gecikmeleri tahmin etmek istiyor. Bir sorunla karşılaştığınızda, göreve üç hafta katacağını duymak istemez; Bu gece birkaç saatte çalışabileceğini duymak istiyor.

Ve diğerleri ve diğerleri.

Bir müşteri için birkaç yıl önce bir projedeydim. Teklif ve proje planı tamamlandıktan sonra getirildim. Daha hızlı, daha hızlı ve gülünç maliyet azaltma kararları, personelin aşırı aşırı yüklenmesi, onlar için kaynak yok; masa, bilgisayar, başka bir şey yok.

Sonunda, projenin 7 ay ve 16 milyon dolara teklif verildiğini keşfettim. Bir zarfın arkasında 24 ay ve 50 ila 100 milyon olmalıydı. Yöneticim ve menajeriyle bir toplantı yaptım ve vakamı ve zaman veya bütçeye uyacak yakın bir yere nasıl gelmeyeceğimizi sundu; bütün sorunları küçümsemişlerdi. Toplantının sonunda CIO, bu teklifin her ikisini de esasen söylediklerim haricinde ne dediğimi söyledi.

Teknolojiyi yetenekli olmadığım bir teknolojiyle değiştirdiğinde projeyi devretme şansım oldu. Daha sonra birisiyle konuştum. Proje yaklaşık yarısı bitince ... 12 ayda ve 35 milyon dolarda iptal edildi.

Yüksek profilli büyük projeler insanları "bu bir hatadır" demekten caydırıyor. Hatalar tolere edilmez.

VonC'nin cevabını biraz detaylandırarak:

Bu büyük projeler "hepsi ya da hiçbiri" zihniyetine sahip olma eğilimindedir. Tanımlanan proje tek seferde piyasaya sürülmelidir - çoğu zaman varolan bir sistemden bir değişiklik olduğu için.

Bu, özellik / ihtiyaç sürünme sorunlarının ele alınması daha zor olduğu anlamına gelir; bu nedenle proje meyve vermeye geldiğinde, genellikle artık gereksinim duyulan gereksinimler olarak görülmez. Mevcut sistem güncellendiğinde ya da teknoloji bu arada devam ettiğinde, bu durum daha da kötüleşebilir.

Bunun çözümü nedir?

Hiç kimsenin, ikisi arasında bölünmüş değişen işlevler dizisine paralel olarak çalışan iki sistemin olmasını istediğini bilmiyorum.

Büyük projenin karmaşıklığı, dış politik baskılar tarafından çılgınca alevlenebilir. Bir bölümün yeni sistemde ne istediğine dair çok net ve odaklanmış bir fikri olabilir, ancak daha sonra ilişkili bölümler "Peki, bunu yaptığınız sürece neden yapmıyorsunuz? Bu küçük yan görevi de bizim için yapar mı? “Hayır, bu kapsam dışı.” Diyerek başlayabilirsiniz, ancak daha sonra iş dünyası arasındaki siyasi çatışma başlar ve herkesin pastasını alamadığı sürece projenin bütçesi tehdit altındadır.

Yerel polisimiz yıllarca, saçma bir şekilde basit görünen bir özellik olan motorlu taşıt sistemi üzerinden arama yapamadı. Bir arkadaşıma bu özelliği eklemek için dünyadakilerin ne kadar zor olduğunu sordum ve modern bir veritabanına geçmeyi teklif ettikleri her seferinde, eyalette motorlu taşıt sistemleriyle herhangi bir etkileşimi olan devletlerin kendi bölümlerini almak istediklerini söylediler. sistem de düzeltti. Sonuç, BT modernizasyonunda tam bir kilitlenme oldu. Sonunda, devlet, sistematik bir modernleşme çabası için yeterli sermayeyi bir araya getirdi.

Dokunulmuş ancak henüz ele alınmamış bir faktör:

Hemen hemen tüm dramatik başarısızlıklar teklif edilen sözleşmelerdir. Böyle bir durumda yetkin bir şirkete ne olur? Gerçekçi bir tahmin yaparlar ve bu yüzden neredeyse kesin olarak kötü bir tahminde bulunan bir kişi tarafından teklif edilir.

Eğer şirket doğru bir şekilde tahmin edemiyorsa, bir sistemi de doğru şekilde kuramaması şaşırtıcı mıdır?

ZDNet'teki Michael Krigsman'ın , burada ilgisini çekebilecek “ IT Project Failures ” adlı bir blogu var.

Diğer bir nokta ise, yıllarca süren uzun projelerle, genel olarak ya dikkate alınacak iyileştirmeler ya da alternatif çözümler ortaya çıkmasıdır. Örneğin, artık daha fazla ortaya çıkmaya başlayan bir şey için yerinde, bulutta yerinde bir proje yapılabilir mi? bunlar proje başladığında verilen bir şey değildi. Örneğin, bir şey 6.0'da iken başlayabilirken, ilk aşama bittiğinde 6.3 veya 6.4 çıkışı olabilir ve ne zaman yükseltme yapılacağı sorusu olabilir. Kapsam ve istenen işlevsellikteki değişiklikler, gerekliliklerin doğru şekilde yerine getirilmediğinden veya birinin fikrini değiştirmesinden dolayı, zaten çoktan ele alınan başka birkaç nokta.

Çevik bu tür projelerde kullanılabilir mi yoksa geleneksel yaklaşım hala en iyisidir.

İyi uygulanmış çevik işlemlerin neden bu sorundan muzdarip görünmediğinin nedeni basit bir sebeptir. Büyük bir projeye çevik bir şekilde başlayamazsınız. Birini veya diğerini seçebilirsin.

Çevik bir süreçle, asla projenin geleceğine bir veya iki kez tekrarlanmayacaksınız. Gelecek 2 yıl için bir 'plan' yoktur, sadece iki hafta. Görüşün bu kadar kısaysa, birkaç taviz vermelisin. Ne tür bir widget tasarlıyorsanız, "Widget'lardaki son kelime" yapma planıyla başlayamazsınız. En çok "frob yapabilen bir widget" ile başlayabilirsiniz, çünkü bir ya da iki yinelemede yapabileceğiniz en fazla iş budur.

Bu konuda iyi bir şey, birkaç yinelemeden sonra, birisinin yararlı bulabileceği, özellikle frob ve zaplayabilen bir widget'a ihtiyaç duyan bir müşterinin, bulabileceği tamamlanmış, çalışan bir ürününüz var .

Temel olarak, büyük projeler başarısız olabilir, çünkü potansiyel müşterilerin tüm sorunlarını çözmeyi amaçlar. Çevik bir projenin asla bu amacı yoktur, bunun yerine her sürümde tek bir müşterinin sahip olabileceği kritik bir konuyu ele almaktır. Uzun bir süre sonra olsa da, çevik bir proje müşterilerin birçoğu için kritik sorunları çözüyor olabilir.

• Gerçek kullanıcılara gönderilemedi

Büyük projeler yıllarca "altyapı" moduna girme eğilimindedir ve gerçek son kullanıcı özellikleri oluşturma ve bunları gönderme gibi şeyleri unuturlar. Gönderildiği zaman, değiştirilmesi çok pahalıdır ve genellikle en büyük kavramsal değişiklikler ilk gerçek beta testinden sonra sorulmaya başlanır.

• Maliyetin doğru bir şekilde tahmin edilememesi

Projeler yatırım geri dönüşlerini artıracak gibi görünüyorsa iptal edilir.

• Kaliteyi kontrol edememe

Yeterli kusur olduğunda, ileri momentumun sıfıra veya altına düşmesi mümkündür. Hiç bir ilerleme olmadan devam eden varlığın tartışılması güçtür.

Hofstadter Yasasını unuttular: Hofstadter Yasasını hesaba katsanız bile, her zaman beklediğinizden uzun sürüyor.

Web Geliştirme'de Gördüğüm Şeyler:

• Çok fazla aşçı - Vurgu birden bire ağa geçtiğinde Binbaşı B&M Perakendecisi. Aniden 20 Bölüm başkanı, yeni baş peynirini etkilemek için her girişimi engelliyor. Bir zamanlar yeni ikonlar uygulamak zorunda kaldım, çünkü yasal olan eskilerin görünüşünden hoşlanmadı.

• Hedeflere ulaşma konusundaki özelliklerin eşleştirilmesine aşırı odaklanma - "IE6'nın ikonları IE7'ninkilerle karşılaştırıldığında biraz soluk görünüyor. Lütfen yaptığınız lansman tarihi kritik çalışmasını bırakın ve günler sürecek korkunç şeyler yapmak için müşteri tabanımızın% 0,05'ine gidin. IE deneyimini daha da fazla uygulamak ve yavaşlatmak. "

• Kendi geliştiricilerinden tavsiye alma zahmetine girmeyen, kötü niyetli olmayanlar tarafından seçilen Kötü Araçlar.

• Kötü araçlar, araçlarla seçildi - "Sürüm kontrolünü kullanmak için çok az şey bilen 200 okuryazar çocuğu zorlukla kodlayabildiğimizde neden 20 yetkili Java devine iyi bir maaş ödüyorsunuz?" eşzamanlı olarak ve farklı ülkelerdeki insanlarla olduğu gibi, öncelikle 3 büyük uygulama için arka uçlarda çalışır.

• Kötü / Kırık Mimari - İşten çıkarılan veya şimdi yönetici olan kişiler tarafından paniklenen, dün yapılan kodun katmanlarına katmanlar.