2018 yılından beri, yazılım sektöründe farklı alanlarda tanınmış ve yer edinmiş kişilerin bize göre anlamlı olan ve geçerliliğini koruyan sözlerini, Türkçeleştirerek ve bağlamlarına uygun şekilde açıklayarak #ünlüsözler hashtag’i ile sosyal medya hesaplarımızda paylaşıyoruz.

Şimdiye kadar paylaştığımız bu sözleri, aynı zamanda, bir blog yazısında sizler için bir araya getirmek ve bu deneyimleri kayıt altına almak istedik.

A

Aaron Levie

(Amerikalı bir girişimci ve bir kurumsal bulut şirketinin kurucu ortağı ve CEO’su)

 

“Basit ve küçük bir şeyle başlayın, sonra zamanla geliştirin. Eğer insanlar yaptınız şeye ‘oyuncak’ demeye başladılarsa, bir şey keşfetmenize kesinlikle az kalmıştır.”

“Başkalarının size cesaret vermesini bekliyorsanız, yanlış yapıyorsunuz. İnsanlar bir fikrin iyi olduğunu düşünmeye başladıklarında, muhtemelen çok geç kalınmıştır.”

Akshat Paul

(Yazılım uzmanı ve yazardır.)

 

“Kullanıcı arayüzü, kaotik karmaşıklıktan zarif sadeliğe geçiş sürecidir.”

Alan Cooper

(Visual Basic’in babası olarak tanınan, Amerikan programcı ve yazılım tasarımcısı.)

 

“Eğer kullanıcıların yazılımımızı hoş bulmasını istiyorsak, onu hoş bir insan gibi davranacak şekilde tasarlamalıyız.”

“Ürünün nasıl yapacağını tasarlamadan önce ürünün ne yapacağını tanımlayın.”

“Kullanılabilirliğin gücü sorunları belirlemede, tasarımın gücü ise çözümleri belirlemededir.”

Alan Kay

(Amerikalı bir bilgisayar bilimcidir ve PC, nesne yönelimli programlama ve GUI tasarımı konularındaki öncü çalışmaları ile tanınmaktadır.)

 

“Başkalarının ne yapacağı konusunda endişelenmeyin. Geleceği öngörmenin en iyi yolu onu icat etmektir.”

“Her teknolojinin, ne şekilde kullanılacağı hakkında değil ama neden, ne zaman ve ne için kullanılacağı hakkında özel bir kılavuzla birlikte gönderilmesi gerekir.”

Alan Perlis

(Amerikalı bir bilgisayar bilimci ve profesördür. Programlama dilleriyle ilgili çığır açan çalışmaları ile tanınmaktadır ve Turing Ödülü’nün ilk sahibidir.)

 

“Programlama hakkındaki düşünme şeklinizi etkilemeyen bir dili bilmenize gerek yoktur.”

“Aptallar karmaşıklığı görmezlikten gelir. Pragmatistler katlanır. Bazıları uzak durur. Dahiler onu ortadan kaldırır.”

“Sanat hayallerimizi yorumluyorsa, bilgisayar onları program kılığında yürütür.”

Alan Turing

(Ünlü bir İngiliz matematikçi, bilgisayar bilimcisi ve kriptologdur. Bilgisayar biliminin kurucusu sayılır. Turing makinesi ile modern bilgisayarların kavramsal temelini atmıştır. Adına, bilgisayar biliminin Nobel’i kabul edilen Turing Ödülü verilmektedir.)

 

“Bilgisayarın ‘akıllı’ olarak nitelendirilmeyi hak etmesi için; bir insanı, kendisinin de insan olduğuna ikna etmesi gerekir.”

Albert Einstein

(Nobel ödüllü, Alman teorik fizikçi.)

 

“Yeni bir fikir aniden ve oldukça sezgisel bir şekilde gelir. Ancak sezgi, geçmişteki entelektüel deneyimlerin sonucundan farklı bir şey değildir.”

Aldous Huxley

(İngiliz bir yazar ve filozoftur. Aralarında distopya türünün önemli örneği kabul edilen “Cesur Yeni Dünya” nın da olduğu roman ve kurgu dışı türlerinde yaklaşık elli kitabı vardır.)

 

“Teknolojik ilerleme bize yalnızca, geriye doğru gitmemiz için daha verimli araçlar sağladı.”

Alex Engelberg

(Bir yazılım mühendisi, aynı zamanda bir müzisyen ve yapımcıdır. TikTok’ta yaptığı müzikal komedilerle de tanınmaktadır.)

 

“Programlama, kendinize ölünceye kadar ‘Bir saat içinde bir toplantım var, bu yüzden buna henüz başlamayayım’ demektir.”

Alistair Cockburn

(Amerikalı bilgisayar bilimci, yazar ve yazılım geliştirmede çevik hareketin öncülerinden biri olarak bilinir.)

 

“Yeterli sayıda insandan oluşan ve iyi işleyen bir ekip, kullanmaları istenen süreç ve teknoloji onlara destek de engel de olsa, onlardan bağımsız olarak projeyi tamamlayacaktır.”

Amir Ghahrai

(Yazılım alanında 15 yılı aşkın deneyime sahip kıdemli bir kalite güvence (QA) mühendisidir. Özellikle karmaşık web ve e-ticaret uygulamaları ve sağlık endüstrisi yazılımlarının test edilmesi ve onaylanması süreçlerinde uzmanlaşmıştır.)

 

“Mümkün olan en fazla sayıda testi yapsanız bile bir yazılımın doğru çalıştığını kanıtlayamazsınız, ama tek bir test ile bir yazılımın yanlış çalıştığını kanıtlayabilirsiniz.”

Andrew Clark

(Facebook React Core ekibinde önyüz geliştirici olarak çalışmaktadır.)

 

“Programlamada, birisi size konuyu fazla karmaşık hale getirdiğinizi söylüyorsa; o kişi ya 10 adım gerinizde, ya 10 adım ilerinizdedir.”

Andrew Singer

(Illinois Üniversitesi’nde elektrik ve bilgisayar mühendisliği profesörü ve İnovasyon ve Girişimcilik Dekan Yardımcısı olarak çalışmaktadır ve ana araştırma alanı sinyal işlemedir.)

 

“Hata ayıklama sanatı, programınıza aslında söylemeyi düşündüğünüz şey yerine gerçekte ne söylediğinizi anlamaya çalışmaktır.”

Andy Hunt

(Bilgisayar programcısı, yazar, Agile Manifesto’nun 17 orijinal yazarından ve Agile Alliance’ın kurucularından biridir. olan Dave Thomas ile birlikte “The Pragmatic Programmer: From Journeyman to Master” kitabını yazmıştır.)

 

“Kısa yazılım tarihinde henüz hiç kimse kusursuz bir yazılım ortaya çıkarmadı. Senin ilk olma ihtimalin çok düşük.”

“Geliştirdiğiniz tüm yazılımlar test edilecektir; siz ve ekibiniz tarafından değilse, son kullanıcılar tarafından. Bu yüzden, yazılımınızı düzgünce test etmeyi planlasanız iyi olur.”

“Ortaçağda katedral inşaatçılarının kullandığı teknikler bugünün inşaat mühendislerine nasıl eskimiş görünüyorsa, bizim mühendisliğimiz de bundan yüz yıl sonra öyle görünecek; ama ustalığımız yine onurlandırılacak.”

“Yeteneklerimizle gurur duyabiliriz, ancak eksikliklerimiz, cehaletimiz ve hatalarımız konusunda dürüst olmalıyız.”

“Herhangi bir araç, dil veya işletim sistemi konusunda, en iyi çözüm diye bir şey yoktur. Sadece belirli koşullar altında daha uygun olabilen sistemler vardır.”

“Bugünün iyi yazılımları, çoğu kez yarının kusursuz yazılımlarından iyidir. Kullanıcılarınıza oynamaları için erkenden bir şey verirseniz, geri bildirimleri genellikle daha iyi ve nihai bir çözüme götürür.”

“Yazdıkları kod hakkında aktif şekilde düşünmeyen geliştiriciler, rastlantısal programlama yaparlar. Kod çalışabilir, ancak bunun belirli bir nedeni yoktur.”

“Kırık bir pencere – tasarımı kötü bir kod parçası, alışılması gereken kötü bir yönetim kararı – çöküşü başlatmak için yeterlidir. Kendinizi birkaç kırık pencereli bir projede çalışırken bulursanız, ‘Kodun geri kalanı zaten kötü, ben de ona uydurayım’ kafa yapısına gelmeniz oldukça kolaydır.”

“Yazılım geliştirme neredeyse tüm fizik yasalarından muaf olsa da, entropi bize ağır zarar verir.”

“Soyut anlamda, şartnamesini doğru şekilde yerine getiren bir uygulama başarılıdır. Ne yazık ki, bu sadece soyut faturaları öder. Gerçekte, bir projenin başarısı kullanıcıların beklentilerini ne kadar iyi karşıladığıyla ölçülür.”

Archibald Putt

(“Putt Yasası ve Başarılı Teknokrat” kitabının takma adı Archibald Putt olan yazarıdır.)

 

“Teknolojiye hükmeden iki tür insan vardır; yönetmediklerini anlayanlar ve anlamadıklarını yönetenler.”

Arthur C. Clarke

(İngiliz bir bilim kurgu yazarı, bilim yazarı ve fütürist, mucit, denizaltı kaşifi, televizyon dizisi sunucusu ve tüm zamanların en etkili filmlerinden biri olan 1968 yapımı “2001: A Space Odyssey” in ortak senaryo yazarı, “Clarke Kanunları” nın yaratıcısıdır.)

 

“Tanınmış ve yaşını almış bir bilim insanı bir şeyin mümkün olduğunu iddia ediyorsa, neredeyse kesinlikle haklıdır. Aynı kişi bir şeyin imkânsız olduğunu iddia ettiğinde ise, büyük olasılıkla yanılıyordur.”

Atli Björgvin Oddsson

(İzlandalı bir yazılım geliştirici, yazılım mimarı ve girişimcidir ve NASDAQ’da çalışmaktadır.)

 

“Kullanıcılarınızdan herhangi bir şikayet almıyorsanız, ya yazılımınızı kullanmıyorlardır ya da destek e-posta adresiniz çalışmıyordur.”

B

Betsy Beyer

(Google’da teknik yazardır.)

 

“Yalnızca güvenilirlik odaklı mühendislik değil, herhangi bir etkin yazılım mühendisliğinin temel ilkesi olan basitlik, bir kez kaybedildiğinde yeniden elde edilmesi olağanüstü derecede zor olabilen bir kalitedir.”

Bill Gates

(Microsoft’un kurucusudur.)

 

“Bir yazılımdaki ilerlemeyi, yazılmış kodun satır sayısıyla değerlendirmek, uçak yapımındaki ilerlemeyi uçağın ağırlığıyla değerlendirmek gibidir.”

“Zor bir işi yaptırmak için tembel birini seçerim. Çünkü tembel bir insan işi yapmanın kolay bir yolunu bulacaktır.”

“Eğer bir gün çok iyi bir programcı ile konuşacak olursanız; onun da araçlarını bir sanatçının fırçalarını bildiği şekilde, biliyor olduğunu görürsünüz.”

“Hâlâ, en iyi programlama yeteneği testlerinden birinin, programcıya 30 sayfalık kod vermek ve ne kadar çabuk okuyup anlayabildiğini görmek olduğunu düşünüyorum.”

“Başarı berbat bir öğretmendir. Akıllı insanlara kaybedemeyeceklerini düşündürerek baştan çıkarır.”

Bram Cohen

(BitTorrent’in yaratıcısıdır.)

 

“Bir programcının artık olgunlaştığının göstergesi; üzerinde zaman harcadığı kodu, anlamsız olduğunun farkına varınca, gönüllü bir şekilde kenara atabilmesidir.”

Brian Foote

(20 yılın üzerinde deneyimi olan bir araştırmacı ve yazılım geliştiricidir. Özellikle, yeniden kullanılabilir nesneler, çerçeveler ve örüntüler üzerine uzmanlaşmış ve “big ball of mud” kavramının kullanımını yaygınlaştırmıştır.)

 

“Eğer iyi mimarinin pahalıya geldiğini düşünüyorsanız, bir de kötü mimariyi deneyin.”

Brian P. Hogan

(Bir yazılım geliştirici, editör ve “Small, Sharp Software Tools,” “Exercises for Programmers” ,”tmux: Productive Mouse-Free Development” gibi teknik kitapların yazarıdır.)

 

“Bir ürünü pazara sunarken, kullandığınız teknolojiler sadece diğer geliştiriciler için önemlidir. Son kullanıcılar, sadece hızlı olmasını ve işlerini görmesini önemserler. Bu, bir geliştirici olarak en büyük önceliğinizdir. İnsanlara sorunlarını çözen ve sürdürülebilir ürünler sunun.”

“Projeyi ve müşteri ihtiyacını anlamadan, kullanacağınız teknolojiye karar vermeyin. İşiniz onların sorunlarını çözmek, kod yazmak değil.”

Bruce Schneier

(Amerikalı bir kriptograf, bilgisayar güvenliği uzmanı, gizlilik uzmanı ve yazardır. Genel güvenlik ve bilgisayar güvenliği üzerine kitapları vardır.)

 

“Teknik sorunlar çözülebilir. Dürüst olmayan bir şirket kültürünü düzeltmek çok daha zordur.”

Bjarne Stroustrup

( C++’ın yaratıcısı ve bir bilgisayar bilimcidir.)

 

“Yazılım geliştirmede en temel sorun karmaşıklıktır. Karmaşıklıkla uğraşmanın tek bir temel yolu vardır: böl ve yönet.”

