``Az´´ daha mı iyi?

0
cbc
Web 2.0'da yapılan konuşmalardan birisinin konusu "Az"ın iyiliği. Konuşmacı rakiplerinizle giriştiğiniz yarışı kazanmanın yolunun ondan bir ya da daha fazla işi yapabilmekten ziyade "az"lıktan geçtiğini savunuyor.

Anladığım kadarı ile özetleyeceğim bu maddeler ile ilgili fazlamesai.net ne düşünüyor?
  1. Daha az para. Zaman değişti. Bu zamanda diğer insanların parası sizi borca sokar ve bu birşeylere başlamak için hiç de iyi bir nokta değil. Donanım için paraya ihtiyacınız yok -- donanım ucuz. Yazılım için paraya ihtiyacınız yok -- yazılım özgür. Pazarlama için paraya ihtiyacınız yok -- birşeyleri kitlelere duyurmak için bedavaya yakın yollar var. Para size ne zaman satın alabilir ne de tutku. (İşinizi iyi yapabilmeniz için tutkulu olmalısınız). Para size sadece "maaş satın alır", maaş ise insan.
  2. Daha az insan. Web tabanlı uygulama hazırlamak için 3 kişi ile başlamak yeterli. Bir programcı, bir tasarımcı ve ikisine de yardımcı olabilecek ve pazarlamadan temel düzeyde anlayan birisi. İnsan sayısını istediğiniz özellik ya da bakış açısına göre ayarlamak yerine bunları insan sayısının yetebileceği bir düzeye indirin. Daha az insan varsa zamanının da daha az demektir.
  3. Daha az zaman. Rakiplerinizin haftada 40 saat çalışacak 10 elemanı var (40 x 10 = 400) fakat sizin haftada 40 saat çalışacak 3 elemanınız var (40 x 3 = 120). Bu bir dezavantaj gibi görünüyor değil mi? Aksine bu büyük bir avantaj. Çalışarak harcadığınız zamanın büyük bir kısmı boşa gider. Çok fazla toplantı, çok fazla planlama, çok fazla düşünme, çok fazla kağıt işi. Ne kadar çok zamanınız olursa boşa gidecek zamanınız da o oranda artacaktır -- muhtemelen kullandığınızdan daha fazlasını harcarsınız. Daha az zamanınız olduğunda bu vakti daha doğru kullanırsınız. Zamanın para olduğunu düşünün (cbc: zaten öyle!): Eğer ki bankada 500YTL'niz varsa bunun 400'ünü televizyon almak için harcamazsınız. Paranızı daha dikkatli harcarsınız. Tıpkı 400 yerine 40 saatiniz olduğunda yapacağınız gibi. Daha az zamanınızın saati daha değerli olacaktır.

    Ayrıca insanlar günde daha fazla saat, haftada daha fazla gün ve ayda daha fazla olmasını isterler. Daha fazla zaman yerine daha az zamana ihtiyacınız var. haftada 40, 50 ya da 60 saat çalışmak yerine geliştirme zamanınızı 20 ya da 30 saate indirin. Muhtemelen daha çok "gerçek iş" yaparsınız.
  4. Daha az soyutlama. Daha az kağıt işi, daha az soyut iş yapın. Daha çok gerçek iş yapın. Daha az kutu, daha az ok, daha az grafik çizin. Gerçek işten soyut olan işlerin daha azını yapın -- müşterilerinizin göreceği gerçek ürün.
  5. Daha az yazılım. Tüm bu azlığın bağlandığı ana nokta: Daha az yazılım. Daha az para, daha az insan, daha az zaman ve daha az soyutlama sizi daha az yazılım geliştirmeye itecektir. Bu mükemmel. Daha az yazılım enerjinizi ve zamanınızı daha az özelliğe kanalize etmenizi sağlar. Daha az işe daha fazla dikkat o işlerin daha iyi olmasını sağlar. Zamanınızın %100'ünü 20 işe ayırmak yerine 10 işe ayırırsanız sonuçta daha güçlü 10 iş yapmış olursunuz. Böylece hazırlaması ve kullanması tatmin edici, basit, üzerinde uğraşıldığı belli olan bir yazılımınız olur. Bu günleri kazanmanın yolu budur.
  6. Daha fazla kısıtlama. Bütün bu azlık aslında daha fazla kısıtlama için. Bu yaratıcı olmanızı gerektiren sebep. İşte bu sebepten işgücünüzü daha yaratıcı kullanmalısınız. Bu kısıtlamadan daha iyi, daha tatmin edici ve daha basit çözimler ortaya çıkacak. Asıl gerçek daha karmaşık problemleri çözmenizden önce çözülmesi gereken milyonlarca daha basit problemlerin olduğudur. Daha az yazılım daha basit sorunları çözer. Bırakın rakipleriniz daha karmaşık sorunlarla debelenirken kendini yoketsin. O sorunları çözmek gerçekten zor, pahallı ve kötü sonuçlar doğurabilir. Basit kalın, basit yapın, basit çözün.

Görüşler

