Örneklem büyüklüğünün proje uzunluğunu etkilemediğini nasıl açıklayabilirim?

Normalde kaynak veritabanından hedef veritabanına veri kopyalamayı ve bu verileri senkronize eden birkaç ek uygulama ayarlamayı içeren büyük kurumsal projelerimiz var.

Son proje 250.000 madde içeriyordu (veri satırları). Bir sonraki proje sadece 4.000 maddeden oluşacak. Proje yöneticileri / iş adamları, projenin tamamlanmasının 1 / 10'u olacağına inanıyor çünkü son projenin büyüklüğünün yalnızca bir kısmı.

İyi bir benzetme nedir, bir sistemden diğerine veri aktarmak için kod yazmanın, sayı öğesinden bağımsız olarak aynı tutarı aldığını - 1 maddeye veya 100.000.000 için yazmanın kabaca aynı süreyi bir programlamadan alacağını açıklayabilirim. bakış açısı.

Onlara ülkenin uzak bir bölgesine yeni bir dört şeritli otoyol inşa etmek gibi olduğunu söyleyin. Bu yolun günde 100 araba veya günde 1000 araba kullanıp kullanmadığı, yolu oluşturma çabası aynı olacaktır.

Kabul edersek, günde 1.000.000 araba destekleyecekse, yolu biraz daha sağlam hale getirmek zorunda kalacaksınız; Kirli ve bu faaliyetler yolu kaç araba kullanıyor olursanız olun sabit bir maliyet.

Onlara bir hesap makinesi verin ve onlardan ne kadar süreceği, 1238783423 - 9858238483 saatlerini eklemelerini isteyin. daha sonra 3423 ila 8483 eklemelerini isteyin ve yaklaşık 100000 zaman daha hızlı bir cevap beklediğinizi söyleyin.

Ayrıca (muhtemelen) yazılımın geliştirme zamanını çalıştırmak için harcayacağı süreyi etkileyen veri miktarını da açıklayabilirsiniz .

Yönetici konuşmasına koyun.

Saniyede 1 widgette widget yapmak için bir makine oluşturursanız, 100 veya 10000 widget yapmak için kullanmanız farketmez, makinenin kendisi de aynı zamana sahip olur.

fark çalışma zamanındadır, zaman değil.

Tüm yönetim sınıfları, varsayımsal widget fabrikalarıyla bu şekilde sorun üzerinde çalışır.

Bir benzetme kullanmayın. Sadece açıkla.

• Çok az sayıda öğe için (10?) Elle dönüştürmek en ucuzudur. Hiç bir program yazma.
• Az sayıda öğe için (100?) Bir program yazmaya değecektir. Teorik olarak mümkün olan, ancak pratikte küçük veri setinde görünmeyen verilerin bazı izinlerini göz ardı ederek tasarruf sağlayabilirsiniz. Veya, programın reddedebileceği ve elle de dönüştürülebilen küçük sayılarla görünür. Köşe kutularının gerçekte veride görünüp görünmediğini kontrol etmek için veriler üzerinde hızlı analizler yapmak mümkündür. Görünmezlerse, göz ardı edilebilirler.
• Bu noktayı geçtiğinizde, verilerin gerçek boyutunun bir etkisi olmaz. Her türlü girişi yapabilecek ciddi bir program yazmanız gerekir. Program 1.000 ürün veya 100.000 işleyebilir. Sadece koşması daha uzun sürüyor.

Eğitim, konuşmaktan daha iyidir :)

Gerçekten bir benzetme değil, ama yine de bu argümanla başa çıkmanın iyi bir yoluna inanıyorum: İçinde ölümcül bir kusur olduğunu göstermek.

Önceki projenizde (elde ettiklerimden itibaren) üzerinde bazı modifikasyonların bulunduğu verilerin kopyalanması yer aldı.

Doğru anladıysam, bu bir takımın, birkaç ay içinde 100 muhasebecinin yapabileceği bir şey olduğunu söylüyor. Öyleyse neden problemi yazılım geliştiriciler attılar?

Çünkü, yarattığınız yazılım 10 veya 10 milyon veri parçasını işleyip işlememesi umrunda değil (tam olarak değil, ama yöneticilerinizin O(n)karmaşıklığı önemsemesinden şüpheliyim ). Bu nedenle, muhtemelen daha ucuz, daha hızlı ve daha temiz (daha az hataya açık işlem).

Daha radikalseniz, yazılım ekibinin çalışma hızını beğenmezlerse, muhasebeciyi her zaman işi elle yapmaya çağırabilirler.

Bu, son projeyi geliştirirken yöneticilerinizin hayatlarını çok daha kolay hale getirdi ve şimdi, bir sonraki yazılım parçasını ya 10 milyon veya 4'te çalışacaklarını umursamayacaklarını anlamak için aynı mantığı uygulamak zorunda kaldıklarında 000 satır, aniden unuturlar.

Sanırım sizin durumunuzda yöneticiler sadece bir tahmin oyunu oynuyorlar ve 4000 ile 250000 arasındaki farkı gösterip biraz 'suçluluk' umuduyla ekibi daha hızlı çalışmaya zorluyorlar. Yanılıyor olabilirim ama bunu daha önce de gördüm.