“Yazılım geliştirme, basit bir mekanik montaj hattına indirgenemez. Büyük bir sistemi başarıyla oluşturmak için yaratıcılığa, mühendislik ilkelerine ve evrimsel değişime ihtiyaç vardır.”

“Programcılarına ahmakmış gibi davranan bir kurumun kısa süre içinde yalnızca ahmakça hareket edebilen programcıları olacaktır.”

“Global değişken ‘sadece bir tanecik’ olduğunda yönetmesi zor olmayabilir; ancak bu tarz, ilk yazan dışında kimsenin işine yaramayan bir kod ortaya çıkarır.”

Bob Frankston

(MIT mezunu bir bilgisayar bilimcidir. VisiCalc hesap tablosu programının yaratıcılarından ve onu geliştiren şirket Software Arts’ın kurucu ortaklarındandır.)

 

“Kod parçalarını yeniden kullanmak, başkalarının hikayelerinden cümleler kopararak bir dergi makalesi yazmaya çalışmak gibidir.”

“Eğer bir programı kendinize anlatamıyorsanız, bilgisayarın onu doğru anlama ihtimali oldukça düşüktür.”

Boris Beizer

(Amerikan yazılım mühendisi ve yazar.)

 

“Programcıları suçlamak, yarım asırlık yazılım geliştirme tarihinin yaygın yaklaşımı olmuştur. Bu yaklaşım henüz sorunu çözmedi, bu yüzden farklı yönlere bakma zamanı geldi.”

Butler Lampson

(Dağıtık kişisel bilgisayarların geliştirilmesine ve uygulanmasına yaptığı katkılarla tanınan Amerikalı bilgisayar bilimci.)

 

“Her şey mümkün olduğunca sade yapılmalıdır. Ancak, bunu yapabilmek için karmaşıklıkta ustalaşmanız gerekir.”

“Bazı insanlardan iyi programcı olur çünkü çoğu insandan daha fazla ayrıntıyla başa çıkabilirler. Ancak bir programcıyı bunun için seçmek dezavantaj yaratır; başkasının sürdüremeyeceği programlar ortaya çıkabilir.”

C

Cem Kaner – James Bach – Bret Pettichord

(Nasıl test yapılması gerektiğine dair varsayımlara yenilikçi bir bakış açısı getiren “Lessons Learned in Software Testing” (2002) kitabının ortak yazarlarıdır.)

 

“Testçiler, bir şeyleri bozmayı sevmezler; bir şeylerin çalıştığı yanılsamasını gidermeyi severler.”

Chad Fowler

(Bir yazılım geliştirici, eğitmen, yönetici, yatırımcı, konuşmacı, yazardır. “The International Ruby Conference” ve “RailsConf” gibi Ruby konferanslarının organizatörlerindendir.)

 

“Hepimiz hata yaptığımız için, herkesin hata yaptığını da biliyoruz. Bu nedenle, mâkul şekilde, birbirimizi yaptığımız hatalar konusunda değil, bu kaçınılmaz hatalarla nasıl başa çıktığımız konusunda yargılıyoruz.”

“Bir yarışı, kaybetmemeye çalışarak kazanmazsınız.”

“Asla hiçbir şeyi bitirmemenin en kolay yolu, asla hiçbir şeyi yapmaya taahhüt etmemektir.”

“Beyninizin sıraladığı ve anlamlandırdığı kavramlar ve modeller, herhangi bir tedarikçinin teknolojisinden çok daha ölçeklenebilir ve evrenseldir.”

“Yaşlandıkça, teknoloji alanında çözülmesi gereken en büyük sorunun, insanlara işleri olması gerekenden daha zor hale getirmeyi bıraktırmak olduğunu daha çok anlıyorum.”

“Nasıl çalıştığını bilene kadar bir işletmeye yaratıcı bir şekilde yardım edemezsiniz.”

“Yazılım geliştirme hem zorlu hem de ödüllendiricidir. Bir sanat formu gibi yaratıcıdır, ancak (sanattan farklı olarak) somut, ölçülebilir bir değer sağlar.”

Charles H. Ferguson

(Amerikalı yönetmen, yazar ve yazılım girişimcisidir.)

 

“Akıllı ve işe yarayan bir kod parçası yazmak ile uzun vadeli bir işi destekleyebilen bir ürün tasarlamak birbirinden oldukça farklı şeylerdir. Ticari yazılım tasarımı ve üretimi titiz ve sermaye yoğun bir faaliyettir; veya öyle olmalıdır.”

Chris Pine

(Ruby yazılım dilini kullanarak programlamayı öğrettiği “Learn to Program” kitabının yazarıdır.)

 

“Programlama, ne bildiğinizle değil; neyi çözebildiğinizle ilgilidir.”

Chris Sacca

(Amerikalı bir girişim yatırımcısı, şirket danışmanı, girişimci, avukattır. Ayrıca ABD’de Twitter, Uber, Instagram, Twilio ve Kickstarter gibi tohum ve erken aşama teknoloji şirketlerine yatırım yapan bir risk sermayesi fonu olan Lowercase Capital’in sahibidir.)

 

“Sadeliğin yapımı zor, kullanımı kolay ve ücretlendirilmesi zordur. Karmaşıklığın ise yapımı kolay, kullanımı zor ve ücretlendirilmesi kolaydır.”

Chris Wenham

(Yazılımın farklı alanlarında ve farklı teknolojilerle 20+ yıllık yazılım geliştirici ve yönetici kariyeri vardır. Stack Overflow ve Hacker Monthly yazılarıyla tanınmaktadır.)

 

“Her türlü görevi yerine getirebilecek kadar genel ve yapılandırılabilir olması için uğraşılan bir program, ya bu hedefin gerisinde kalacaktır ya da korkunç bir şekilde bozulacaktır.”

Christopher Baus

(Amerikalı yazılım geliştirici ve mühendislik yöneticisi.)

 

“Yazılım metodolojiler, diller ve hatta işletim sistemleri ile ilgili değil; çalışan uygulamalar ile ilgilidir.”

Cyrille Martraire

(Arolla’nın kurucu ortağı, Paris Software Crafters topluluğunun kurucusu, uluslararası konferanslarda konuşmacı ve “Living Documentation: Continuous Knowledge Sharing by Design” kitabının yazarıdır.)

 

“Yazılım geliştirme, tamamen bilgi ve bu bilgiye dayalı karar verme ile ilgilidir ve bu da ek bilgi yaratır.”

D

Dan Bricklin

(Amerikalı iş adamı ve mühendis.)

 

“Bazen bir programın ardındaki fikir, küçük bir yaratıcı çabadır. Tıpkı bir kısa hikayede küçük bir düğümün, olay dizisindeki tüm fikri oluşturması gibi.”

Daniel T. Barry

(Amerikalı bir elektrik mühendisi, bilgisayar bilimci, bilim insanı ve emekli bir NASA astronotudur. Yapay zekâ ve robotik üzerine uzmanlaşmıştır.)

 

“Doğru yapmak için hiçbir zaman yeterli vakit yoktur; ancak düzeltmek veya en baştan yapmak için her zaman yeterli vakit vardır.”

Daniel M. Berry

(Kanada’da Waterloo Üniversitesi’nde bilgisayar mühendisliği bölümünde akademisyendir. Yazılım alanında çok sayıda makalesi ve kitabı vardır.)

 

“Çok yetenekli olan ama alan koruması yapan, egoist ve politik kişilerden oluşan bir ekip başarısız olurken; aynı yetenek seviyesinde olan, egosuz davranan ve yardımlaşan takım oyuncularından oluşan bir ekip başarılı olacaktır.”

Daniel Hillis

(Amerikalı bir mucit, girişimci ve bilim insanıdır. Paralel bilgisayarlara ve bunların yapay zekâ alanında kullanımlarına öncülük etmiştir. 300’ün üzerinde yayınlanmış patenti vardır. 1998 yılında “The Pattern on the Stone” kitabını yayımlamıştır.)

 

“Bilgisayarın sihri; isteğinizi tam olarak açıklayabildiğiniz sürece, hayal edebileceğiniz hemen hemen her şeye dönüşebilme yeteneğidir.”

“Doğru programlama ile bir bilgisayar; tiyatro, müzik aleti, başucu kitabı, satranç rakibi olabilir. Dünyada insan dışında hiçbir varlık bu kadar uyarlanabilir, evrensel bir doğaya sahip değildir.”

Danny Thorpe

(Özellikle Delphi üzerindeki çalışmaları ile tanınan, derleyici ve dil tasarımı, nesne yönelimli uygulama mimarileri ve platform altyapısı konusunda uzman olan bir Amerikalı programcıdır.)

 

“Genel bir mimari veya tasarım olmadan programlama yapmak bir mağarayı sadece fenerle keşfetmek gibidir. Nereden geçtiğinizi, nerede olduğunuzu ve nereye gittiğinizi bilmezsiniz.”

Dave Muirhead

(Deneyimli bir yazılım geliştirici ve iş teknolojisi uzmanıdır.)

 

“Yazılım geliştirme temelde bir tasarım faaliyetidir, çünkü geliştirilen sistem üretime girene kadar devam eden bir karar verme sürecini içerir.”

Dave Parnas

(Kanada’da bilgisayar mühendisliğinin öncülerinden kabul edilmektedir. Yayımladığı 265’ten fazla makale ve raporla bilgisayar mühendisliğinin akademik olarak yaygınlaştırılmasına büyük katkısıyla bilinir.)

 

“Kural olarak, yazılım sistemleri gerçek uygulamalarda kullanılana ve art arda başarısız olana kadar iyi çalışmaz.”

“Bir kötü programcı, yılda iki yeni pozisyon yaratabilir. Daha fazla kötü programcı işe almak, daha da fazla kişiye ihtiyacımız olduğu algısını yaratır.”

Dave Thomas

(Bilgisayar programcısı, yazar ve yayımcıdır. Andy Hunt ile birlikte “The Pragmatic Programmer” kitabını yazmış ve yine birlikte “Pragmatic Bookshelf” yayınevini kurmuştur.)

 

“Kodunuz içine kapanık olsun. Modülleriniz, diğer modüllere gereksiz herhangi bir şeyi açık etmesin; onların uygulamalarına bel bağlamasın.”

“Eğer kod artık tam uymadığı için ayak bağı oluyorsa veya iki şeyin artık birleştirilmesi gerektiğini farkettiyseniz, ya da başka bir şey size ‘yanlış’ geliyorsa; değiştirmek için tereddüt etmeyin. Bugünün işini yarına bırakmayın.”

David Heinemeier Hansson

(Danimarkalı bir programcı, Ruby on Rails’ın yaratıcısı, Basecamp’ın kurucu ortağı ve CTO’sudur. “Rework” ve “It Doesn’t Have to Be Crazy at Work” gibi en çok satanlar arasına giren kitapların da aralarında bulunduğu 5 kitabın ortak yazarıdır.)

 

“Her şeyi öğrenemezsiniz. Her kavramı, tamamen genişletilmiş biçimde, kafanızda tutamazsınız. Kaldı ki; yapmamalısınız. Eskiden önemli olan kavramları sıkıştırarak, yeni ve daha büyük soyutlamalara yer açarız.”

David Wheeler

(Bilgisayar bilimci ve Cambridge Üniversitesi’nde bir bilgisayar bilimi profesörüdür.)

 

“Uygulamanın önceki versiyonlarına uyumlu olmasını sağlamak, başka insanların hatalarını kasıtlı olarak tekrarlamak anlamına gelir.”

Dennis Ritchie

(Amerikalı bilgisayar bilimci.)

 

“Bilgisayar bilimi geleneksel disiplinlerden farklıdır. Felsefi olarak fiziksel bilimlerden farklıdır; çünkü doğal dünyayı keşfetmeyi, açıklamayı veya ondan faydalanmayı değil, insan yaratımı makinelerin özelliklerini incelemeyi amaçlar. Bu açıdan matematiğe benzer ve aslında bilgisayar biliminin ‘bilim’ kısmı, özü itibarıyla matematikseldir. Ancak bilgisayar biliminin kaçınılmaz bir yönü, bilgisayar programlarının yaratımıdır. Bu nesneler, elle tutulmamalarına rağmen ticari değiş tokuşa tabidir.”

Donald Knuth

(Bilgisayar bilimci ve “The Art of Computer Programming” kitabının yazarıdır.)

 

“İnsanlar bilgisayar bilimlerinin dahilerin sanatı olduğunu düşünürler. Aslında, birçok insanın kendi elindekileri küçük taşlardan bir duvar oluşturur gibi üst üste eklemesidir.”

“Program inşasına karşı geleneksel tavrımızı değiştirelim. Asıl görevimizi bir bilgisayara ne yapması gerektiğini öğretmekmiş gibi hayal etmek yerine, bir bilgisayarın ne yapmasını istediğimizi insanlara açıklamaya odaklanalım.”

“Bilgisayar programlama bir sanattır, çünkü birikmiş bilgiyi dünyaya uygular ve beceri ve ustalık gerektirir. Bilinçaltında kendini bir sanatçı olarak gören bir programcı yaptığı işten keyif alacak ve onu daha iyi yapacaktır.”

“Bir şeyi yapmanın genellikle aklınıza gelen ilk yoldan daha basit ve daha iyi bir yolu olduğunu unutmayın.”

Donald Norman

(Amerikalı araştırmacı, profesör ve yazardır.)

 

“İyi tasarımın en iyi özeliklerinden ikisi keşfedilebilirlik ve anlayıştır.”

Donald G. Reinertsen

(Reinertsen & Associates’in başkanı ve “Managing the Design Factory“, “The Principles of Product Development Flow: Second Generation Lean Product Development“ ve “Kanban: Successful Evolutionary Change for Your Technology Business“ kitaplarının yazarıdır.)

 