0
darkhunter
8-D ilginçtir biz firmamızda bu standartları uzun zamandır koruyoruz. Bunların bazılarının iyiliğinden pek emin değilim ama... Örneğin, daha az soyutlama kısmı : Tecrubelerime dayanarak, özellikle bir çalışanın zaman zaman bu iş üstüne düşünmesi gerek. Sürekli pratiğe yönelik çalışmak bir süre sonra iş kalitenizi düşürüyor. Çoğunlukla, çalışanların soyutlama başarısıda aynı eksende olmuyor ne yazık ki. O yüzden soyutlama konusunda çalışacak birileri lazım. Çalışanlar bu işe zaman ayıramayacak kadar meşgulse, patronlar soyutlama için biçilmiş kaftan olur, hemde diğer kriterleriniz sarsılmamış olur bu sayede :)
0
cbc
"Hiç" demiyor zaten. "Daha az" diyor. Yazılım hiç okumyacak dokümanlarla vakit harcamayın diyor. Belli bir hacmin üzerindeki firmalara "tasarlanan" işlerde bu kısım ciddi rol oynuyor. 1 paragraflık fikri 30 sayfa doküman ile anlatmanız gerekiyor. bunu bekliyorlar.
0
cbc
dağıtmışım cümleleri. toparlayayım. "Hiç" demiyor zaten. "Daha az" diyor. En azından yazılım geliştirme ve kullanım aşamasında hiç okunmayacak dokümanlarla vakit harcamayın diyor. Belli bir hacmin üzerindeki firmalara "tasarlanan" işlerde bu kısım ciddi rol oynuyor. 1 paragraflık fikri 30 sayfa doküman ile anlatmanız gerekiyor. bunu bekliyorlar. En az bir tane tasarım aşaması için ayrılan süresinin en fazla %50 sinde bitebilecek bir proje biliyorum.
0
darkhunter
Eyvallah ama işin soyutlama kısmını optimize ederken daha az ibaresini kullanmak beni rahatsız ediyor açıkçası.

İşin özellikle soyutlama bölümünde ayarı kaçırırsanız, projeyi tekrar gözden geçirilmesi gereken belgelerle de gereksiz yere uzatmanız mümkün ki genellikle bu işte ayarı kaçırmak böyle sonuçlar doğuruyor.
0
darkhunter
Ek: Yoksa çıkıpta bir allahın kulu : "soyutlamak lazım" demiyor genellikle, "bu işin azı makbül" tümcesi gördüğüm kadarıyla hakim yaklaşım türü bu. Rahatsızlığımın nedeni de bu.
0
azertet
burada yazıdaki konsept azlık üzerine kurulduğu için herhalde soyutlama için de aynısı denmiş, fakat muhtemelen yazıyı yazan kişi de soyutlamanın öneminin farkındadır. abartılmasın demek istiyor olabilir. gerekli olduğu kadar soyutlama daha doğru bir ifade olabilir.
0
neurorebel
Yazı çok güzel bence. Soyutlamanın dozunu iyi ayarlamak gerek eyvallah. Ama genelde zaten yeterli kadar yapılmıyor. Yeteri kadar önemlide görülmüyor zaten... Şöyle bir serzenişim var idi geçenlerde.. :) M.Y.M.
0
anonim
Ozellikle 3. maddenin az dokumantasyon kısmına katılmıyorum. Ozellikle program ve yapısı ile ilgili dokumantasyonun oldukca detaylı bir sekilde yapılması gerekiyor. Yazılım Gelistirme Yasamdongusu(SDLC) nun her adımında ne yapıldıgına dair yeterli hatta detaylı bilgi dokumante edilmeli.

Yazılım gelistirmeyi adımlara ayırırsak

1- Kullanıcı tarafı gelistirme talebi

2- Yazılım tarafı onayı

3- Planlama

4- Gelistirme

5- Testlerve sonucları(ozellikle kullanıcı kabul testleri)

6- Canlı ortama test ortamından aktarılması

7- Kullanıcı egitimi/kullanım dokumantasyonunun aktarılması

Bu asamaların bazıları detaylı dokumantasyon gerektirse bile sadece sozkonusu taraflar tarafından imzalanarak gecilebilecek asamalar da vardır. Ozellikle teknik gereksinimin "business" tarafınca belirlenmesi, bunların gerceklestirilebilirliginin IT tarafınca onaylanması gerekmektedir. Program yazılırken kod yeterice acıklama ile birlike yazılmalıdır. Test asaması en onemli asamadır. Istenmeyen degisikligin sisteme atılmadan onlenmesı eger ayrı bir kalite yonetimi yoksa mumkun degildir. En azından kullanıcı onayları alınmalıdır. Bu imzalar mumkunse formal bir ortamda gerceklestirilmelidir.. Programın canlı ortama atasımasında tasımayı yapan programcı ve yoneticilerinin onayı olmalıdır.

Yazdıklarım sizleri urkutmus olabilir ancak genelde uygulanmayan ideale yakın dongu bu olmalıdır.

0
cbc

