સ softwareફ્ટવેર વિશ્વના વાહિયાત કાયદા

શું તમે ક્યારેય વિચાર્યું છે કે સ softwareફ્ટવેર ડેવલપર્સ જેવા સ્માર્ટ લોકો આટલી વાર શા માટે આંચ આવે છે? એવા લોકો પણ છે જેણે કર્યું. આ પોસ્ટમાં અમે સમીક્ષા કરીએ છીએ કેટલાક અલિખિત કાયદા જે વ્યાવસાયિકોની વર્તણૂકનું વર્ણન કરે છે ગણતરી.

મારું પ્રથમ કમ્પ્યુટર એ કમોડોર 64 હતું. લગભગ 30 કેબી રેમ સિસ્ટમ માટે હતી, વર્ડ પ્રોસેસિંગ, ગેમિંગ, કૌટુંબિક વ્યવસાય એકાઉન્ટિંગ માટે 32 કેબી છોડીને, અને હવે મારી પાસે 6 જીબી કમ્પ્યુટર સાથે હું જે કંઇક કરું છું તે વિશે. તે પ્રશ્નને ખુલ્લો મૂકે છે શું આજના સાધનો સ softwareફ્ટવેરની જરૂરિયાતોને પ્રતિસાદ આપે છે અથવા સોફ્ટવેર ઉપલબ્ધ હોવાને કારણે વધુ હાર્ડવેર સંસાધનોનો ઉપયોગ કરે છે?

Fairચિત્યમાં, રમતો સમાન નથી, ગ્રાફિક્સ સમાન ગુણવત્તા નથી, અને મૂવીઝ જોવી અને સંગીત સાંભળવું અશક્ય હોત. જો કે, એક મદદ કરી શકે છે, પરંતુ તે વિચારી શકશે નહીં એવા પ્રોગ્રામ્સ છે જે ખરેખર કંઈપણ નવું યોગદાન આપ્યા વિના સંસ્કરણો પ્રકાશિત કરે છે અને વધુને વધુ સંસાધનોનો વપરાશ કરે છે.

અહીં કારણો છે.

ઝાવિન્સકીનો કાયદો

નેટસ્કેપના વિકાસકર્તા જેમી ઝાવિંસ્કીએ દલીલ કરી હતી દરેક પ્રોગ્રામ સુવિધાઓ શામેલ કરે છે જ્યાં સુધી તે ઇમેઇલ્સ વાંચવામાં સક્ષમ ન થાય. જો તે સફળ ન થાય, તો તેની જગ્યાએ તે બીજા દ્વારા લેવામાં આવે છે જે આમ કરવા સક્ષમ છે.

જ્યારે તેણે કહ્યું, મજાક એ હતી કે તે એવા પ્રોગ્રામ્સનો ઉલ્લેખ કરી રહ્યો હતો જેનો હેતુ ઇમેઇલ ક્લાયન્ટ્સ તરીકે ન હતો. જ્યારે તે જાણવા મળ્યું કે ગૂગલ પ્લે પર ઘણી એપ્લિકેશન્સ ફોનના ઘટકો અને વપરાશકર્તા ડેટાને jobક્સેસ કરવા માટે પરવાનગી માંગી રહી છે ત્યારે તેમને રમૂજી થવાનું બંધ થયું કે તેમને તેમનું કામ કરવાની જરૂર નથી.

કેટલાક લોકોએ તેનો જાસૂસ કરવાના પ્રયત્નોના ભાગ રૂપે અર્થઘટન કર્યું. પરંતુ સંભવત something કંઈક કરવું તે માનવ સ્વભાવ છે કારણ કે તે કરી શકાય છે.

પીટરના સિદ્ધાંત સ softwareફ્ટવેર પર લાગુ

લોરેન્સ પીટર એમ કહીને પ્રખ્યાત બન્યા કે વંશવેલોમાં, વ્યક્તિ એવી સ્થિતિમાં ઉગે છે કે જેના માટે તે એકદમ અસમર્થ છે. પરંતુ તેમની પાસે જટિલ પ્રોજેક્ટ્સ વિશે કંઈક કહેવાનો પણ સમય હતો:

"એક જટિલ પ્રોજેક્ટ તેના જ વિકાસકર્તાઓ દ્વારા પણ સમજી શકાય તેટલું જટિલ બનશે."

ઓછામાં ઓછા આશ્ચર્યનો સિદ્ધાંત

1984 માં આઈબીએમ સિસ્ટમ્સ જર્નલમાં પ્રકાશિત, આ સિદ્ધાંત જણાવે છે કે:

"જો આવશ્યક સુવિધા મોટા આશ્ચર્યનું કારણ બને છે, તો સુવિધાને ફરીથી ડિઝાઇન કરવાની જરૂર પડી શકે છે."

અન્ય શબ્દોમાં, જો ભાગ અથવા તમામ સ softwareફ્ટવેર યુઝર જે કરતા હતા તેના કરતા ખૂબ અલગ છે, તો ફરીથી ડિઝાઇન શ્રેષ્ઠ છે. આદર્શરીતે, પ્રાપ્ત કરવાનો પ્રયત્ન કરો પ્રભાવશાળી બનવા માટે પર્યાપ્ત સુધારાઓ, પરંતુ પરિચિત રહેવા માટે પૂરતા નાના વપરાશકર્તા માટે.

ખૂબ ખરાબ શટલવર્થે જ્યારે યુનિટી શરૂ કરી ત્યારે તેને ધ્યાનમાં લેતા નહોતા.