“Ürün geliştirmeyi etkin bir şekilde yönetmek için, geliştirme döngüsü boyunca sürekli olarak değerli yeni bilgilerin geldiğini kabul etmeliyiz. Orijinal planımıza kilitlenip zamanda donup kalmaktansa, ortaya çıkan bu bilgiyi kullanarak iyi ekonomik seçimler yapmayı öğrenmeliyiz.”

Doug Linder

(Virginia Tech Mühendislik Fakültesi’nde elektrik ve bilgisayar mühendisliği doçentidir.)

 

“İyi programcı, tek yönlü bir caddede karşıya geçmeden önce daima iki tarafına da bakan kişidir.”

Douglas Adams

(Ünlü bir İngiliz bilim kurgu yazarı, komik radyo oyunu yazarı ve müzisyendir. En fazla “Otostopçunun Galaksi Rehberi” serisinin yazarı olarak bilinmektedir.)

 

“Elle yapıldığında yaklaşık 10 saniyemi alacak bir işi, tüm gün programlama yaparak otomatize ettiğimde mutlu olduğumdan daha fazla mutlu olduğum gün çok nadirdir.”

Douglas Crockford

(JavaScript dilinin geliştirilmesinde yer alan Amerikalı bilgisayar programcısı.)

 

“Maliyeti doğru hesaplanmış özellik odaklı pek çok ürün tasarımı görüyoruz. Fazla sayıda özellik, müşteride olumsuz etki yaratabilir, çünkü ürünlerin anlaşılmasını ve kullanılmasını zorlaştırır. İnsanlar işe yarayan ürünleri severler. Çalışan bir tasarım üretmek, uzun özellik listelerini birleştiren bir tasarım üretmekten daha zordur.”

“Matematik, programlama için önemlidir; ancak pek çok önemli şeyden yalnızca biridir. Gereğinden fazla önem verirseniz, okuryazarlık gibi daha önemli olabilecek şeylerin üzerinde yeterince durmamış olursunuz.”

“Açık ve tutarlı bir tarzda yazmak programlarınızın okunması daha kolay hale gelir.”

E

Edsger W. Dijkstra

(Hollandalı bir sistem bilimci, bilgisayar bilimci ve yazardır. “Dijkstra’nın algoritması” ile tanınmaktadır. 1972’de Turing Ödülü almıştır.)

 

“Kalite standartlarınızı mümkün olan en yüksek seviyeye yükseltin, rutin problemlerle zaman kaybetmekten kaçının ve yeteneklerinizin sınırına yakın çalışmayı deneyin. Ancak bu şekilde sınırlarınızı genişletebilirsiniz.”

“Kendini kusursuz hale getirmek; öğrenmek kadar, bazı öğrendiklerini unutmayı da gerektirir.”

“İşinin ehli olan bir programcı, kafatasının sınırlı büyüklüğünün tamamen farkındadır. Bu nedenle, görevine alçakgönüllülükle yaklaşır ve zekice numaralardan vebadan kaçar gibi kaçınır.”

“Elimizdeki göreve, onun muazzam zorluğunun farkında olarak, zihnimizin doğal sınırlarına saygı göstererek ve mütevazilikle yaklaşırsak, daha iyi programlama yapabiliriz.”

“Eğer kod satırlarını sayacak isek, onları ‘üretilen satırlar’ olarak değil ‘harcanan satırlar’ olarak değerlendirmeliyiz.”

“Yetenekli bir programcının matematiğe yatkınlık dışındaki en önemli varlığı, anadilindeki istisnai ustalığıdır.”

“Bundan 10 yıl sonra, basit ve kalitesiz bir yama ile çözüm uygularken, bir anda sizi dikkatle izlediğimi zihninizde canlandırıp; kendinize ‘Dijkstra bunu sevmezdi’ deseniz, bu benim için yeterli bir ölümsüzlük olurdu.”

“Kaosla savaşmalıyız ve bunu yapmanın en etkili yolu ortaya çıkmasını engellemektir.”

“Kullandığımız araçların düşünme alışkanlıklarımız ve dolayısıyla düşünme yeteneklerimiz üzerinde derin ve sinsi bir etkisi vardır.”

“Sadelik ve zarafet popüler değildir çünkü başarmak için sıkı çalışma ve disiplin gerektirir.”

Elisabeth Hendrickson

(Quality Tree Software, Inc.’in kurucusu, testçi ve geliştirici)

 

“Test otomasyonundaki en büyük başarımı, etkili bir araç kullanma stratejim olmasıyla elde ettim. En büyük başarısızlığım ise her şeyi otomatikleştirmek gerektiğini varsaymamın bir sonucuydu.”

Elizabeth Zwicky

(Güvenlik ve sistemi kötüye kullanma üzerine uzmanlaşmış bir Unix sistem yöneticisidir. Uzun yıllar boyunca Yahoo’da anti-spam mimarı olarak çalışmıştır. “Building Internet Firewalls” kitabının ortak yazarıdır.)

 

“Tornavidası olan bir yazılım geliştiriciden veya programı olan bir donanım mühendisinden daha korkutucu olan tek şey, tel keskisi ve root şifresi olan bir kullanıcıdır.”

Elon Musk

(Girişimci, iş adamı, SpaceX’in kurucusu, CEO’su ve baş mühendisidir.)

 

“İnsanlar teknolojinin kendiliğinden geliştiğini düşünerek yanılırlar; kendi kendine gelişmez. Sadece birçok kişi onu daha iyi hale getirmek için çok çalışırsa gelişir ve aslında, bence, kendi kendine geriler.”

Eric Evans

(Yazılım tasarımı ve alan modellemede bir düşünce lideri, Etki Alanı Dili’nin kurucusu ve yazardır.)

 

“Başarı, tüm ayrıntıları anlamlandıran, ortaya çıkan bir dizi soyut kavramda gelir. Bu damıtma, en uygun bulunan belirli bilginin titiz bir ifadesidir.”

“Esnek tasarımın, yazılımın değişim ve karmaşıklıkla başa çıkma yeteneği üzerinde derin bir etkisi vardır.”

Eric S. Raymond

(Amerikalı bir yazılım geliştirici ve açık kaynak savunucusudur. Aralarında açık kaynaklı bir projenin nasıl yürütüleceğini anlattığı “The Cathedral & the Bazaar”ın da yer aldığı pek çok yayımlanmış kitabı bulunmaktadır.)

 

“Kullanıcılarınızı birlikte geliştirme yaptığınız kişiler gibi ele almak, hızlı kod iyileştirme ve etkili hata ayıklama için en az zahmet veren yoldur.”

“Tüm iyi yazılım projeleri, bir yazılım geliştiricinin kendi kişisel sorununu çözmek için yola çıkmasıyla başlar.”

F

Federico Toledo

(Uruguaylı bir bilgisayar mühendisidir ve test üzerine doktora yaptıktan sonra kalite mühendisliği alanında ilerleyerek performans testi, test otomasyonu ve fonksiyonel testler üzerine yoğunlaşmıştır. İspanyolca olarak yayımladığı bir kitabı vardır.)

 

“Yaşadığınız darboğazlarla ilgili olmayan herhangi bir optimizasyon, ilerlediğinize dair bir yanılsamadır.”

Felix von Leitner

(Alman bir BT güvenlik uzmanı ve standart bir C kütüphanesi olan dietlibc’in ana yazarıdır. Fefe olarak adlandırılmakta ve kişisel blog yayınları Almanya’da medyada geniş yer bulmaktadır.)

 

“Eğer bir veri yapısı bardak altlığı üzerinde açıklanamıyor ise, fazla karmaşıktır.”

 

Filipe Fortes

(HTML / JavaScript, yerleşim algoritmaları, tarayıcı teknolojileri, etkileşim tasarımı ve proje yönetimi alanlarında uzmanlaşan bir girişimci ve bilgisayar bilimcidir.)

 

“Hata ayıklamak, katil olduğun bir polisiye filmde aynı zamanda dedektif olmak gibidir.”

Fred Brooks

(Sistem mimarı, bilgisayar mühendisi ve bilgisayar bilimcidir. Çok kişi tarafından yazılımın kutsal kitabı kabul edilen “The Mythical Man‑Month”un yazarıdır.)

 

“Gecikmiş bir yazılım projesine insan gücü eklemek, tamamlanmasını daha da geciktirir.”

“İyi özellikler ve fikirler bir sistemin temel konseptiyle bütünleşmiyorsa onları hayata geçirmemek daha iyidir.”

“İnsanoğlu kusursuz olmaya alışkın değildir ve çok az sayıda insani faaliyet alanı bunu talep eder. Kusursuz olma gereğine uyum sağlamak, bana göre, programlamayı öğrenmenin en zor kısmıdır.”

“Akış çizelgelerini gösterip tabloları gizlersen, durum benim için gizemli olur. Eğer tabloları gösterirsen, genellikle akış çizelgelerine ihtiyacım kalmaz; durum apaçık ortadadır.”

“Başarıdan ziyade başarısızlıktan daha fazlasını öğrenebilirsiniz. Başarısızlık durumunda hangi parçanın çalışmadığını bulmak zorunda kalırsınız. Ancak başarıda, yaptığınız her şeyin harika olduğuna inanabilirsiniz, aslında bazı kısımlar hiç işe yaramamış olabilir. Başarısızlık sizi gerçeklerle yüzleşmeye zorlar.”

Fred Heath

(Yazılım geliştirme yaşam döngüsünün her aşamasında çalışmış; Ruby, Nim, Elixir, çevik metodolojiler, meta-programlama, davranış odaklı geliştirme, kavram ağları konularında uzmanlaşmıştır. Şu anda serbest bir full-stack yazılım geliştirici olarak çalışmakta, blog yazıları yazmakta ve konferanslara konuşmacı olarak katılmaktadır.)

 

“Bellek sızıntıları, su sızıntıları gibidir. En az beklendiklerinde meydana gelirler, yerlerini bulmak saatler sürer ve değerli eşyalarınızı muhafaza etmek için daha fazla zaman ayırmış olmayı dilersiniz.”

G

Glenford J. Myers

(Amerikalı bir bilgisayar bilimci, girişimci ve bilgisayar bilimleri üzerine sekiz tane ders kitabının yazarıdır. Mikroişlemci mimarisine önemli katkıları bulunmaktadır.)

 

“Problemi, tasarım sürecini aceleye getirerek çözmeye çalışıyoruz. Böylece, projenin sonunda, tasarım sürecini aceleye getirdiğimiz için ortaya çıkan hataları aramaya yeterli vaktimiz kalıyor.”

Grace Hopper

(Bilgisayar bilimi alanında öncü kabul edilmektedir ve Amerikan Donanması’nda bir tuğamiral olarak çalışmıştır. Harvard Mark I projesinde çalışan ilk bilgisayar programcılarından biridir. COBOL’u geliştirmeye yardım etmesi, ilk gerçek “bug”ı kaydetmesi ve ilk derleyiciyi icat etmesiyle tanınmaktadır.)

 

“Dildeki en zarar verici ifade: ‘Hep bu şekilde yapıldı.’dır. Şimdi size hayatınızın geri kalanında hep sizinle olacak bir hediye vereceğim. Bu ifadeyi her kullandığınızda hayaletim belirecek ve 24 saat boyunca size dadanacak.”

Grady Booch

(Amerikalı bir yazılım mühendisidir. Birleşik Modelleme Dilini (UML) geliştirmesiyle tanınmıştır. Ayrıca yazılım mimarisi, yazılım mühendisliği ve işbirliğine dayalı geliştirme ortamlarındaki yenilikçi çalışmaları ile uluslararası alanda da bilinirlik kazanmıştır.)

 

“İyi bir süreci olan iyi insanlar, her seferinde süreci olmayan iyi insanlardan daha iyi performans gösterir.”

“Amatör yazılım mühendisi her zaman bir sihir, uygulandığında yazılım geliştirmeyi önemsiz kılacak sansasyonel bir yöntem veya araç arayışı içindedir. Böyle bir mucizevi çözümün var olmadığını bilmek profesyonel yazılım mühendisinin işaretidir.”

“Yazılım geliştirme ekibinin görevi, basitlik yanılsamasını oluşturmaktır.”

Greg McKeown

(İngiliz bir konuşmacı, lider, iş stratejisti ve “Essentialism: The Disciplined Pursuit of Less“, “Multipliers: How the Best Leaders Make Everyone Smarter“ ve “Effortless: Make It Easier to Do What Matters Most” kitaplarının yazarıdır.)

 

“Özcülük nasıl daha fazlasını yapacağınızla ilgili değil, doğru şeyleri nasıl yapacağınızla ilgilidir. Bu, daha azını yapmış olmak için daha azını yapmak anlamına gelmiyor. Sadece gerçekten gerekli olanı yaparak en yüksek katkıyla çalışmak için zamanınıza ve enerjinize mümkün olan en akıllıca yatırımı yapmakla ilgilidir.”

“Özcülük, eklememiz gereken çabalara ve kaynaklara odaklanmak yerine, kaldırmamız gereken kısıtlamalara veya engellere odaklanır.”

Guido Van Rossum

(Python programlama dilinin yaratıcısıdır.)

 

“Python, programcıların ne kadar özgürlüğe ihtiyacı olduğuna dair bir deneydir. Çok fazla özgürlük olduğunda kimse diğerinin kodunu okuyamaz; çok az özgürlük olduğunda ise anlamlılık tehlikeye girer.”

“Değişmez bir şekilde, eğer dil iyiyse, dili kullananların onu asla gideceğini düşünmeyeceğiniz noktalara götürdüğünü görürsünüz.”