Bir programcı ekibini yönetmenin korkunç bir yolu (aslında her türlü yaratıcı ekip) ve kimseye yardımcı olmuyor.

Bir benzetme istediğini biliyorum, ama bence bu yanlış teknik.

Diğerlerinin de bahsettiği gibi, veri boyutunun zaman oluşturma değil çalışma zamanını etkilediğini vurgulamanız gerektiğine inanıyorum .
Böylece, onlar için ayırın - aslında iki alt projeniz var, inşa ediyor ve çalışıyor. Bina projesi (çoğunlukla), ne kadar veri üzerinde çalışacağıyla ilgili olmamalıdır, yalnızca veri türleriyle ilgilidir.
Çalışma zamanına gelince - kesinlikle, veri boyutuna göre (önemsiz olmayan sabit ek yükler hariç) faktör olduğunu söyleyebilirler.

Melbourne’e gitmeniz gerekecek gibi - ama önce arabayı yapmalısınız.
Elbette, Sydney’e araba sürmek daha hızlı olabilir - ancak aracı inşa etmek aynı zaman alır.
_{Tamam, sonuçta sana bir benzetme verdim.}

Belki bir telefon? Müşteriniz ısmarlama bir telefon istiyor. Günde 0 arama yaparsa veya günde 100 arama yaparsa telefonunu oluşturmak için aynı miktarda zaman gerekir.

Bir telefonun aktardığı veriler, programınız tarafından kopyalanan verilere benzer.

Yöneticileriniz programın gerçek çalışma zamanı ile zamanla karıştırıyor gibi görünüyor. Ancak yanlış anlaşılmaları farklı olabilir. Daha az sayıda "alan" bulunduğunu varsayabilirler. Sadece daha az veri kaydı değil. 100000 ayrı veri alanı varsa, sadece 10 alanla karşılaştırıldığında çok büyük bir çaba olacaktır. Sistemden sisteme daha fazla haritalama çalışması. Bu durumda aslında doğru olabilirler, ancak hala bazı sabit yükler var ve zaman kazanmak için alan sayısına bölünemezsiniz.

Tarif etmeyi sevdiğim gibi veriler 2 boyutta uzunluk ve genişliğe sahiptir. Uzunluk kayıt sayısı, genişlik tüm tablolardaki toplam sütun sayısıdır.

Şimdi veri almak istediğinizde, bir delikten blok almak gibi bir şey. En küçük boyut için yeterince büyük bir delik açmanız ve ardından bloğu geçirmeniz gerekir.

Şimdi 10 milyon ve 10 bin ile en küçük boyut hala genişlik. Bu nedenle, delik açmanın ne kadar süreceğine karar veren genişliktir.

Metaforu tamamlamak için, daha küçük olan uzunluktaysa, verileri el ile yazmanız yeterlidir.

Her hafta yüzlerce müşteri dosyasını alıyorum.

Bulduğum şeylerden biri, küçük dosyaların genel olarak veri aktarımını geliştirmek için daha uzun sürdüğü, çünkü:

• Kurallara uyma olasılıkları daha düşüktür (standart dosya yapılarına sahibiz, daha önce küçük bir müşterinin bize istediğimiz standart biçimde veri verdiğini görmedim, ancak büyük olanlar bunun neden önemli olduğunu anlıyorlar)
• Özellikle veri bütünlüğü kuralları yerleşik olan bir veritabanı yerine (büyük dosyaların gelme eğiliminde olduğu) bir Excel dosyasından geliyorlarsa daha fazla veri bütünlüğü sorunu yaşama eğilimindedirler.
• Her seferinde aynı biçimde sunulması daha az olasıdır.

Standart bir çocuk süreci olan bir ana çocuk SSIS paketi oluşturarak gelişimde çok zaman kazandığımızı ve standart biçimdeki verileri almak için gerekli herhangi bir manipülasyonun ebeveynde yapılabileceğini bulduk. Bu şekilde, bir tahminde bulunduğumuzda kaç kaydın olduğu, ancak stanrdard'a ne kadar yakın olduğumuzla ilgili bir sorun daha az olur. Artık daha küçük şeylerin geliştirilmesi daha uzun sürdüğünde, standarda uymadıkları için çok fazla şikayet almıyoruz.

Program yazmak, yeni bir çalışanı işe almaya benzer. Onlara verileri nerede bulacağını, bununla ne yapacağını ve sonuçları nasıl vereceğinizi öğretmelisiniz. Doğru yaptıklarından emin olmak için bir süre onlara göz kulak olmalısın. Karmaşık / önemli bir işi varsa veya çok fazla iş yapacaklarsa, onları eğitmek biraz daha uzun sürebilir, ancak ne olursa olsun çok fazla zaman alır.

Birçok yönetici yeni bir çalışanı eğitmekle ilgilenen ek yükü bilir; bu nedenle bu onlar için anlamlı olabilir.

(Yeni çalışanınız ne kadar kayıt attıysanız olun, önemsiz bir zamanda işi yapabilecek kadar güçlü bir robot olduğu için analoji kopar.)