સાયબરનેટિક એન્ટોમોલોજી કાયદો

કમ્પ્યુટર ઇતિહાસમાં પ્રથમ ભૂલ વાસ્તવિક હતી. માર્ક II કમ્પ્યુટર પર ખામીને કારણે એક રિલેમાં એક શલભ ઉડ્યો.

રૂપક સાથે ચાલુ રાખીને, સાયબરનેટિક એન્ટોમોલોજીનો કાયદો તે ધરાવે છે હંમેશાં એક વધુ બગ હશે.

તે કંઈક છે જે બધા કમ્પ્યુટર વપરાશકર્તાઓ જાણે છે. Matterપરેટિંગ સિસ્ટમનું કેટલું પરીક્ષણ કરવામાં આવે છે તે મહત્વનું નથી, ત્યાં હંમેશાં દોષ હોય છે જે શોધવામાં આવે છે જ્યારે ખૂબ મોડું થાય છે.

કર્નીઘનનો કાયદો

લિનક્સ એડિક્ટ્સે પ્લગઇન ઇન્સ્ટોલ કર્યું છે તેની ખાતરી કરવા માટે કે અમે લેખકો શોધ એંજિન મૈત્રીપૂર્ણ રીતે લખીએ છીએ. મને તેનો પ્રથમ દિવસથી જ નફરત છે. થોડીક સાહિત્યિક ફ્લાઇટ સાથે લખવાનો કોઈપણ પ્રયાસ લાલ વર્તુળ સાથે તરત જ વખોડવામાં આવે છે. જેમ જેમ સમય વીતતો ગયો તેમ તેમ મારી આદત પડી ગઈ અને થોડા જ સમયમાં મારે ટચ-અપ કરવું પડશે.

પ્રોગ્રામરો માટે એક જ વસ્તુ થાય છે, ઘણી વાર તેઓ સરળ કોડ લખવામાં કરતાં સમજવાની અને જાળવણી કરવામાં સરળતા કરતા તેમની કોડ કરવાની તેમની ક્ષમતા દર્શાવવામાં વધુ રસ લે છે.

આથી કર્નીઘનનો નિયમ છે કે:

પ્રથમ સ્થાને કોડ લખવા કરતાં બમણું મુશ્કેલ છે. તેથી જો તમે શક્ય તેટલું સ્માર્ટ કોડ લખો છો, તો તમે વ્યાખ્યા દ્વારા, તેને ડિબગ કરવા માટે પૂરતા સ્માર્ટ નથી. '

90/90 નો નિયમ

વાસ્તવિક જીવનમાં નફાકારક પ્રોજેક્ટ શરૂ કરનાર કોઈપણ જાણે છે કે પ્રત્યેક પ્રોજેક્ટ બમણા બમણા લાંબા ખર્ચમાં અને બજેટ કરતા બમણી ખર્ચ કરશે, જે અપેક્ષિત નફો કરશે.

કમ્પ્યુટર જગતમાં આ કાયદાના વિવિધ પ્રકારો છે. ઉદાહરણ તરીકે, એક ટોમ કારગિલે કહ્યું:

“કોડનો પ્રથમ 90 ટકા વિકાસ સમયનો પ્રથમ 90 ટકા રજૂ કરે છે. બાકીનો 10 ટકા કોડ વિકાસના અન્ય 90 ટકા સમયને રજૂ કરે છે. "

તે સ્પષ્ટ ન હતું? કદાચ હોફ્સ્ટાડેટરનો કાયદો મદદ કરશે:

"હોફ્સ્ટાડેટરના કાયદાને ધ્યાનમાં રાખીને પણ, તે હંમેશાં તમારી અપેક્ષા કરતા વધુ સમય લે છે."

હું માનું છું કે ઉબુન્ટુ અને ફેડોરા વિકાસકર્તાઓને જાણવું જ જોઇએ. અથવા ઓછામાં ઓછા દર 6 મહિના પછી તેને યાદ રાખો.

બ્રુકનો કાયદો

ઓપન સોર્સ સ softwareફ્ટવેર પ્રોજેક્ટ્સમાં ઘણી વાર બે સમસ્યાઓ હોય છે; ધિરાણ અને સહયોગીઓનો અભાવ. સિવાય કે બીજી કોઈ સમસ્યા નથી. બ્રુક મુજબ:

"સોફ્ટવેર પ્રોજેક્ટમાં મજૂર ઉમેરવાનું કે જે શેડ્યૂલની પાછળ છે તે વધુ વિલંબ કરશે."

સમજી શકાય તેવું છે, તમારે ફક્ત નવા એન્કોડર્સને અપડેટ કરવાની જરૂર નથી. વધુને દસ્તાવેજીકરણ કરવું પડશે, તે દરેકને સુમેળમાં રાખવા માટે વધુ અમલદારશાહી લેશે, અને સંભવત: ઝઘડા થશે.

અને અલબત્ત અમે મિત્ર પાર્કિન્સન અને તેના દાવા વિશે ભૂલી શકતા નથી તમે કેટલી ખાલી જગ્યાથી પ્રારંભ કરો છો તેનાથી કોઈ ફરક પડતો નથી. તમારે હંમેશા વધુની જરૂર રહેશે. તે officeફિસની જગ્યાનો ઉલ્લેખ કરી રહ્યો હતો, પરંતુ તે જ રેમ અને ડિસ્ક સ્પેસ માટે છે.