Gordon Bell

(MIT mezunu bir mühendistir ve dünyadaki ilk mini bilgisayarların yapımında öncü olmuştur.)

 

“Tüm büyük yazılımsal felaketler, çok fazla fikri alıp tek bir yere koymaktan kaynaklanır.”

H

Hans Hofmann

(Almanya doğumlu, Amerikalı öğretmen ve Soyut Dışavurumculuğu benimseyen bir ressamdır.)

 

“Sadeleştirme yeteneği, gerekli olan belli olsun diye gereksiz olanı elemek demektir.”

Henry Petroski

(Amerikalı bir inşaat mühendisi ve Duke Üniversitesi’nde tarih profesörüdür. Tasarım, başarı ve başarısızlık, mühendislik ve teknoloji tarihi konularında geniş çapta yazılar yazmıştır.)

 

“Yazılım sektörünün en hayret verici başarısı, donanım sektörünün istikrarlı ve şaşırtıcı kazanımlarını geçersiz hale getirmesidir.”

H. W. Kenton

(Ken Henderson’un “The Guru’s Guide to Transact-SQL” kitabında sıkça referans verilen bir isimdir. Kendisiyle ilgili bilgiye ulaşamadık.)

 

“Mühendislikte sanatsal bir unsur şüphesiz ki vardır. Fakat bir köprü yıkılarak 50 kişinin ölümüne sebep olduğunda, hiç kimse köprünün ne renk olduğu ile ilgilenmez.”

“İyi mühendislik, bir kodun 8 dakikada veya 8 saatte çalışması arasındaki farktır. Gerçek insanları gerçek yollardan etkiler. Tıpkı kuşların uçabilmesi gibi, bu da bir ‘fikir meselesi’ değildir.”

Hyrum Wright

(Google’da yazılım mühendisidir.)

 

“Bir API’nin yeterince kullanıcısı varsa, artık sözleşmede neler vadedildiğinin bir önemi yoktur; sisteminizin tüm gözlenebilir davranışları bir başkasına bağlı olacaktır.”

I

Ilan Goldstein

(Dünyaca tanınan bir Sertifikalı Scrum Eğitmeni’dir. Scrum ile çevikliklerini artırmak için start-up’lar, pazar liderleri ve kamu şirketleri ile çalışma konusunda geniş deneyimi vardır ve “Scrum Shortcuts Without Cutting Corners” kitabının yazarıdır.)

 

“Otomasyon olmadan Scrum, toprak pistte spor araba sürmek gibidir; tam potansiyeli tecrübe edemezsiniz, hayal kırıklığına uğrarsınız ve muhtemelen sonunda arabayı suçlarsınız.”

J

James Gosling

(Kanadalı bir bilgisayar bilimcidir. Genellikle “Dr. Java” olarak anılmaktadır ve Java programlama dilinin kurucusu ve baş tasarımcısı olarak bilinmektedir. Gosling, C++ ile tasarlamaya başladığı bir elektronik aletlerde gömülü sistem projesinin giderek hantallaşmaya başlayacağını farkedince, C++’nın en iyi özelliklerini alarak, daha az karmaşık bir söz dizimi ile kullanıcı dostu bir programlama dili yaratmak amacıyla Java üzerinde çalışmaya başlamıştır.)

 

“Java, C++’nın silah, sopa ve bıçaksız halidir.”

James Whittaker

(Amerikalı bir yazılım testçisi, unFIX modelinin yaratıcısı, girişimci ve “How Google Tests Software“, “The 7 Stages of Creativity: Developing Your Creative Self“ , “Exploratory Software Testing“ gibi kitapların yazarıdır.)

 

“Küçük testler kod kalitesine yol açar. Orta ve büyük testler ürün kalitesine yol açar.“

Jef Raskin

(Amerikalı bir insan-bilgisayar arayüzü uzmanıdır. 70’lerin sonlarında Apple’da Macintosh projesini tasarlaması ve başlatmasıyla tanınmıştır. “The Humane Interface” kitabının yazarıdır.)

 

“Bir projeyi uygulamaya, önce kullanıcının hedeflerine ulaşmak için ne yapacağını ve sistemin her bir kullanıcı davranışına nasıl cevap vereceğini adım adım listeleyerek başlayın.”

“Alanımız ‘ilerlemek’ ise; terminolojimizin, yaratıcılık ve estetikten vazgeçmeksizin anlaşılır olduğundan emin olmalıyız.”

“İyi tasarlanmış ve insancıl bir arayüz, başlangıç seviyesinde ve uzman seviyesinde alt sistemlere bölünmek zorunda değildir.”

“Bir arayüz, insan ihtiyaçlarına cevap veriyorsa ve insan zaaflarını dikkate alıyorsa insancıldır.”

Jeff Atwood

(Amerikalı bir yazılım geliştirici ve yazardır. Aynı zamanda, Stack Overflow’un kurucu ortağı ve programlama blog’u Coding Horror’un sahibidir.)

 

“ ‘Kafam karıştı, bunun dokümanları nerede?’ sorusuna en iyi cevap, daha fazla doküman yazmak değil, eklenen özelliği daha az kafa karıştıracak şekilde yeniden yazmaktır.”

“Yazılımcılar için optimize etmeyi bırakmalı ve kullanıcılar için optimize etmeye başlamalıyız.”

Jeff Bezos

(Amerikalı bir internet girişimcisi, sanayici, medya sahibi, yatırımcı, Amazon’un kurucusu ve CEO’sudur.)

 

“Müşteri tabanınız sizinle birlikte yaşlanıyorsa, sonunda eskimiş ya da konu dışı kalırsınız. Sürekli olarak yeni müşterilerinizin kim olduğunu ve genç kalmak için neler yapmanız gerektiğini öğrenmeniz gerekiyor.”

“Bir yenilik getirecekseniz, yanlış anlaşılmaya istekli olmalısınız.”

“Rakip odaklıysanız, rakip bir şey yapana kadar beklemeniz gerekir. Müşteri odaklı olmak, daha öncü olmanızı sağlar.”

Jeff Sutherland

(Scrum yazılım geliştirme sürecinin yaratıcılarından olan yazılım geliştiricidir. “Scrum’ın babası” olarak bilinmektedir. 2001 yılında “Agile Manifesto”nun yazılmasına katkıda bulunmuştur ve “Scrum Guide”ın yazarıdır.)

 

“Scrum, futboldaki kurallar gibidir. Sadece kuralları takip etmek sizi iyi bir oyuncu yapmaz.”

Jeff Weiner

(Linkedin’in CEO’sudur.)

 

“En iyi ürünler -neredeyse istisnasız olarak- bir şirketin stratejisini yerine getirme ihtiyacı sayesinde değil, bir sorunu çözmek isteyen ekipler sayesinde geliştirilir.”

Jeremy Keith

(Web geliştirici, müzisyen ve yazardır.)

 

“Unutmayın; web, kontrol ile ilgili değildir. Eğer sitenize gelen bir ziyaretçi, tarayıcının kendi formunu kullanmayı biliyorsa, widget’ınızın daha iyi göründüğünü düşünerek tarayıcı işlevini kendi widget’ınızla geçersiz kılarsanız, onlara herhangi bir iyilik yapmış olmazsınız.”

Jessica Gaston

 

“Birinin yazdığı berbat yazılım, başka birinin tam zamanlı işidir.”

Jessica Kerr

(Yazılım geliştirici, blog yazarı, konuşmacı; şu anda DevOps ve çevik dönüşüm danışmanlığı yapmaktadır.)

 

“Bir yazılım safsatası: Eğer çalışıyorsa ve hiçbir şeyi değiştirmezsek, çalışmaya devam eder.”

Jez Humble

(Amerikalı kod, altyapı ve ürün geliştirici, yazar.)

 

“Sistemleri dağıtırken uyulması gereken iki temel kural vardır. Birincisi, yeni özellik eklemenin tek seferde yalnızca bir servisi veya bileşeni değiştirmeyi gözettiğinden emin olun. Bu, arayüz karmaşasını azaltır. İkincisi, servisler arasında “konuşkan” veya hassas iletişimden kaçının. Konuşkan servisler ölçeklenmede başarısızdır ve test amacıyla taklit edilmeleri daha zordur.”

Jim Highsmith

(Amerikalı yazılım mühendisi veyazılım geliştirme metodolojisi üzerine pek çok kitabın yazarıdır. “Agile Manifesto”yu imzalayan kişilerden biridir ve Uyarlanabilir Yazılım Geliştirme (Adaptive Software Development) konseptinin yaratıcısıdır.)

 

“Bir projeyi daha çabuk tamamlamanın en iyi yolu daha erken başlamaktır.”

“Harika ürünler ortaya çıkarmak için, harika insanlara ihtiyacımız var. Harika insanları çekmek ve elimizde tutmak için, harika prensiplere ihtiyacımız var.”

“Yüksek performanslı ekiplerde liderler prensipleri, prensipler ekibi yönetir.”

“Çeviklik süreçten daha fazla tutum, metodolojiden daha fazla ortamla ilgilidir.”

“Basit kurallar yenilikçi, akıllı yanıtlara rehberlik eder. Kapsamlı kurallar ezbere, rutin yanıtlara rehberlik eder.”

“Herhangi bir işbirliği çabasından elde edilen sonuçların kalitesi, güven ve saygıya dayalıdır.”

“Çevik geliştirme, bir proje yaklaşımından ziyade bir ürün yaşam döngüsü yaklaşımını yansıtır.”

Jim McCarthy

(Yazar, açılış konuşmacısı ve Michele McCarthy ile birlikte Core Protocols’un ortak yaratıcısıdır. “Software for Your Head” ve “Dynamics of Software Development” kitaplarının yazarıdır. Bell Laboratuvarları, Whitewater Grubu ve Microsoft’ta çalışmıştır ve anlık mesajlaşma konusunda önemli bir patente sahiptir.)

 

“Harika bir ekip olmadan harika bir yazılıma sahip olamazsınız ve çoğu yazılım ekibi işlevsiz aileler gibi davranır.”

Joel Goldberg

(Amerikalı yazılımcı.)

 

“Takımlar güven hızında hareket eder. Birlikte çalışmak isteyeceğiniz güvenilirlikte biri olun.”

Joel Spolsky

(Amerikalı yazılım mühendisi ve yazar.)

 

“Biz programcıyız. Programcılar, içten içe mimar olduklarına inanırlar ve bir yere vardıklarında ilk yapmak istedikleri şey, orayı buldozer ile düzleştirip büyük bir şey inşa etmektir. Aşamalı tadilattan (basit tamir, iyileştirme, çiçek dikme gibi) heyecan duymazlar.”

John Backus

(Amerikalı bilgisayar bilimcidir ve FORTRAN’ı yaratan takımın başında yer almıştır. Aynı zamanda, Backus-Naur formunun (BNF) mucididir. Programlamaya matematiksel yaklaşımı savunan FP adlı fonksiyonel programlama dilini geliştirmiştir. 1994 yılında Draper Ödülü’nü almıştır.)

 

“Kendim de çok defa başarısız oldum ve öğrendim ki; eğer çok sayıda başarısızlığınız yoksa, muhtemelen yaratıcılığınızı yeterince kullanmıyorsunuz — hayal gücünüzü esnetmiyorsunuz.”

John Carmack

(Commander Keen, Wolfenstein 3D, Doom ve Quake gibi oyunları geliştiren takımın başında olan bilgisayar programcısı, oyunu geliştirici ve mühendistir.)

 

“Programlama bir rekabet oyunu değildir. Bir programcıya bildiğiniz bir şeyi öğretmek o bilgiyi sizden almaz.”

“Bir yazılıma yeni özellik eklemenin maliyeti, sadece kodlanması için gereken süre değildir; eklenen bir özellik yazılımın gelecekteki ilerlemesine engel de olabilir. İşin sırrı, birbiriyle savaşmayan özellikleri seçmektir.”

“Odaklanma, ne yapmayacağına karar verme meselesidir.”

“Odaklı ve sıkı çalışma başarının gerçek anahtarıdır. Gözlerinizi hedeften ayırmayın ve ona ulaşmak için adım atmaya devam edin. Bir şeyi ne şekilde yapacağınızdan emin değilseniz, her iki şekilde de yapın ve hangisinin işe yaradığını görün.”

John Cutler

(Kariyerine oyun geliştirici olarak başlayarak ürün yönetimi konusunda uzmanlaşmıştır. Ürün yönetimi konusunda kanaat önderi kabul edilmekte ve çok sayıda farklı kaynakta yazıları yayınlanmaktadır. Ürün yönetimi ile ilgili çıkardığı 50 dersi listelediği “50 Things I’ve Learned About Product Management” yazısı ile de tanınmaktadır.)

 

“Baktığınız yere doğru gitme eğilimi gösterirsiniz. Eğer rakibe çok fazla bakarsanız, önüne geçmek yerine ona doğru gidersiniz.”

“Şüpheniz varsa, düşünmeyi bırakın ve veri toplayın. Bir şeyler oluşturun ve test edin. Aynı şey sonsuz varsayımlar üzerinden ilerleyen toplantılar için de geçerlidir. Elinizi korkak alıştırmayın.”

“Birisi yeni bir özelliği kendi ortamında, günlük işlerinde, kendi verileriyle kullanmayı deneyene kadar hiçbir şeyden emin olamayız. Buradan gelecek geri bildirimle beraber tekrar gözden geçirmek için zaman bırakmalısınız.”

“Büyük bir jet uçağını, sürat teknesine indirmeye çalışmak asla iyi bir fikir değildir. Küçük parçalar halinde çalışın ve mümkün olan son anda karar verecek şekilde planlayın.”