Az "kağıt işi"nden kasıt "gerektiğinden fazlasından kaçınmak" olsa gerek. yoksa hiç yapmayın demek değil. kimse "doküman yazmaya gerek yok" demiyor meraklanmayın :)

bu bahsettiğiniz maddelerin önemi proje büyüdükçe artıyor ve uygulanması gerekiyor. büyüdükçe de uygulanıyor zaten.

Yazılım geliştirme modelleri

0
FZ
6 ila 10 maddelik listelerle size bir şeyleri hap usülü aktarmaya çalışan yazılara daha az önem verin. O'Reilly'den gelmiş olsa dahi. (buzzword'lere ve "hype"lara karşı da daima tetikte olun, 1 milyon dolarlık şirketlerde çalışan yazılım ekipleri ile kendi küçük ekibinizi kıyaslarken çok çok çok dikkatli olun [kaç madde oldu? :)])
0
cbc
küçük projenizde maddeleri umursamadan çalışın. oldukça başarılı çalışmalara imza attıktan sonra milyon dolarlık firmaların size iyi bir teklifte bulunmasını bekleyin. ardından zaten o maddelere boğulacaksınız. zamanınız varken boğulmayın! :)
0
darkhunter
Otomatiğe bağlamayın... Bu maddeler milyon dolarlık yazılım geliştirme guruplarını hedeflemiyor. Dikkat edin. İş kalitesi ve ekonomi için küçük gurupların incelemesi gereken bir özet bence.
0
cbc
evet. "3 kişi" kesinlikle küçük br grup. ama küçük grupla büyük bir iş başlatmak zor olmasa gerek :)
Görüş belirtmek için giriş yapın...

İlgili Yazılar

GNU/Linux Ortamında Webcam İle Hareket Algılama

FZ

Başlık biraz fazla ciddi gelmiş ya da kafa karıştırmış olabilir o yüzden kısaca derdimi ve bu makalenin ana temasını belirteyim: Basit bir kamerayı GNU/Linux çalıştıran bir PC´ye USB portu üzerinden bağladıktan sonra bir tür ilkel gözetleme/uyarma sistemi kurma işini adım adım anlatmak.

Yemeği hazırlamaya başlamadan önce malzeme listesine bir göz atalım:
  • 1 adet PC
  • 1 adet Debian tabanlı KNOPPIX 3.1 Bootable Live CD
  • 1 adet PHILIPS PCVC 730K webcam
  • 1 adet hareket tespit (motin detection) yazılımı

LKD Yılın En İyi Basılı-Görsel İçerik Çalışması: fazlamesai.net

larweda

Linux Kullanıcıları Derneği yılın penguenleri 2004 ödülleri kapsamında fazlamesai.net web sitesi "En İyi Basılı-Görsel İçerik Çalışması" dalında ödüle layık görüldü. Bu ödülü hepimiz adına Ankara Milli Kütüphanede düzenlenen 3.ncü Linux ve Özgür Yazılım Şenliğinde biz kabul ettik. Hepimize hayırlı olsun!

Ian Murdock Burada, Richard M. Stallman Burada FM Okurları Nerede?

FZ

Ziyaretçiler bir bir gelmeye başladı. Debian projesinin kurucusu Ian Murdock şu anda Bilgi Üniversitesi kampüsünü ziyaret ediyor. Diğer yabancı konuklar da gelmeye başladı. Richard Stallman da varmak üzere.

27 Şubat, yani Cuma, yani yarından itibaren İstanbul Bilgi Üniversitesi gümbür gümbür 3 günlük bir Özgür Yazılım ve Açık Kaynak etkinliğine ev sahipliği yapacak.

Gelebilecek tüm FM takipçilerine kapılar ardına dek açıktır, herkesi bekliyoruz. Gelmeyenleri kara listeye alıp dövücez :-P

Bilgisayarlar ve 2038 yılı

FZ

Belli bir süredir gündemde olan bir sorun bugün takip ettiğim Compunauts listesinde karşıma ilginç bir şekilde çıkınca FM kitlesi ile paylaşayım dedim.

Basit bir Perl komut satırı ile sisteminizin 2038 yılına nasıl tepki vereceğini inceleyebilirsiniz...

An Istanbul breakfast with Tim O'Reilly

sundance

It all began with a tweet; "Just arrived in Istanbul for #occrp meeting. Staying at the lovely Antalya hotel with a view of the sea of marmara. Now out for a ramble Tim O'Reilly"

I asked if he would care for an interview, to my surprise he kindly accepted, even introduced us to OCCRP people, stating that we are from "Turkish Slashdot", which made us feel both proud and overinflated :)

Let me say that all the blunders are mine (especially not mentioning more about OCCRP guys who are doing a wonderful job) while all the provacative thoughts belong to Mr. O'Reilly (of course I do not refer to the Fox Tv Guy :)

We enjoyed talking with him, I hope you enjoy reading it. (Bu uzun röportajın deşifresini ancak bitirebildim, bu yüzden daha fazla bayatlamadan çevirmek için beklemeyip yayınlayalım istedik. Türkçe halini (referanslar eklenmiş olarak) kısa süre sonra yayınlamayı umuyoruz.)