“Tüm belirsizlikleri ortadan kaldırmak, özgünlüğün (ve yeniliğin) de ortadan kalkmasına yol açar.”

“Çöpünüzü diğer departmanlara aktardığınızda, örneğin ‘Destek konuyla ilgilenecektir’, sonuçta her zaman size geri döner.”

“Ürününüze dair güçlü bir vizyonunuzun olmaması, ürün stratejisini sizin yerinize şirketteki diğer kişilerin belirlemesiyle sonuçlanır.”

John Johnson

“İlk önce, sorunu çözün. Ardından kodu yazın.”

John Maeda

(Amerikalı yönetici, tasarımcı ve teknoloji uzmanı.)

 

“Sadelik, önemsiz olması beklenen ve normalde farkedilmeyecek olandan alınan umulmadık keyifle ilgilidir.”

John Ousterhout

(Amerikalı bilgisayar bilimi profesörü ve yazar.)

 

“Bir geliştirici olarak işiniz, yalnızca kolayca çalışabileceğiniz kod oluşturmak değil, başkalarının da kolayca çalışabileceği kodlar oluşturmaktır.”

“Her büyük tasarım kararı için birden fazla seçeneği göz önünde bulundurursanız, çok daha iyi bir sonuç elde edersiniz.“

John Romero

(Oyun endüstrisinde çalışan Amerikalı bir yönetmen, tasarımcı, programcı ve geliştiricidir. Wolfenstein 3D, Dangerous Dave, Hexen, Doom, Doom II ve Quake gibi oyunları ortaya çıkaran şirketin kurucu ortağı ve oyunların tasarımcısı olarak bilinir.)

 

“Programcıların sanatçı olduğunu düşünmüyor olabilirsiniz, ancak programlama aslında son derece yaratıcı bir meslektir. Mantık temelli yaratıcılık.”

John Warnock

(Amerikalı bir bilgisayar bilimci ve iş insanıdır. PostScript dilini icat etmiştir. En çok Adobe Systems Inc.’in kurucu ortağı olması ve baskı ve dizgide yarattığı devrimle bilinmektedir.)

 

“Programcının bir kod parçasını tıpkı kitabın kötü bir bölümü gibi görüp, ardına bakmadan hurdaya çıkarabilmesi çok önemlidir. Asla tek bir fikre sevdalanmayın, asla gerektiğinde onu atamayacak kadar inatla birşeye tutunmayın.”

“Büyük deneyler yerine küçük deneylerden öğrenin. Ortaya hiçbir şeyin çıkmadığı 2 yıllık bir geliştirmeye girmeyin. Her 2 ayda bir ortaya birşeyler çıkarın; böylece değerlendirip, düzeni değiştirip, yeniden başlayabilin.”

“Başarılı olmak için, etrafınızı yetenekleri birbirine uyumlu olan çok yetenekli insanlarla  kuşatın. Başarının sırrı budur.”

John F. Woods

(Hakkında, Eylül 1991’de comp.lang.c ++ haber grubuna gönderdiği e-posta dışında bir bilgi bulamadığımız bir oyun programcısıdır.)

 

“Her zaman, yazdığınız kodu devam ettirecek kişi nerede yaşadığınızı bilen vahşi bir psikopatmış gibi kod yazın.”

Joshua Bloch

(Amerikalı bir yazılım mühendisidir. Java üzerine aralarında “Effective Java” nın da yer aldığı pek çok kitabı yayımlanmıştır. Java Collections çatısı, java.math paketi, assert mekanizması dahil olmak üzere çok sayıda Java platformu özelliğinin tasarımına ve uygulanmasına liderlik etmiştir.)

 

“Dil seçerken, aslında seçtiğiniz teknik fayda setinden fazlasıdır. Bir topluluk seçersiniz.”

K

Kathryn Barrett

(12 yaşından itibaren kendi kendine kodlamayı öğrenerek şu anda Kanada’da Learning Labs’da -Ladies Learning Code, Girls Learning Code, Kids Learning Code ve HackerYou gibi oluşumların tanıtımını yapan kurum- çocuklara kodlama öğretmektedir.)

 

“Koda aşık olmak, problem çözmeye aşık olmak ve sürekli devam eden bir sohbetin parçası olmak demektir. Bilgisayar programcısı olmak tecrit ve yalnızlık içinde yaşamanın tam tersidir.”

Karolina Szczur

(Tasarımcı ve önyüz geliştiricidir. 2015 yılında “On writing maintainable front-end systems” makalesini yazmıştır.)

 

“Bir yazılımı, onu kavraması gereken tek kişi bizmişiz gibi yazmak, yapılabilecek en büyük hatalardan ve yanlış varsayımlardan biridir.”

Kelsey Hightower

(Güçlü bir açık kaynak savunucusudur. Teknoloji alanındaki kariyeri boyunca teknik destekten, yazılım geliştirmeye veya sistem yöneticiliğine kadar mümkün olan her şapkayı takmış ve çeşitli liderlik rollerinde yer almıştır. Kubernetes üzerine “Kubernetes: Up and Running: Dive into the Future of Infrastructure” adında bir kitabı vardır. Son olarak Google Cloud’da “Staff Developer Advocate” – Geliştirici Savunucusu – rolünde çalışmaktadır.)

 

“Açık kaynaklı bir projeyi sürdüren kişi olmak, tüm biletlerin ücretsiz olduğu ve çoğu müşterinin memnuniyet anketlerine uçağın nasıl uçurulacağına dair önerilerini yazdığı bir havayolunda uçuş görevlisi olmak gibidir.”

Kent Beck

(Amerikalı bir yazılım mühendisi ve çevik yazılım geliştirme metodolojilerinden Extreme Programming’in (Aşırı Programlama) yaratıcısıdır. Aynı zamanda “Agile Manifesto”nun 17 orijinal imzacısından biridir ve yazılım tasarım desenlerinin öncüsü olarak tanınmaktadır.)

 

“Ben harika bir programcı değilim. Harika alışkanlıklara sahip iyi bir programcıyım.”

“Programlama becerisi empati ile başlar; biçimlendirme, yazılım dilleri, araçlar, algoritmalar veya veri yapılarıyla değil.”

“İyimserlik, programlama için mesleki bir tehlikedir; tedavisi geri bildirimdir.”

“Testler, programcının korkuyu can sıkıntısına dönüştüren taşıdır.”

“Yazılımdaki her şey değişir. Gereksinimler değişir, tasarım değişir, iş değişir, teknoloji değişir, takım değişir, ekip üyeleri değişir. Sorun değişim değil, çünkü değişim olacak; sorun, daha çok, değişimle baş edemememizdir.”

“Okuyucuların programları ayrıntılı ve konsept olarak anlamaları gerekir. Bazen detaydan konsepte, bazen konseptten detaya geçerler.”

Kevlin Henney

(Danışman ve eğitmendir. Örüntüler, mimari, programlama teknikleri konularına odaklanmıştır.)

 

“İki olası çözüm olduğunda, genel olmasıyla övünen daha karmaşık olandan ziyade daha basit ve somut ihtiyaca dayalı olanı tercih edin.“

L

Larry Bernstein

(Yazılım mühendisliği profesörüdür ve NJCSE’de yazılım mimarisi dersi vermektedir. Bell Labs’da 35 yıl büyük yazılım projelerini yönetmiştir.)

 

“Disiplinsiz bir iş akışını otomatikleştirmeyin. Bilgisayar, müşterinizdeki yöneticilerin yapamadığı şeyleri çözemez.”

Larry Bossidy

(Amerikalı yazar ve emekli iş adamıdır. 1990’larda AlliedSignal’ın (daha sonra Honeywell) CEO’su olarak görev yapmıştır. Daha öncesinde de General Electric’teki yönetici pozisyonlarında 30 yılı aşkın görev almıştır.)

 

“Karmaşıklığın zeka ile ilgisi yoktur, sadeliğin vardır.”

“Davranışı değiştirmenin temeli, ödülleri performansla ilişkilendirmek ve bağlantıları şeffaf hale getirmektir.”

“Bir bilgisayarın donanımı, doğru yazılım olmadan bir işe yaramaz. Benzer şekilde, bir organizasyonda donanım (strateji ve yapı) yazılım (inançlar ve davranışlar) olmadan durağandır.”

Larry Constantine

(Yazılım mühendisi ve Madeira Üniversitesi Matematik ve Mühendislik Bölümü’nde profesördür. Yazılım bilimi ve kurum kültürü hakkında pek çok yayını vardır. Ayrıca yapısal yazılım tasarım metodolojilerinin öncülerinden biri olarak kabul edilmektedir ve karmaşık sistemlerde etkileşim tasarımı ve kullanılabilirlik üzerine uzmanlaşmıştır.)

 

“En iyi toplantılar, gerçekten iş bitirici olanlardır. Çalışanlarınız toplantılarınızın gerçekten bir işe yaradığını fark ettiklerinde, başka yerde bulunmak için bahane üretmeyi bırakırlar.”

Larry Flon

(Amerikalı bilgisayar bilimi profesörüdür.)

 

“Şimdi de, herhangi bir zamanda da, kötü program yazmayı zorlaştıran hiçbir programlama dili olmadı ve olmayacak.”

Larry Wall

(Perl programlama dilinin yaratıcısıdır.)

 

“Bir programcının 3 erdemi vardır: Tembellik, sabırsızlık ve aşırı özgüven.

Tembellik: Toplam enerji tüketimini azaltmak için büyük çaba harcamanızı sağlayan özellik. Diğer insanların yararlı bulacağı emek tasarrufu sağlayan programlar yazmanızı ve yazdıklarınızı belgelemenizi sağlar, böylece bu konuda çok fazla soruya cevap vermek zorunda kalmazsınız.

Sabırsızlık: Bilgisayar yavaşladığında hissettiğiniz öfke. Bu, yalnızca gereksinimlere yanıt vermeyen, aynı zamanda bunları öngören, ya da en azından öyle davranan, programlar yazmanızı sağlar.

“Aşırı özgüven: Başkalarının, hakkında kötü şeyler söylemek istemeyeceği programlar yazmanızı (ve sürdürmenizi) sağlayan özellik.”

“Bilgisayar dilleri neyi mümkün kıldıklarına göre değil, neyi kolaylaştırdıklarına göre farklılık gösterirler.”

Larry Tesler

(1980 ile 1997 yılları arasında Apple’da görev almış ve bilgisayarlardaki “Cut-Copy-Paste” komutlarının mucidi olarak tanınan bilgisayar bilimcidir.)

 

“Her uygulamanın kendine özgü doğal bir karmaşıklığı vardır. Tek soru, bu karmaşayla kullanıcının mı, uygulama geliştiricinin mi, yoksa platform geliştiricinin mi uğraşmak zorunda kalacağıdır.”

Laurence J. Peter

(Kanadalı bir eğitimci ve yazardır. En yaygın şekilde hiyerarşi konusunda geliştirdiği “Peter prensibi” ile tanınmaktadır. 1982’de “Peter’s Almanac”ı yayınlamıştır.)

 

“Bazı problemler o kadar karmaşıktır ki; onlar hakkında kararsız olmanız için bile oldukça zeki ve bilgili olmanız gerekir.”

Linus Torvalds

(Yazılım mühendisi ve Linux kernel’in yaratıcısıdır.)

 

“En iyi programcıların çoğu, programlamayı ücret almayı umarak ya da halk tarafından kabul edilmeyi bekleyerek değil, eğlenceli olduğu için yaparlar.”

“Teori ve pratik bazen çatışır. Ve bu olduğunda, teori kaybeder. Her seferinde.”

“İnsanlara ‘onu yapma’ demek- eğer kolayca yapabiliyorlarsa- işe yaramaz. Düzeltmeye teşvik edecek seviyede bir ağrı olmadıkça işler gerçekten düzelmez.”

Lisa Crispin

(Çevik metodolojiler ve test üzerine uzmanlaşmıştır, dört kitabı bulunmaktadır. Test topluluğunun DevOps ve sürekli teslimat (CD) hakkında bilgi edinmesine, çevik ve DevOps topluluklarının testler hakkında bilgi edinmesine ve en iyi uygulamaların yayılmasına uğraşmaktadır.)

 

“Metodolojiler veya araçlar değil, insanlar projeleri başarılı kılar.”

Louis Srygley

(30+ yıllık yazılım kariyeri vardır. Aynı zamanda yapımcılık ve oyunculuk yapmaktadır.)

 

“Gereksinimler veya tasarım olmadığında, programlama boş bir metin dosyasına hata ekleme sanatıdır.”

M

Marc Donner

(Amerikalı bilgisayar bilimcidir. Robotik alanında doktorası bulunmaktadır. IBM Watson Araştırma Merkezi, Google, Uber gibi firmalarda çalışmıştır.)

 

“Programlama hatalarımın %80’i sözdizimi hataları, kalan %20’nin %80’i önemsiz mantık hataları, kalan %4’ün %80’i gösterici hatalarıdır. Ve geriye kalan %0,8 zordur.”

Mario Fusco

(İtalyan yazılım mühendisi ve Java uzmanıdır. Aynı zamanda “Java 8 in Action: Lambdas, Streams, and Functional-style Programming” kitabının yazarı ve “Modern Java in Action” kitabının ortak yazarıdır. Şu anda Red Hat’te “Drools Core Developer” olarak çalışmaktadır.)

 

“Yazdığınız kod sizi programcı yapar. Sildiğiniz kod sizi iyi bir programcı yapar. Yazmanız gerekmeyen kod sizi harika bir programcı yapar.”

“Bazen bir hata çok büyüktür ve siz detaylara o kadar çok odaklanırsınız ki; onu ortaya çıkarmak, mikroskopla fil aramak gibidir. Geriye doğru bir adım atın.”

“İnsanlar gibi programlar da yaşlanır. Yaşlanmanın önüne geçemeyiz; ancak nedenlerini anlayabilir, etkilerini sınırlayabi-lir ve zararın bir kısmını tersine çevirebiliriz.”

“Düşük gecikme süresi için optimize edebilirsiniz. Yüksek çıktı oranı için optimize edebilirsiniz. Bellek kullanımı için optimize edebilirsiniz. Yine de, durumların %90’ında optimize etmeyi amaçla- manız gereken en kıymetli şey sürdürülebilirliktir.”

Mark Berry

(Yazılım mühendisi ve girişimcidir.)

 

“Yazılım geliştiriciler, rüzgara göre yön değiştiren yönergeler ve ürünün müşteriye ulaşmaması yüzünden tükenmişlik yaşarlar; işlerin zorluğundan dolayı değil.”

Mark Fewster

(Yazılım testi alanında 20 yıldan fazla sektörel deneyimi vardır. Test teknikleri ve test otomasyonu alanında danışman, eğitmen, yazar ve konuşmacı ve “Software Test Automation” kitabının ortak yazarıdır.)

 

“Kötü testlerin verimliliğini artırmak yerine, önce testleri daha etkili hale getirmek gerekir. Çünkü kaosu otomatikleştirmek sadece kaosun daha da hız kazanmasına sebep olur.”

Martin Fowler

(Nesne odaklı analiz ve tasarım, UML, örüntüler ve aşırı programlama da dahil olmak üzere çevik yazılım geliştirme metodolojileri konusunda uzmanlaşmış, İngiliz bir yazılım geliştirici, yazar ve yazılım geliştirme üzerine uluslararası bir konuşmacıdır. Aralarında “Refactoring”in de bulunduğu pek çok kitabı vardır.)

 

“Eğer bir şeyi değiştirmekten korkuyorsanız, belli ki o şey kötü tasarlanmıştır.”

”Ne zaman bir kodun ne yaptığını anlayabilmek için düşünmem gerekse, kendime ‘Daha çabuk anlaşılabilmesi için bu kodu yeniden düzenleyebilir miyim?’ diye sorarım.”

”Sezgisel olarak, koda açıklama yazma ihtiyacı hissettiğimizde bunun yerine bir metot yazarız.”

”Bugünün işini bugünden bitirebiliyorsanız; ancak bunu, yarının işlerinin muhtemelen yarın bitmeyeceği şekilde yapıyorsanız, kaybedersiniz.”

”Kod düzenleme için ayrıca zaman ayırmaya karşıyım. Bence kod düzenleme, ayrıca zaman ayırdığınız bir etkinlik değil, küçük atışlar halinde her zaman yaptığınız bir şeydir.”

“Bir programa bir özellik eklemeniz gerektiğini ve program kodunun bu özelliği eklemek için uygun bir şekilde yapılandırılmadığını fark ettiğinizde, özelliği eklemeyi kolaylaştırmak için önce programı yeniden düzenleyin, ardından özelliği ekleyin.”

Mary Poppendieck

(Kariyerine süreç kontrol programcısı olarak başlamış, bir üretim tesisinin BT departmanını yönetmiş ve ardından ürün geliştirme alanına yönelerek “Lean Software Development” konusunda aralarında “Implementing Lean Software Development: From Concept to Cash” kitabının da bulunduğu dört kitap yazmıştır.)

 

“Her kod satırı yazılmak için paraya ve desteği için daha da fazla paraya mal olur. Geliştiricilerin gerekmeyecek kod yazmaktansa internette gezinmeleri daha iyidir.”

“Yazılım temelli sistemlerin başarısız olmasının en büyük nedeni teknik eksiklik değil; yanlış şeyi inşa etmektir.”

“İyi yazılım mimarisi hakkında bildiğimiz neredeyse her şey, değiştirmesi kolay bir yazılım yapmakla ilgilidir.”

“Akıllıca kararlar verecek ustalıktaki insanları geliştirmek, insanlar yerine düşündüğünü iddia eden karar verme süreçleri geliştirmekten daha önemlidir.”

“İşleri yerleşik takımlara atamak, projeler etrafında yeni takımlar oluşturmaktan daha iyidir.”

“Problem çözmeye disiplinli bir yaklaşım, bir ekibin safça hayaller kurmak yerine yeni bilgiye, belirlenmiş karşı önlemlere ve kalıcı sonuçlara ulaşmasını sağlar.”

“Testlerin ve testleri geliştirip çalıştıran kişilerin işi, kusurları bulmak değil, kusurları önlemektir.”

“Algılanan bütünlük vizyonu düzenli olarak yenilenmezse, mühendisler teknik ayrıntılarda kaybolma ve müşteri değerlerini unutma eğilimi gösterirler.”

Max Kanat-Alexander

(Google’da yazılım mühendisi ve ‘Code Simplicity’ kitabının yazarıdır.)

 

“Gerçekten de, bazı programlar en iyi kağıt üzerinde yazılır. Bilgisayara taşımak sadece küçük bir ayrıntıdır.”

“Kodunuzu basitleştirmek, bakım çabasını azaltır, böylece her olası değişikliğin istenebilirliğini artırır.”

Melinda Varian

(Programcı ve Princeton Üniversitesi’nde akademisyendir. IBM’in sanal makine işletim sistemi VM’in tarihi üzerine çalışmaları ve makaleleri bulunmaktadır.)

 

“En iyi programlar, programcının başka bir şey üzerinde çalışması gerekirken yazılmış olanlardır.”

Mich Ravera

(Yazılım geliştirici ve yayıncıdır.)

 

“Eğer çalışmıyorsa, ne kadar hızlı çalışmadığının bir önemi yoktur.”

Michael Feathers

(Yazılım ve organizasyon tasarımı konusunda uzmanlaşmış ve son 20 yılda yüzlerce kuruluşa genel yazılım tasarımı, süreç değişikliği ve kod canlandırma konularında danışmanlık desteği vermiştir. “Working Effectively With Legacy Code” kitabının yazarıdır.)

 

“Unutmayın; kod sizin eviniz ve içinde yaşamak zorundasınız.”

“Acımasız gerçek şudur ki; mimari sadece birkaç kişiye bırakılmayacak kadar önemlidir. Koda dokunan herkes mimariyi bilmeli ve bir başkasının öğrendiklerinden de fayda sağlayabilmelidir.”

“Testsiz kod, kötü koddur. Ne kadar iyi, ne kadar güzel, ne kadar nesne yönelimli veya iyi kapsüllenmiş olduğu önemli değildir. Kodun davranışını ancak testle hızlı ve doğrulanır şekilde değiştirebiliriz. Diğer türlü, kodun iyiye mi kötüye mi gittiğini gerçekten bilemeyiz.”

“Temiz kod her zaman umursayan biri tarafından yazılmış gibi görünür.”

“Bakımlı bir sistemde, değişikliğin nasıl yapılacağını bulmak biraz zaman alabilir, ancak bir kez yaptığınızda, değişiklik genellikle kolaydır ve sistemle çok daha rahat hissedersiniz. Eski bir sistemde, ne yapılması gerektiğini anlamak uzun zaman alabilir ve değişim de zordur.”

Michael Hartung

(Uzun yıllar IBM’de çalışmış bir bilgisayar donanım uzmanıdır. 2002’de “IBM Fellow” ünvanını almıştır.)

 

“Donanım, eninde sonunda bozulur. Yazılım, eninde sonunda çalışır.”

Michael A. Jackson

(İngiliz bilgisayar bilimci ve bilgi işlem danışmanıdır. Aynı zamanda İngiltere’de Open University’de misafir araştırma profesörü ve çok sayıda kitabın yazarıdır.)

 

“Optimizasyonla ilgili 2 kural var:

Kural 1: Yapma.

Kural 2: (yalnızca uzmanlar için) Henüz yapma. Tamamıyla net ve optimize edilmemiş bir çözüm bulana kadar bekle.

Michael Lopp

(Amerikalı bir yazılım mühendisliği yöneticisi, “Rands“ lakabıyla tanınan bir blog yazarı ve “The Art of Leadership: Small Things, Done Well“, “Managing Humans: Biting and Humorous Tales of a Software Engineering Manager“ ve “Being Geek: The Software Developer’s Career Handbook“ kitaplarının yazarıdır.)

 

“Bir yazılım metaforu, bir yol haritasından çok bir projektör gibidir. Size cevabı nerede bulacağınızı söylemez; nasıl arayacağınızı söyler.”

Michael Nygard

(Amerikalı yazılımcı, mimar ve yazardır.)

 

“Bir sistem yaratırken, yalnızca amaçlanan etkilerini düşünmeyin; rakip gibi düşünün. Nasıl kötüye kullanılabilir? Bu size çok farklı bir yaklaşım getirecektir.”

Mike Cohn

(Scrum’ın gelişmesine katkıda bulunmuştur. Scrum Alliance’ın kurucularından biridir. Çevik metodoloji üzerine kitapları vardır. Günlük stand-up toplantılarını ortaya çıkaran kişidir.)

 

“Bir ekibin kendi kendini organize etmesine imkan vermenin anlamı, yöneticinin gözünden kaçan ideal yapıyı ekibe buldurmak değil; ekibi problemi tamamen sahiplenmeye teşvik etmektir.”

“Her bir özelliğin tahmini, diğer özelliklerin tahminlerine göre yapıldığından, tahminlerimizin doğru veya yanlış olması önemli değildir. Önemli olan tutarlı olmalarıdır.”

“Bireylere takım çalışması için mümkün olan her türlü teşvik verilmelidir. Başkasına yardım etmem takımın iş çıktısını artıracaksa, yapmam gereken budur.”

Mike Krieger

(Brezilyalı-Amerikalı girişimci, yazılım mühendisi ve Instagram ortak kurucusudur.)

 

“Bir ürünü, sadece geliştirme yaparak inşa edemezsiniz; neden inşa ettiğinizi bilmeniz gerekir. Öğleden sonralarınızı bir eskiz defteri ile geçirerek veya fikirlerinizi başkalarıyla konuşarak, geliştirme zamanından bir yıl kazanabilirsiniz.”

Mikko Hypponen

(Finlandiyalı bir global bilgisayar güvenliği ve gizlilik uzmanı ve köşe yazarıdır. Nesnelerin interneti güvenliği konusundaki Hypponen Yasası ile tanınmaktadır.)

 

“Gerçekleşmemiş bir felaketi önlemek için yaptığı çalışmalar nedeniyle birine nadiren teşekkür edilir.”

Milt Bryce

(Bilişim sistemleri uzmanıdır.)

 

“Hiçbir mükemmel programlama veya teknoloji, yanlış açıklanmış veya baştan anlaşılmamış bir sorunu çözemez.”

N

Neal Ford

(Üniversite eğitimini diller ve derleyiciler konusunda uzmanlaşan bir bilgisayar bilimci ve istatistiksel analiz alanında uzmanlaşan bir matematikçi olarak tamamlamıştır. Günümüzde özellikle çevik mühendislik teknikleri ve yazılım mimarisi konularında uzman olarak tanınmaktadır. Yazılım mimarisi, sürekli dağıtım, fonksiyonel programlama gibi konularda pekçok makale, kitap ve video sunumu vardır.)

 

“Yeni bir programlama paradigması öğrenmenin zor kısmı yeni bir söz dizimi öğrenmek değil, farklı şekilde düşünmeyi öğrenmektir.”

Nicole Forsgren

(Amerikalı teknoloji yöneticisi, girişimci ve yazardır.)

 

“Architects should collaborate closely with their users—the engineers who build and operate the systems through which the organization achieves its mission—to help them achieve better outcomes and provide them the tools and technologies that will enable these outcomes.”

“Bir ekip liderinin sorumlulukları arasında, süreçteki işi sınırlamak ve işlerini yapabilmeleri için ekibin karşısındaki engelleri ortadan kaldırmak yer alır.“

Nicoll Hunt

(20+ yıllık bir yazılım geçmişi vardır. Ağırlıklı olarak oyun geliştirme alanında çalışmış ve Fist Of Awesome, Shirtless Bear-Fighter, Maximum Car, 8-Bit Waterslide gibi oyunları geliştirmiştir.)

 

“Herhangi bir projenin ilk adımı, onun karmaşıklığını ve zorluğunu fena şekilde küçümsemektir.”

Niklaus Wirth

(İsviçreli bir bilgisayar bilimci olarak Pascal da dahil olmak üzere birçok programlama dili tasarlamış ve yazılım mühendisliğinde klasik konuların öncülüğünü yapmıştır.)

 

“Karmaşıklığın asıl nedeni; yazılım satanların, kullanıcıların istediği tüm özellikleri sorgulamadan kabul etmeleridir.”

Nitin Borwankar

(20 yıllık sektör deneyimine sahip bir veritabanı uzmanıdır.)

 

“Özgeçmişinizi gereksinimlerin önüne koymayın.”

Norm Schryer

(Bilgisayar bilimci ve AT&T Broadband Services Research başkanıdır.)

 

“Kod ve açıklama birbiriyle uyuşmuyorsa, büyük olasılıkla her ikisi de yanlıştır.”

Norman Ralph Augustine

(Havacılık ve uzay alanında çalışmış ve “İnsanlı Uzay Uçuşları Planlama Komitesi”nin başkanlığını yapmış ünlü bir iş adamıdır. 1984 yılında “Augustine’s Laws” listesini yayımlamıştır.)

 

“Yazılım entropi gibidir. Kavramak zordur, ağırlığı yoktur ve termodinamiğin 2. yasasına uyar; yani, her zaman artar.”

O

Oscar Godson

(Yazılım geliştirici ve girişimcidir.)

 

“Sahip olabileceğiniz en iyi programlama becerilerinden biri, ne zaman bir süre uzaklaşacağınızı bilmektir.”

P

Pamela Zave

(Yazılım gereksinim mühendisliği, telekomünikasyon hizmetleri, protokol modellemesi ve doğrulaması konusundaki çalışmaları ile tanınan Amerikalı bilgisayar bilimcidir. Şu anda Princeton Üniversitesi’nde ağ mimarisi üzerinde çalışmaktadır.)

 

“Yazılım mühendisliğinin amacı karmaşıklığı kontrol etmektir, onu yaratmak değil.”

Patrick Collison

(İrlandalı girişimci ve Stripe’ın kurucu ortağı.)

 

“Programlama tuhaf fikirlerle doludur. Daha kısa, daha az açıklayıcı adlar kullanmak, genellikle genel olarak daha okunaklı kodlar üretir. En güçlü diller genellikle daha az olanlardan çok daha az kavrama sahiptir. Başarısız olmak, başarılı ve özgün işler üretmenin en iyi yolu olabilir.”

Patrick McKenzie

(Yazılım mühendisi ve girişimcidir. Aynı zamanda programcılık ve yazılım pazarlaması hakkında pek çok makalesi vardır.)

 

“Tanıdığınız her büyük yazılım geliştirici, nasıl çözüleceğini bilmediği problemleri çözerek şimdi bulunduğu yere geldi.”

Paul Butcher

(Kariyerine çocukluğunda 8-bit ev bilgisayarları için oyun yazarak başlayarak, o zamandan beri, bit dilim işlemcilerdeki mikro koddan, yüksek seviyeli bildirime dayalı programlamaya tüm soyutlama seviyelerinde çeşitli alanlarda çalışmıştır. “Debug It!” kitabının yazarıdır.)

 

“Hata ayıklama genellikle kodu yeniden düzenleme fırsatlarını ortaya çıkarır. Hata içeren bir kodla çalıştığınız gerçeği, kodun daha anlaşılır veya daha iyi yapılandırılmış olma şansı olduğunu gösterir.”

Paul Graham

(Amerikalı bilgisayar bilimci, girişimci ve yazar.)

 

“Hataları erken yakaladığınızda, aynı zamanda daha az bileşik hatanız olur. Bileşik hatalar, etkileşime giren iki ayrı hatadan oluşur; merdivenden inerken tökezlersiniz, trabzanı tutmaya çalıştığınızda o da elinizde kalır.”

“Bir programlama dili, önceden düşündüğünüz programları ifade etmeniz için değil, programları düşünmeniz içindir.”

“İyi yazılımın içine bakarsanız, kimsenin görmesi gerekmeyen parçaların da güzel olduğunu görürsünüz. Harika olduğumu iddia etmiyorum. Ancak kod söz konusu ise, günlük hayata aynı şekilde yaklaşırsam beni reçeteli ilaçlara elverişli hale getirecek şekilde davrandığımı biliyorum. Kötü şekilde girintili veya çirkin girişken adları kullanılan bir kod görmek beni çıldırtıyor.”

“Kullanıcıların sevdiği bir şey oluşturmanız için ipucu: Kendiniz kullanmak isteyeceğiniz temiz ve basit bir şey yaparak başlayın.”

“Olayları kullanıcının bakış açısından görebilmeniz gerekir.”

“Tasarım ve araştırma aynı hedefi hedefliyor, sadece farklı yönlerden yaklaşıyor.”

Pearl Zhu

(Yazılım geliştirici ve yazardır.)

 

“Çevik’te gelişmiş üretkenlik görmenin nedenlerinden biri basitlik ilkesinden kaynaklanmaktadır.”

Peter Roizen

(Kanadalı yazılım geliştirici, oyun yaratıcısı ve girişimcidir.)

 

“Zeki ama pratik olmayan pek çok insan gördüm. Faydasız akademik hedeflerin peşinde kayboluyorlar. Pratik olmak, iyi programlama için önemlidir. Bir projenin ne kadar süreceğini, o sürede neyin yapılıp yapılamayacağını hesap edebilmeli; başka şeyler yapma arzunuza karşı koyarak projeyi tamamlamalısınız.”

R

Radia Perlman

(Amerikalı bir bilgisayar programcısı ve network mühendisidir. STP’yi — Spanning-Tree Protocol — icat etmesiyle “internetin annesi” olarak tanınmıştır. Network tasarımı ve standardizasyonunun diğer alanlarına da büyük katkıları olmuştur.)

 

“Daha fazla mühendis benim gibi teknolojiden nefret etse, dünya daha iyi bir yer olurdu. Eğer başarırsam, tasarladığım şeyleri kimse fark etmeyecek; sadece işlerini yapıp, kendi kendilerini yönetecekler.”

Ralph Johnson

(Bilgisayar bilimi araştırmacısı ve “Design Patterns: Elements of Reusable Object-Oriented Software” kitabının yazarlarındandır.)

 

“Bir yazılım, yeniden kullanılabilir olmadan önce, kullanılabilir olmalıdır.”

Rasmus Lerdorf

(PHP programlama dilinin yaratıcısıdır.)

 

“PHP diş fırçanız kadar heyecan vericidir. Her gün kullanırsınız, işinizi görür, basit bir araçtır, yani? Kim diş fırçaları hakkında okumak ister ki?”

Ray Ozzie

(Eski Microsoft CTO’su, yazılım mimarı ve aynı zamanda girişimcidir.)

 

“Karmaşıklık öldürür. Geliştiricilerin canına okur; ürünleri planlamayı, inşa etmeyi ve test etmeyi zorlaştırır, güvenlik sorunları ortaya çıkarır, son kullanıcı ve sistem yöneticisi için hayal kırıklığına neden olur.”

“Hatalar genellikle alt sistemler arasındaki kötü ilişkinin bir özelliği ve çoğunlukla insanların onları tasarlarken yetersiz iletişim kurmasının sonucudur. Bir hata bulunca, onu alt sistem içinde ele alma ve programa bir bütün olarak bakmama eğilimi vardır.”

Rebecca Parsons

(Amerikalı bilgisayar bilimi profesörü ve ThoughtWorks’ün Baş Teknoloji Sorumlusudur.)

 

“Performansı düşünmek için hiçbir zaman çok erken değildir.”

Richard Dalton

(İrlandalı deneyimli bir yazılım geliştirici, eğitmen ve mentordur.)

 

“Takımlar değişmezdir. Biri ayrıldığında veya katıldığında, her defasında, değişen bir takımınız değil, yeni bir takımınız olur.”

Richard Kenneth Eng

(30+ yıllık yazılım geçmişi olan ve çok çeşitli dillerde ve alanlarda programlama yapmış Kanadalı yazılım geliştiricidir.)

 

“Mümkün olan her zaman, daha basit olan programlama dilini tercih edin. Karmaşık diller, beyninizdeki bilişsel yükü arttırır. Basit dillerin, güç veya ifade açısından bir eksiği yoktur.”

Richard Monson-Haefel

(Kıdemli yazılım mühendisi ve bağımsız danışmandır. O’Reilly ve Pluralsight’ta kitapları yayımlanmaktadır.)

 

“Mimariyi siz yönlendirmezsiniz, gereksinimler yönlendirir.”

“Tasarım bir keşif sürecidir. Uygularken, genellikle önceden bilinmesi imkansız olan yeni bilgileri keşfederiz.”

Richard E. Pattis

(Bilgisayar bilimleri alanında profesördür, Karel programlama dilini ortaya çıkarmıştır ve şu anda Kaliforniya Üniversitesi’nde programlamaya giriş ve veri yapıları üzerine ders vermektedir.)

 

“Hata ayıklarken, yeni başlayanlar düzeltmek için kod ekler; tecrübeliler ise kusurlu kodu kaldırır.”

“Kod sadece gerektiği kadar hızlı çalışmalı, gerekenden daha hızlı olmamalıdır. Çünkü hızı artırmak için mutlaka başka önemli bir şey feda edilir.”

“Eğer bir programın yapısını duştayken uçtan uca idrak edemiyorsanız, henüz onu kodlamaya hazır değilsinizdir.”

“Bir yazılım sisteminin yapısı, kodun doğduğu, olgunlaştığı ve öldüğü ekolojiyi sağlar. İyi tasarlanmış bir yaşam alanı, bir yazılım sisteminde ihtiyaç duyulan tüm bileşenlerin başarılı şekilde gelişmesine imkan verir.”

Richard Stallman

(Amerikalı özgür yazılım hareketi aktivisti ve programcısı.)

 

“Yaratıcılık toplumsal bir katkı olabilir, ancak toplum sonuçları kullanmakta özgür olduğu sürece.”

Rick Lemons

(20+ yıldır yazılım analizi, mimarisi, uygulaması ve yönetimi üzerine çalışmakta ve danışmanlık vermektedir.)

 

“Kullanıcınızdan, sistemin zaten bildiği bilgileri size tekrar sunmasını istemeyin.”

Rob Pike

(Kanadalı programcı ve yazardır.)

 

“Veri üstündür. Doğru veri yapılarını seçerek iyi organize ettiyseniz, algoritmalar neredeyse her zaman apaçık olacaktır. Programlamanın merkezi algoritmalar değil, veri yapılarıdır.”

Robert C. Martin

(Yazılım tarihinde büyük öneme sahip olan Amerikan yazılım mühendisi ve eğitmenidir. Uncle Bob olarak da bilinir. En fazla “The Clean Code” kitabı, Agile Manifesto ve SOLID Prensipleri ile tanınmaktadır.)

 

“Çoğu yönetici, zaman çizelgesini ve isterleri tutkuyla savunabilir; çünkü bu onların işi. Kodu eşit tutkuyla savunmak ise sizin göreviniz.”

“Kölelerin hayır demesine izin verilmez ve işçiler hayır demekte tereddüt edebilirler. Ancak profesyonellerden hayır demeleri beklenir. Gerçekten de, iyi yöneticiler hayır demek için cesareti olan birini isterler. Gerçekten bir şey yapabilmenin tek yolu budur.”

“Uzun isimler vermekten korkmayın. Uzun ve tanımlayıcı bir isim, kısa ve esrarengiz bir isimden daha iyidir. Uzun ve tanımlayıcı bir isim, uzun ve tanımlayıcı bir yorumdan daha iyidir.”

“Bir programın basitmiş gibi gelmesini sağlayan dili değildir; bir dilin basitmiş gibi gelmesini sağlayan programcıdır.”

“Çeviklik daha hızlı olmaktan ibaret değildir. Çeviklik umudu yok etmekle ilgilidir. İyi bir çevik ekip tarafından sağlanan veriler, yöneticilere sert gerçekleri zamanında müdahale edebilecekleri şekilde sunar.”

“Son 30 yılda, yazılımı geri dönüşü olmayan şekilde medeniyetimizin temellerine taşıdık. Biz programcılar şimdi hayranlıkla karışık korku uyandıran bir sorumluluk taşıyoruz. Medeniyeti geliştirmek veya yok etmek artık bizim elimizde.”

“Kodunuza her yorum yazdığınızda, yüzünüzü buruşturmalı ve ifade becerinizin eksikliğini hissetmelisiniz.”

“Mimarı ilgilendiren ilk şey, evin kullanılabilir olduğundan emin olmaktır; tuğladan yapılmasını sağlamak değildir.”

“İyi mimari, sistemin anlaşılmasını, geliştirilmesini, bakımını ve dağıtımını kolay hale getirir.”

“Programcılar, kodun anlamını gizleyen yanlış ipuçları bırakmaktan kaçınmalıdır.”

Robert D. Schneider

(Büyük veri, veri analitiği, veritabanı teknolojileri ve bulut gibi konularda uzmanlaşmıştır. Yayımlanmış 6 kitabı ve çok sayıda makalesi vardır. Dünya çapında teknoloji etkinliklerinde konuşmacı ve sunucu olarak yer almaktadır.)

 

“Programcıların asla hata yapmadığı bilinen bir gerçek olsa da programınızın kritik noktalarındaki hataları kontrol ederek kullanıcıların gönlünü almak iyi bir fikirdir.”

Robert X. Cringely

(Mark Stephens, bu takma adla, kitaplarını ve InfoWorld, Forbes, Newsweek, Success, The New York Times, Upside, Worth gibi yayınlarda teknoloji konusunda makalelerini yayımlamış ve NerdTV internet programının yapımcılığını üstlenmiştir.)

 

“Eğer otomobil bilgisayarla aynı gelişme döngüsünü takip etmiş olsaydı; bir Rolls-Royce bugün 100 dolara mal olacak, galon başına bir milyon mil yol alacak ve yılda bir defa patlayarak içindeki herkesi öldürecekti.”

Roedy Green

(Kanadalı bir programcı, yazılım danışmanı ve aktivisttir. İnternette “Java ve İnternet Sözlüğü” ile tanınmıştır.)

 

“Sürdürülemez kod yazmanın temel kuralı, her bir olguyu mümkün olduğunca çok yerde ve mümkün olduğunca çok şekilde belirtmektir.”

Ron Jeffries

(Çevik yazılım geliştirme metodolojilerinden Extreme Programming’in (Aşırı Programlama) yaratıcılarından biridir.)

 

“Kod asla yalan söylemez, kod açıklamaları bazen söyler.”

S

Sam Altman

(Amerikalı girişimci, yatırımcı, programcı ve blog yazarıdır. OpenAI’nin CEO’su ve Y Combinator’ın eski başkanı olarak tanınmıştır.)

 

“Bir fikri iyi şekilde hayata geçirmek, iyi bir fikre sahip olmaktan en az on kat önemli ve yüz kat zordur.”

Sandro Mancuso

(İngiliz yazılımcı, London Software Craftsmanship Community’nin (LSCC) kurucusu ve yazardır.)

 

“Açık kaynak projelerine katkıda bulunmak, pratik yapmak için harika bir yoldur.”

Sidney Markowitz

(MIT mezunu bir bilgisayar bilimcidir, yazılım gelişirici olarak 30+ yıllık deneyimi vardır, açık kaynak ve özgür yazılım savunucusudur ve biyoinformatik alanında doktorası vardır.)

 

“Bir yazılım, sonuncu kullanıcı ölene kadar tamamlanmış sayılmaz.”

Stephen Hawking

(Dünyaca ünlü bir İngiliz teorik fizikçi, kozmolog, yazardır. Son yıllarında Cambridge Üniversitesi’ndeki Teorik Kozmoloji Merkezi’nde araştırma direktörlüğü yapmıştır.)

 

“Bilginin en büyük düşmanı cehalet değildir, bildiğini zannetme yanılsamasıdır.”

Steve Jobs

(Amerikalı iş insanı, endüstriyel tasarımcı ve Apple’ın kurucusudur.)

 

“Müşterilerinize ne istediklerini sorup, sonra istediklerini yerine getirmeye çalışamazsınız. İstedikleri şeyi yapmayı tamamladığınızda, yeni bir şey isteyeceklerdir.”

Steve McConnell

(Yazılım tarihinde iz bırakan “Code Complete”, “Rapid Development” ve “Software Estimation” gibi kitapların yazarı olan tanınmış bilgisayar mühendisidir.)

 

“İyi kod, kendisinin en iyi dokümantasyonudur. Kodunuza açıklama eklemek üzereyken, kendinize şu soruyu sorun: ‘Bu açıklamanın gerekmemesi için neyi iyileştirebilirim?’ ”

“Programlama diğer aktivitelerden daha fazla konsantrasyon gerektirir. Programcıların ‘hızlıca araya girmelerden’ rahatsız olmalarının nedeni budur — bu tür kesintiler bir jonglörden üç topu havada tutarken aynı anda torbalarınızı da tutmasını istemek gibidir.”

“Test kalitesini artırarak yazılım kalitesini yükseltmeye çalışmak, daha sık tartılarak kilo vermeye çalışmak gibidir. Yazılımınızı geliştirmek istiyorsanız, daha fazla test yapmayın; daha iyi geliştirin.”

“Yazılımda, zincir en zayıf halkası kadar bile güçlü değildir; tüm zayıf halkalarının çarpımı kadar zayıftır.”

“Büyük optimizasyonlar bireysel rutinleri değil, üst düzey tasarımı iyileştirerek olur.”

“Kodlamaya başladığınızda, kodunuzla duygusal bir bağ kurarsınız ve kötü tasarımı atıp baştan başlamak zor hale gelir.”

“Kodunuzda hata arayarak, onu bulmak zaten yeterince zorken; kodunuzun hatasız olduğunu varsaydığınızda, hatayı bulmak daha da zor hale gelir.”

“Başarılı bir yazılım projesinde sırlar yoktur. İyi haberler de kötü haberler de, kısıtlama olmaksızın proje hiyerarşisinde aşağı yukarı hareket edebilmelidir.”

“Yazılım projeleri iki nedenden dolayı başarısız olur; ya proje ekibi bir yazılım projesini başarılı şekilde yürütme bilgisine sahip değildir, ya da proje ekibi bir projeyi etkin bir şekilde yürütme konusunda kararlılıktan yoksundur.”

“En iyi süre tahmini, proje yöneticisine proje gerçekliği hakkında görüş netliği sağlayıp; projeyi hedeflerine ulaştırmak için nasıl yöneteceğiyle ilgili doğru karar almasını sağlayan tahmindir.”

“Bir yazılım projesindeki varsayılan hareket, daha karmaşık hale getirmek için öğeler eklemek yerine, yazılımı daha basit hale getirmek için yazılım öğelerini uzaklaştırma yönünde olmalıdır.”

“Motivasyon, kesinlikle insanların ne kadar iyi performans gösterdiği üzerinde en büyük etkidir.”

Steve Swartz

(Uzun yıllar Microsoft’ta çalışmış bir yazılım geliştirme yöneticisidir. Dağıtık sistemler, platform ve çatı geliştirme, bulut yazılım ve e-ticaret konularında geniş deneyime sahiptir.)

 

“Bir Porsche ile trafikte sıkışıp kaldığınızda, tek yaptığınız boşta daha fazla benzin yakmaktır. Ölçeklenebilirlik, daha hızlı arabalar yapmakla değil, daha geniş yollar yapmakla ilgilidir.”

T

Tim Berner-Lee

(İngiliz bilgisayar bilimci, profesör, yazar ve World Wide Web’in mucididir.)

 

“Web, teknik olmaktan çok sosyal bir yaratımdır. Teknik bir oyuncak olarak değil, sosyal bir etki için – insanların birlikte çalışmasına yardımcı olmak için – tasarlanmıştır.”

Thomas C. Gale

(Chrysler, Dodge ve Plymouth ile yaptığı çalışmalarla tanınan Amerikan otomobil tasarımcısıdır.)

 

“İyi bir tasarım, maliyeti artırdığından daha hızlı şekilde ‘değer’ katar.”

Tom Cargill

(Nesne yönelimli programlama alanında ve “90–90 kuralı” ile tanınmaktadır. Yoğun olarak C ++ ile yazılan hata ayıklayıcılar üzerinde çalışmıştır ve “C++ Programming Style” kitabının da yazarıdır. Şirketlere danışmanlık hizmetleri ve C ++, Java, XML ve Nesneye Yönelik Teknoloji kursları ve atölyeleri vermektedir.)

 

“Kodun ilk %90’ı, geliştirme süresinin ilk %90’ını oluşturur. Kodun kalan %10’u, geliştirme süresinin diğer %90’ını oluşturur.”

Tom DeMarco

(Amerikalı bir yazılım mühendisidir ve ayrıca yazılım mühendisliği danışmanlığı yapar.)

 

“Yöneticinin işlevi, insanları çalıştırmak değil, insanların çalışmasını mümkün kılmaktır.”

“Kötü yönetimin birinci yasası: Bir şey işe yaramıyorsa, ondan daha fazla yapın.”

“Bilgisayar sistemi analizi çocuk yetiştirmeye benzer; çok büyük zararlar verebilirsiniz, ancak başarıyı garanti edemezsiniz.”

“Son kullanıcının beklediğinin çok ötesinde kalite, daha yüksek üretkenlik için bir araçtır.”

“İçinde bulunduğumuz iş, teknolojik olmaktan çok sosyolojik, işçilerin makinelerle iletişim kurma yeteneklerinden daha çok birbirleriyle iletişim kurma yeteneklerine bağlı.”

“Başarılı değişim, yalnızca neyin asla değişmeyeceğine, organizasyonun neyi temsil ettiğine dair net bir anlayış bağlamında gelir.”

Tom Gilb

(Amerikalı bir sistem mühendisi, danışman ve yazardır. Yazılım ölçümleme, yazılım incelemesi ve çevik yazılım geliştirme yöntemlerinin öncüsü kabul edilen evrimsel süreçleri geliştirmesiyle tanınmaktadır.)

 

“Bilgisayarın suçlandığı tüm hataların kökeninde, bilgisayarı suçlamak da dahil olmak üzere en az iki insan hatası vardır.”

Tom Love

(Washington Üniversitesi’nde Bilişsel Bilimler alanında doktorası bulunan bir bilgisayar bilimcidir. Objective-C’nin yaratıcılarındandır. Nesne yönelimli programlama konusunda “Object Lessons: Lessons Learned in Object-Oriented Development” kitabını yazmıştır.)

 

“Verimli geliştirme yapmanın yolu, yeni ve ilginç hatalar yapmaktan geçer.”

Tom Van Vleck

(Amerikalı bir bilgisayar mühendisidir. MIT’den matematik alanında lisansı vardır ve MIT Bilgisayar Bilimleri ve Yapay Zeka Laboratuvarı’nın çıkış noktası olan Project MAC’te yer almıştır.)

 

“Biri ‘… yapsak hoş olur’ dediğinde yapılacak doğru şey, nazikçe sözünü bitirmesini beklemektir. Hiçbir projede hoş olacak özelliklere vakit ayrılmaz, veya onları yaptıktan sonra pişman olunur. ‘… yapmalıyız.’ cümlelerini bekleyin, çok dikkatli olun ve hemfikir olup olmadığınıza dikkat edin.”

Tommy Collison

(Yazar ve gazetecidir. Çevrim içi olarak yazılım geliştirme ve kodlama dersleri veren Lambda School’da yöneticilik yapmaktadır.)

 

“En iyi öğrenenler, bir konuda nesnel şekilde kötü olmalarının verdiği rahatsızlığa rağmen peşini bırakmayarak sonuna kadar gidenlerdir.”

Tony Hoare

(Programlama dillerine, algoritmalara, işletim sistemlerine, resmi doğrulamaya ve eşzamanlı hesaplamaya temel katkılarda bulunan İngiliz bilgisayar bilimci.)

 

“Bir yazılım tasarımı oluşturmanın iki yolu vardır: Bir yol, onu açıkça hiçbir eksiklik olmayacak kadar basit hale getirmek ve diğer yol, onu hiçbir belirgin eksiklik olmayacak kadar karmaşık hale getirmektir.”

V

Vaughn Vernon

(Yazılım tasarımı ve uygulamasını basitleştirme konusunda deneyimli bir yazılım ustası ve düşünce lideridir.)

 

“Geliştiriciler, teknolojiye çok fazla sarılmış durumdalar ve sorunları dikkatli düşünce ve tasarım yerine teknolojiyi kullanarak çözmeye çalışıyorlar. Bu da sıklıkla, bir hevesle son moda teknolojilerin peşine düşmelerine neden oluyor.”

W

W. Edwards Deming

(Amerikalı bir mühendis, istatistikçi, profesör, yazar, öğretim görevlisi ve yönetim danışmanıdır. En çok 2. Dünya Savaşı sonrasında Japonya’da yapmış olduğu çalışmalarla tanınmaktadır.)

 

“Veri olmadan, sadece fikri olan herhangi biri olursunuz.”

Ward Cunningham

(Amerikalı bir bilgisayar programcısıdır, tasarım örüntüleri ve aşırı programlamada öncü kabul edilmektedir, ilk Wiki’yi geliştirmiştir ve Agile Manifesto’nun ortak yazarları arasındadır.)

 

“İnternette doğru cevabı almak için en iyi yol; soru sormak değil, yanlış cevabı yazmaktır.”

“Biriyle kod hakkında konuşurdum ve ‘Bence bunu yapmanın en iyi yolu A’ derdim. O da ‘Hayır, B’ derdi. ‘Tamam, B yap; ben yanılıyorsam, hasar çok büyük olmaz. Ben haklıysam ve sen B yaparsan, hasar yine çok büyük olmaz çünkü hatayı düzeltebiliriz. Hadi, bunun bir hata olup olmadığını öğrenelim.’ diyebildiğim an benim programcılık kariyerimde bir dönüm noktası oldu.”

“Bir programa yeni özellik eklemek önemlidir, ancak gelecekte başka yeni özelliklerin eklenebilmesi için kodu yeniden düzenlemek de aynı derecede önemlidir.”

“İnsanlar sürekli olarak yarının işini kolaylaştıran sistemler tasarlamaya çalışıyorlar. Ama yarın geldiğinde, yarının işini tam olarak anlamadıkları ortaya çıkıyor ve aslında işi daha da zorlaştırmış oluyorlar.”

Wietse Venema

(Hollandalı bir programcı ve fizikçidir. En fazla Postfix e-posta sistemini yazmasıyla ve Coroner’s Toolkit ile tanınmaktadır.)

 

“Yazılım geliştirirken, kendi hatamdan veya başka bir nedenden dolayı başarısız olabileceğini bilirim.”

Y

Yegor Bugayenko

(Rus bir programcı, girişimci, yatırımcı ve açık kaynak destekçisidir. “Code Ahead” adlı kitabı ve blog yazıları ile tanınmıştır. PDD gibi bazı tescilli metodolojileri ortaya çıkarmıştır.)

 

“Kalite, zorla uygulatılmalıdır; başka türlü gerçekleşmez. Biz programcıların test yazması zorunlu tutulmalıdır; başka türlü yazmayız.”

“Kıdemli geliştirici olmak, yüksek bir maaş almak veya ofiste takdir görmek anlamına gelmez. Belirli şeyleri nasıl yapacağını bilen ve bunları yapabilen seçkin bir geliştirici grubuna dahil olmak anlamına gelir.”

“Bir yazılım ekibinde bilgiye ulaşmak ne kadar zorsa, ekibin verimi o kadar düşüktür.”

“Yazılım geliştiricileri kodlama hataları için suçlamamalıyız. Hatalar, sadece kod depoya birleştirilene kadar onlara aittir. Ondan sonra tüm hatalar hepimizindir!”

“Ceza iyi tanımlanmış kuralların olduğu bir sistemden değil de, kişilerden geldiğinde şevk kırıcı olur.”

“Bir yazılım projesinde, tüm teknik kararlardan sorumlu olan ve bunları yerine getirmek için yeterli yetkiye sahip bir teknik lider bulunmalıdır. Sorumluluk ve yetki, bir kişinin mimar olarak adlandırılabilmesi için gereken iki zorunlu bileşendir.”

Anonim – Boston Bilgisayar Müzesi

“Hata ayıklama tatsızca beklenir, isteksizce yapılır ve hakkında sonsuza kadar övünülür.”