Идеи ..
Ideas ..
Идеи..
-
Maybe one day: SOFTWARE SCHOOL
Може би някой ден: УЧИЛИЩЕ ПО СОФТУЕР
Представи си работилница-училище за софтуер, в което хората учат чрез правене
на проекти - и обратното, се правят проекти, обучавайки се. То в софтуера винаги е така
ама никой не смее да си признае - "аз знам че нищо не знам" не се казва лесно. (виж
книгата на Филип Армур в препоръчваните четива).
Ударението ще е на правенето на *добри* неща *бързо*: Добри като (статично)
качество И като (динамично) лесно-променяеми (също част от бързо-то) ; Бързо като
оборот и време за реакция. А това става чрез уместна употреба И изобретяване на езици,
езици, езици.. навсякъде.
Яйце и кокошка: търся проекти за правене - И хора да се учат..
Imagine a software house-school where people learn by doing real stuff and do real
stuff learning. All software making is actualy learning - just noone wants to admit it
- "i do know that i dont know anything" isn't said easy. (see Phillip Armour's
book/quotes in the recommended readings).
The accent will be on doing *good* stuff *fast*: good as (static) quality And
(dynamic) easy-changeable (which is also part of the Fast) ; fast as turnaround and
time-to-reaction. And this happens by proper usage And inventing of languages,
languages, languages.. everywhere.
Egg and chicken: looking for projects to do - And people to learn..
-
Garden of personal notions
Градина на личните понятия
Огород личных понятий
This should be a System that helps you do "routine"
activities like remembering, learning and expressing yourself, about your known
things. And translating to and from everything else.
Това трябва да е Система която ти помага да правиш "рутинни"
дейности като запомняне, научаване и себеизразяване, относно познатите ти неща. И
преводачи към и от всичко друго.
Это должно быть Система помагающая тебе делать "рутинних"
действий как запоминать, научать и себевыражать, относно знакомых тебе вещей. И
переводчики на и от всего другого.
-
my software - dbcook, facer, version-control, hyphenation,
Python in bulgarian, and what not
мой софтуер - dbcook, facer, контрол-на-версии, сричкопренасяне,
Питон на български, и какво ли не
мой софт - dbcook, facer, контроль-версий, слово-перенос,
Питон на болгарским, и всякое
..
- Намери си приятел да бъде твоите сетива.
- Не можеш да направиш свестен инструмент/нещо, ако никога не си му бил потребител.
- Направиш ли нещо да могат да го ползват идиоти, само идиоти ще го ползват.
- Езиците са твоите инструменти. Ако няма подходящ, направи си!
- Асоциациите са велико нещо - вярвай на собствения си (интуитивен) нюх.
- Софтуерът всъщност е за и относно хората, а не за и относно машините.
- Доверието е същността на правенето на софтуер. Машината има 100% доверие на
програмиста... докато на другия край хората изобщо си нямат доверие.
Човек трябва да реши къде е в тази редичка - колко доверие и недоверие
можеш да понесеш?
- www-Mрежата прави световното село - така че _всичко_ и всеки е на почти-нулево
"разстояние". Но НИКОГА нулево. А понякога човек се нуждае точно от това - леко
докосване - или добър ритник...
- Find a friend to be your senses.
- One can't make a decent tool/thing if never has been an user of it.
- If you make something to be usable by idiots, only idiots will use it.
- Languages are your tools. If no suitable, make it!
- Association is a great thing - trust your common (intuitional) sense.
- Software is actually about people, not about machines.
- Trust is the essence of making software. The machine trusts the
programmer 100%... while at the other end people don't trust each other
at all. One has to position hirself in this chain - how much trust and
distrust you can handle?
- www-web makes the global village - so _everything_ and everyone is at near-zero
"distance". But NEVER zero. And sometimes one needs just that - a warm touch -
or good kick...
- Найди себе друга, который был бы твои ощущения.
- Не можешь сделать хороший инструмент/чтото, если никогда не был его потребителем.
- Если сделаешь чтото употребляемое идиотами, только идиоты будут его пользовать.
- Языки есть твои инструменты. Если нет подходящих, сделай сам!
- Ассоциация - великая штука. Верь своему собственному (интуитивному) носу.
- В сущности Софтуер есть для и о людей, а не для и о машин.
- Доверие является сущностью всего изготовления софтуера. Машина доверяет програмисту на
100%... а на другом полюсе люди вообще не доверяют друг друга.
Человек должен найти свое место в этой цепи - сколько доверия и недоверия
ты сможеш нести?
- www-Сеть делает мировую деревню - так что "расстояние" до _всех_ и до _всего_
почти-нулевое. Но НИКОГДА нулевое. А человек иногда нуждается точно в этим -
легкое прикосновение - или хороший пинок...
Какво мисля ..
What i think ..
Что я думаю ..
-
Описание на методологията в един мой проект
Description of methodology in one of my projects
Описание методологии в одном из моих проектов
Последните 10+ години всичко е Пъргава-методология.. или по-често, "злоупотреба" с нея.
Ами, "Пъргавината" е като зен-будизма (виж в библиотеката). Не е религия, и не е
панацея, а начин на живот. Не става въпрос за докарване на външен вид, става въпрос за
съдържанието. Ако не идва отвътре - т.е. се разглежда като списъци и правила и отмятане по
точки - няма никаква полза. И няма смисъл да се спазва буквално - ползвай това което те
кефи. Но имай предвид че веднага лъсва _всичко_друго_ което не е наред.
Recent 10+ years everything is Agile methodology.. or more frequently, its "misuse".
Well, "Agile" is like zen-buddhism (see in the library). It's not a
religion, and not a silver bullet, but a way of life. It's not a facade to keep, it's
about contents. If it's not in the heart - i.e. is only taken by lists and rules and
checkboxes - there's no use. And there's no point sticking blindly to it - pick whatever
makes u tick. But have in mind that it makes _all_other_ deficiencies come to light.
Последние 10+ лет всё только Проворная-методология.. или чаще, "злоупотребление" ей.
Ну, "Проворность" как зен-будизм (см. в
библиотеку). Это не религия, и не панацея, а способ жизни. Это не вопрос внешнего вида, а
вопрос о содержанием. Если не приходит изнутри - т.е. рассмaтривается только как списки и
правила да точки - никакой пользы не будет. И незачем применять буквально - бери то что
нравится. Но имей ввиду что сразу увидится _все_другое_ что не работает.
Важно е Въздействието, а не списъка задачи:
What matters is the Impact, not just backlog:
Важно Воздействие, а не список задач:
impact vs backlog framing
-
Правенето на софтуер като граф във време/пространството, и ролите
Software process as a graph in time/space, and roles
Софтуерный процесс как граф во время-пространстве, и роли
IMO, the process of making
software has to be viewed as a graph, both in time (when), and space (what and _who_).
Different metodologies idealize it to be specific kind of graph, e.g. single
multi-point-line, spiral, whatever... and then expect/assume it's the only one, in whole
graph. Which is not correct, pieces (person/time/feature) can be of different kind,
So all the "wars" Agile vs Waterfall/CMMi etc. are because of lazyness and reluctance to
accept that there is NO-single-silver-bullet,
learn all the ways, and most of all, leave (local-) control to the actual doers.
Според мен,
процесът на правене на софтуер трябва да се разглежда като граф, във времето (кога) и
пространството (какво, и _кой_). Разните методологии го идеализират като специфичен вид
граф, т.е. насочен, единична начупена линия, спирала и т.н... и после очакват/приемат че
това е единственото и е приложимо в/у целия граф. Което просто не е вярно,
парчетата (човек/време/детайл) може да са от различен вид,
Тъй че всички войни Пъргава методология срещу Водопадна/CMMi и пр. са само мързел и нежелание да се приеме че
НЯМА-единствен-сребърен-куршум, да се научат всички начини, и най-вече, да се предаде
(местния) контрол на самите извършители.
По моему,
процес создания софтуера надо рассматривать как граф, во времени (когда) и в пространстве
(что, и _кто_). Разные методологии идеализируют его как специфичный вид граф, т.е.
ориентированный, одна ломанная линия, спираль и т.д... и потом ждут/принимают что это
одинственный способ и приложим он по всему графу. Что просто не верно, отдельные куски
(человек/время/деталь) могут быть разными видами.
Так что все "войни" Проворная методология против Водопадной/CMMi и т.д. ... только лень и нежелание принять что
НЕТ-одинственной-серебряной-пули, выучить все способы, и тем-более, передать
(местный) контроль самим совершителям.
-
Спецификацията като изкуство.. (изисквания, анализ, спецификация... връзката, без която не може)
Specification as art.. (requirements, analysis, specification... the link that can not be missing)
Спецификация как исскуство.. (требования, анализ, спецификация... связь, без которой нельзя)
Основните инструменти в правенето на софтуер са... правилните въпроси.
Били те 3-те нива в случай на употреба (use-case: защо-какво-как), или вида
програмиране - процедурно (как), функционално (какво), причино-следствено (защо),
обектно (кой) ... или простото съмняващо се "Дали трябва".
Main tools in software making are... the right questions. Were they
the 3 levels in a use-case (why-what-how), or the kind of programming - procedural
(how), functional (what), reason-goal (why), object-oriented (who) ... or the simple
doubting "Whether it should".
Основные инструменты в создании софтуера это... правильные вопросы.
Были бы они 3 уровня в случае пользования (use-case: почему-что-как), или вид
программирования - процедурное (как), функционалное (что), причино-следственое
(почему), обектное (кто) ... или простое сомневающееся "Да-надо-ли".
- I keep six honest serving-men
- (They taught me all I knew);
- Their names are What and Why and When
- And How and Where and Who.
Rudyard Kipling
- Слуги аз имам шест на брой
- от странно естество.
- Наричат се: Защо, Как, Кой,
- Кога, Къде, Какво.
Ръдиард Киплинг
- Есть у меня шестерка слуг,
- Проворных, удалых.
- Зовут их: Как и Почему,
- Кто, Что, Когда и Где.
|
Добре е да можеш да си (избирателно) глупав.
One should be able to be (selectively) stupid.
Хорошо чтоб мог быть (выбирательно) глупым.
-
Криза? Каква криза? или ефикасното правене на ефективен софтуер
Crisis? What crisis? or the efficient making of effective software
Кризис? Какой кризис? или еффикасно делать еффективный софтуер
-
Аутсорсинг, ишлеме, глобална разработка на софтуер -
предизвикателства на общуването
Outsourcing, offshoring, global software development -
challenges of communication
Аутсорсинг, офшоринг, глобалная разработка софта -
предизвикательства общения
All these are about taking out and distributing work, geographically or
not. Some ways are more separated and independent, others are more intertwinned - one
team is part of the other. The major problem in any such undertaking is the
communication between the teams (written spec is _also_ communication). There are 3
main obstacles - cultural, language and time differences. IMO the cultural one has the
biggest impact. It may happen even if all are in same town, but following different
cultures / ways of thinking and work. And it is hardest to overcome - mentality is not
easily changed, and not everyone is able to walk in other people's shoes. That's my
experience after several years in a global development project with 4 teams of
different cultures.
Всички тези представляват изнасяне и разпределяне на работа, географски
или не. Някои начини са по-отделни и независими, други са по взаимосвързани -
единият отбор е част от друг. Най-голямата трудност в такова едно занимание е
общуването между отборите (писмената спецификация _също_ е общуване). Има 3 основни
пречки - културните, езиковите и времевите разлики. Според мен културните са най-силно
влияещи. Те могат да се проявят даже ако всички са в един и същ град, но следват
различни култури / начини на работа и мислене. И са най-трудни за преодоляване -
манталитетът и мисленето не се променят лесно, и съвсем не всеки може да "ходи в чужди
обувки". Поне това показва моят опит след няколко години в глобален развоен проект с 4
отбора с различни култури.
-
тестването - нещото, без което не трябва (всъщност винаги го има...
крайният потребител)
testing - the thing that should not be missing (actually it's always
there... the end-user)
тестирование - штука, без которой не надо (всущности она всегда есть -
конечний пользователь)
If you want to do
a certain thing
You first have to be
a certain person.
Once you have become
that certain person
you will not care any more about doing
that certain thing.
- Dogen
Ако искаш да направиш
определено нещо
Ти първо трябва да станеш
определен човек.
Веднъж като станеш
този определен човек
няма да те е грижа вече за правенето на
онова определено нещо.
- Доген
Если хочеш сделать
чего-то определенного
Тебе надо спервым стать
определенным человеком.
Когда уже будешь
этим определенным человеком
ты больше не будешь заботиться делать
того определенного чего-то.
- Доген
|
Recommended readings
Препоръчвам за четене
Рекомендую для чтения
Ето някои неща за софтуера, които препоръчвам като основополагащи:
Here some things about software, which i recommend as fundamental:
Вот некоторые вещи о софтуере, которых я рекомендую как основополагающие:
-
Software Engineering book - Ian Sommerville
(Софтуерно инженерство - Ян Сомървил)
(Софтуерное инженерство - Ян Сомервиль)
- amazon8
- amazon6
Това е Книгата за софтуера като инженерна наука. В нея има всичко.
За темата "стари системи" (legacy software), виж по-старото 6-то издание (черното).
The Book about software as engineering science. There is
everything in it. On topic of legacy software, see the older 6th edition (black).
Это Книга о софтуере как инженерная наука. В ней есть все. Для
темы о "старых систем" (legacy software), смотри на старое 6-ое издание (черное).
-
Design patterns book (Erich Gamma et al -- Gang of Four, GOF)
(Проектантски шаблони - Ерих Гама и др, бандата на четиримата)
(Проектантские шаблоны - Ерих Гамма и др, группа четирех)
- wikipedia
A book with important role in software development..
a bit watered with example code. See wikipedia for a list of the patterns.
Това е книга с много важна роля в разработката на софтуер..
малко разводнена с примерен код. Виж уикипедия за списъка от шаблони/образци (patterns).
Это книга очень важной роли в разработке софтуера.. хотя
излишно много примерного кода. Смотри на уикипедия для списка шаблонов/образцов (patterns).
-
Usability Engineering book - Jakob Nielsen
(Използваемост - Якоб Нилсен)
(Использоваемость - Якоб Нильсен)
- wikipedia
Това е Книгата по темата Използваемост. Насочена е към
софтуера, но заложените принципи са общовалидни за всякакви потребителски интерфейси
(напр. управление на касетофон или автомобил). Общо-интересни са първите няколко части.
The Book about Usability. It is targeted at software but the
underlying principles are generally valid for all kinds of user interfaces (e.g.
controls of a tapedeck or a car). Of general interest are the first several chapters.
Это Книга о Использоваемости. Предназначенная для софтуера, но
принципы являются общовалидными для всяких потребительских интерфейсов (напр.
управление радиолы или автомобиля). Общо-интересные - первые несколько части.
-
Organisational patterns book - James Coplien, Neil Harrison
(Организационни шаблони - Джеймс Коплиен, Нийл Харисън)
(Организационние шаблоны - Джеймс Коплиен, Нийл Харисон)
Това е "библия" на тема организационна култура и общуване. Насочена е към
правене на софтуер, но би била полезна и за други (творчески) дейности. Откъси:
This is a "bible" about organisational culture and communication.
It is targeted at software, but can be useful for other (creative) activities. Excerpts:
Это "библия" по теме организационной културы и общения. Насочена она к
созданию софтуера, но могла быть полезной и для других (творческих) деятельностей. Отрывки:
-
Манифест на съвместната игра - Алистар Кобърн и др.
Cooperative game manifesto - Alistair Cockburn et al
Манифест совместной игры - Алистар Кобърн и др.
" Software development is a series of resource-limited,
goal-directed cooperative games of invention and communication. The primary goal of
each game is the production and deployment of a software system; the residue of the
game is a set of markers to assist the players of the next game. People use markers
and props to remind, inspire and inform each other in getting to the next move in the
game. The next game is an alteration of the system or the creation of a neighboring
system. Each game therefore has as a secondary goal to create an advantageous position
for the next game. Since each game is resource-limited, the primary and secondary
goals compete for resources. "
" Разработката на софтуер е последователност от
съвместни игри на изобретяване и общуване, с определена цел, при ограничени ресурси.
Основната цел на всяка игра е направа и внедряване на дадена софтуерна система;
след играта остават набор от белязки (маркировка), които да подпомогнат
играчите при следващата игра. Хората използват тези белязки за да си напомнят, да се
вдъхновяват и осведомяват един друг по пътя към следващия ход в играта. Следващата
игра може да е за промяна на софтуера, или за създаване на друг. Така че всяка игра
има за вторична цел създаването на благоприятни позиции за следващата игра. И тъй-като
всяка игра е ограничена откъм ресурси, първичната и вторичната цел се надпреварват за
тези ресурси. "
" Разработка софтуера представляет последователность совместних
игр на изобретение и общение, имея определенной цели при ограниченних ресурсов.
Основная цель каждой игры - создание и внедрение какой-то софтуерной системы; остаток
после игры является набор меток (маркировка), чтобы помочь игрокам следующей игры.
Люди используют эти метки и опоры для напоминания, вдохновления и осведомления друг
друга по пути к следующему ходу в игре. Следующая игра может бить о перемене той самой
системы, или о создании другой. Так что у каждой игре есть вторичная цель на
создавание благоприятних позиций для следующей игры. И так-как каждая игра ограничена
ресурсами, первичная и вторичная цели состязаються об этих ресурсах. "
виж също Разработката на софтуер като съвместно писане на поезия
see also Software development as community poetry writing
см. тоже Разработка софтуера как совместное писание поезии
-
Декларация на взаимозависимостта -
Declaration of interdependence -
Декларация взаимозависимости -
"We ...
- increase return on investment by --
making continuous flow of value our focus.
- deliver reliable results by --
engaging customers in frequent interactions and shared ownership.
- expect uncertainty and manage for it through --
iterations, anticipation and adaptation.
- unleash creativity and innovation by --
recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.
- boost performance through --
group accountability for results and shared responsibility for team effectiveness.
- improve effectiveness and reliability through --
situationally specific strategies, processes and practices.
"
"Ние ...
- увеличаваме възвръщаемостта на вложеното чрез --
съсредоточаване върху непрекъснатостта на потока от ценности.
- даваме надеждни резултати чрез --
включване на клиента в чести взаимодействия и споделяне на собствеността.
- очакваме несигурността и се справяме с нея чрез --
малки стъпки, предвиждане и приспособяване.
- даваме воля на съзидателността и нововъведенията чрез --
признаване на личностите като първоизточник на ценности, и създаване на среда, където да могат да се развият.
- повишаваме производителността чрез --
групова отчетност за резултатите и споделена отговорност за отборната ефикасност.
- подобряваме ефикасността и надеждността чрез --
специфични за положението стратегии, процеси и методи.
"
"Мы...
- увеличиваем возвращаемость инвестиции через --
сосредоточивание на непрерывный поток ценностей.
- даем надеждних результатов через --
включение клиента в частые взаимодействия и разделение собствености.
- ожидаем неуверенность и справляемся ей через --
итерации, ожидание и приспособливание.
- даем свободу созидательности и нововведениям через --
признавание личностях как первоисточник ценностей, и создание среды, где они
могли развертыватся.
- повишаем производительность через --
групповая отчетность о результатах и разделяя отговорность об ефикасности команды.
- улучшаем ефикасность и надеждность через --
специфичные для ситуации стратегии, процессы и методы.
"
виж също Манифест на Пъргавостта:
see also Agile manifesto:
см. тоже Манифест Проворносты:
... we value:
Individuals and interactions - over processes and tools;
Working software - over comprehensive documentation;
Customer collaboration - over contract negotiation;
Responding to change - over following a plan;
... ние ценим повече:
Личностите и взаимодействията - отколкото процесите и инструментите;
Работещия софтуер - отколкото изчерпателната документация;
Сътрудничеството с клиента - отколкото предоговарянето;
Реагирането на промените - отколкото следването на плана;
... мы ценим больше:
Личности и взаимодействия - чем процессы и инструменты;
Работающий софтуер - чем обширная документация;
Сотрудничество с клиентом - чем предоговаривание;
Реагировать на перемены - чем следование плана;
-
Край на софтуерното инженерство - започват икономически-съвместните игри - Алистар Кобърн
The end of software engineering and the start of economic-cooperative gaming - Alistair Cockburn
Конец софтуерного инженерства и начало экономически-совместных игр - Алистар Кобърн .
"... This means the speed of the project is proportional to the
speed at which information moves between people's heads. Every obstacle to detecting
and moving information between heads slows the project. Understanding and attending to
this issue is essential to playing the game effectively. ..."
"... Това значи че скоростта на проекта е пропорционална на
скоростта с която информацията се придвижва между главите на хората. Всяко препятствие
при откриване и прехвърляне на информация между глави забавя проекта. Разбирането на
това изискване и грижата за него са най-важните за да се играе играта ефективно. ..."
"... Это значит что скорость проекта право пропорциональна
скорости передвижения информации между голов людей. Каждое препятствие обнаруживанию и
передачу информации между голов замедляет проект. Понимание этого требования и забота
о нем является изключительно важной для ефективной игре. ..."
-
"Crystal Clear - A Human-Powered Methodology For Small Teams", 1998-2004, Alistair Cockburn
incl. The Seven Properties of Effective Software Projects
( Кристално-Ясна - Движена-от-хора Методология за малки отбори, вкл.
Седемте свойства на Ефективните софтуерни проекти, Алистар Кобърн )
( Кристально-Ясная - Движимая-людями Методология для малых команд, вкл.
Семь свойства Ефективних софтуерных проектов, Алистар Кобърн )
Прилагах тази методология 7-8 години. Прилича на Скрум, има си и
малко теория, като най-младша от семейството Кристални методологии.
Общо-интересните части са 1,2 и 9 (какво и защо); останалото са подробности (как):
Applied this methodology for 7-8 years. It is similar to
Scrum, and has some theory to it, being lightest in the family of Crystal methodologies.
Chapters of general interest are 1,2 and 9 (what and why); the rest is details (how):
Прилагал эту методологию 7-8 лет. Наподобляет Скрум,
имеет и немножко теории, являясь младшей из семьи Кристальних методологий. Части
общего интереса - 1,2 и 9 (что и почему); остальное есть подробности (как):
-
шу-ха-ри
shu-ha-ri
шу-ха-ри
-
Преживяването е Всичко - Дон Норман
It's all about experience - Don Norman
Переживание есть Все - Дон Норман
, Business of software'2009 -
видео
video
видео
- This must be watched, whole.
- This must be watched, whole.
- This must be watched, whole. .. See?
- The only real thing (about software) is the taste that's left in your mouth.
- Това трябва да се гледа, цялото.
- Това трябва да се гледа, цялото.
- Това трябва да се гледа, цялото. .. Видя ли?
- Единственото важно нещо (в софтуера) е вкуса който остава в устата.
- Этого надо смотреть, всего.
- Этого надо смотреть, всего.
- Этого надо смотреть, всего. .. Видел?
- Одинственная важная вещ (в софтуере) есть вкус который остается во рту.
-
Meeting the Spec and Other Software Fables
(Да покриеш изискванията и Други софтуерни сюжети)
(Выполнить спецификацию и Другие софтуерные сюжеты)
1993
Michael Meier (or metaphysics of software quality)
Майкъл Мейер (или метафизика на софтуерното качество)
Майкл Мейер (или метафизика качества софтуера)
@moq
Warm fuzzies... aren't in the spec. But products lacking warm fuzzies
will never be considered more than average. Warm fuzzies, guts feelings, are
quality. Not the fiscal year bottom line. Happiness isn't technology. Fun has no
price tag. The trick is, usualy we do not detect the presence of warm fuzzies, we
detect their absence...
Топло усещане... няма в спецификацията. Но изделие не предизвикващо
топло усещане, никога не се счита за повече от посредствено. Топлото вътрешно
усещане е качество. Не финансовия резултат за годината. Щастието не е в
технологията. Кефът цена няма. Номерът е там, че обикновено не усещаме наличието
на топло чувство, но много добре усещаме липсата му...
Теплое ощущение... такого нет в спецификации. Но изделие которое не
вызивает теплих ощущений, не оценивается больше чем посредственное. Теплые
внутренные ощущения и есть качество. Не финансовий результат года. Счастье не в
технологии. У удовольствия цены нет. Трик в том, что обычно не узнаем наличие
теплого ощущения, но всегда узнаем когда его нет...
-
On the cruelty of really teaching computing science;
(За жестокостта наистина да обучаваш по изчислителни науки)
(О жестокости воистине обучать в вычислительних науках)
1988
lecture by E.W.Dijkstra
лекция от Е.Дийкстра
лекция Э.Дийкстра
The "How to program if you cannot" science... Whether IT (or
technology at large) has since progressed even a bit into right direction, or...
Are the actual pursued values+outcome the right real one, or a bogus substitute...
Whether we learned to tailor the machines to the job or instead, tailor the job to
the machines...
Науката "Как да програмираш като не можеш"... Дали ИТ (или
технологията като цяло) е напреднала оттогава поне малко в правилната посока
или... Дали гонените резултати+ценности са правилни и същностни, или само кух
заместител... Дали сме се научили да приспособяваме машините към работата, или
напротив, приспособяваме работата към машините...
Наука "Как програмировать если не умееш"... Ушла ли ВТ (или
технология вообще) с тех пор хоть немножко в правильную сторону или... Являются ли
искомые ценности+результаты правильными и сущностными, или пустой заместитель
какой-то... Научились ли мы приспособлять машин к работу, или напротив,
приспособляем работу к машинам...
-
The Laws of Software Process: A New Model for the Production and Management of
Software, 2003, Phillip Armour
(Закони на софтуерния процес: Нов модел за производство и
управление на софтуер, Филип Армур)
(Законы софтуерного процесса: Новая модель производства и
управления софтуера, Филлип Армур)
Software as knowledge medium, and effects thereof
Софтуерът като носител на знание, и произтичащите последствия
Софтуер как носитель знания, и вытекающие последствия
... software is not a product but a medium for storing knowledge, and software
development is not a product-producing activity, it is a knowledge-acquiring activity.
... the real job is not writing the code, or even building the system - it is
acquiring the necessary knowledge to build the system... Code is simply a by-product
of this activity. The problem arises when we think the code, rather than the knowledge
in the code, is the product.
... When we use models and mindsets that are rigid and deterministic to manage an
activity that is fluid and variable, it is not surprising that people get disappointed.
... софтуерът не е продукт, а среда за съхранение на знания, и разработката му не
е производство на продукти, а придобиване на знания.
... истинската работа не е да се напише кодът, или дори да се построи системата -
тя е да се придобие нужното знание за построяване на системата... Кодът е само
страничен продукт от тази дейност. Белята идва като започнем да си мислим, че кода е
продукта, а не знанието в него.
... Като се ползват твърди и (пред)определени модели и представи, за да се
управлява дейност променлива и неясна, не е изненадващо че хората се разочароват.
... софтуер не продукт, а среда сoхранения знаний, и его разработка не
производство продуктов, а получение знаний.
... настоящее дело не в написанием кода, или даже не в построением системы - оно в
получения нужного знания для построения системы... Код есть просто посторонныий
продукт етой деятельности. Беда приходит как начнем думать, что код и есть продукт, а
не знание что в ним.
... Когда употребляются твердые и (пред)определенные модели и представления, чтобы
управлять деятельности переменной и неясной, не удивительно что люди огорчаются.
тази книга е... философска? Все едно всичко по-горе заедно със
себеподобните си, на едно място - опит да се поставят нещата на краката им.
Например, виж това следствие: "... като цяло, (софтуерните) инженери
не _знаят_ как да направят системите които се опитват да направят; тяхната работа
е да _открият_ как се прави това." т.е., че програмистите трябва да
умеят да учат (и да обучават) - да се научат на това и/или да бъдат научени.
Всичко друго са само инструменти, подпомагащи тази дейност.
this book is... philosophical? Like all the above together with
all its peers, in one place - an attempt to put them things with their legs down.
For example, see this consequence: "... for the most part, (software)
engineers do not _know_ how to build the systems they are trying to build; it's
their job to _find_ out how to do it." i.e. programmers must be able
to learn (and teach) - should learn that and/or be taught to it. All else are
tools supporting that activity.
эта книга... философская? Все равно все что выше вместе со
себеподобными, на одном месте - попытка поставить вещи вниз ногами. Например, см.
это следствие: "... в целом, (софтуерные) инженеры не _знают_ как
построить системы которые они питаются сделать; их работой является _открить_ как
это делается." т.е., програмистам надо уметь учить (и обучать) -
надо им научиться того и/или их научить. Все другое - только инструменты,
воспомагащие эту деятельност.
-
PHILOSOPHY OF SOFTWARE
(Философията на софтуера)
(Философия софтуера)
1996
-
още нещо за размисъл...
more food for thought...
еще чего-то к размишлению...
-
The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change, 2017, Camille Fournier
(Пътят на мениджъра: наръчник на технологическия ръководител при
растеж и промяна, Камил Фурние)
(Путь мениджера: гид технологического руководителя в случае растежа
и перемен, Камиль Фурние)
--
Това е Книгата.. описваща цялата стълбичка от обикновен писач до
технически директор/CTO.. занимания, качества, отношения.. хора, хора, хора. Според мен,
най-тежкото откровение е, че ако се качиш нагоре, "не можеш да бъдеш приятел с
подчинените си - предишни колеги или не". За съжаление е вярно, колкото и да не ми
харесва. А колко можеш да си приятел със другите на твоето ниво.. ммммх.
This is The book.. describing whole staircase from regular coder to
CTO/technical director.. activities, qualities, relations.. people, people, people. IMO, the
heaviest revelation is that, if you climb up, "you cannot be friends with your
subordinates - previously colleagues or not". Sad but true, regardless how much i
don't like it. But how much you can be friends with others at your level... mmmh.
это есть Книга.. описывающая всю лестницу от обычного кодера до
CTO/технического-директора.. занятия, качества, отношения.. люди, люди, люди.
По моему, наиболее тяжелое откровение то, что если пойдеш наверх, "не можешь бить в
друзья с твоими подчиненими - предидущие коллеги или нет". А сколько можно бить в друзья с
остальных на твоем уровне... мммх.
-
Динамична теория за създаването на знание (Нонака, 1994)
Dynamic theory of knowledge creation (Nonaka, 1994)
Динамическая теория создавании знания (Нонака, 1994)
--
Дълбока статия, за начините на мислене и създаване на ново знание и
основополагащата роля на отделния човек, и организацията като среда за това, за
неявното-неограничено-вътрешно знание и явното-външно-кодирано такова и важността на
взаимодействията им... (а техно-човечеството се старае да заобиколи този факт). Има
идеите от горните няколко книги... доста преди тях.
Deep article, about ways of thinking and creation of knowledge and the
foundation role of the individual person, and the organisation as medium in this,
about the tacit-implicit-unlimited-internal knowledge and explicit-external-coded one,
and the importance of their interactions... (and techno-mankind is trying to steer
clear of the fact). Also most ideas of the books above... long before them.
Глубокая статья; способы мишления и создавания нового знания и
основополагающая роль отдельного человека, и организация как среда для этого;
неявное-неограниченое-внутренное-знание и явное-внешнее-кодированное знание и важность
их взаимодействий... (а техно-человечество все старается обойти мимо этого факта). И
идеи с книг выше... много лет заранее их.
-
Какво значи че не ми харесваш стила (Дж.Филдън 1982)
What do you mean you don't like my style (J.S.Fielden, 1982)
Что значит тебе не нравится мой стиль (Дж.Филден, 1982)
--
За това как стила на един текст може да промени посрещането и разбирането
му (и оттук крайното му значение в дадената ситуация)
About how change of some text's style may change its reception and interpretation
(hence its final meaning in the situation)
О том как стиль текста можеть переменить его встречное понимание (и как
следствие его конечное значение в данной ситуации)
-
интересни четива, мисловни и организационни:
interesting readings, thinking and organisational:
интересные вещи, мисловные и организационные:
-
метафизика на качеството/Пирсиг, наука като суши, TaoTeChing, Паркинсон,
измерения на културите, антропология и култура
metaphysics of quality/Pirsig, sushi science, TaoTeChing, Parkinson,
cultural dimensions, anthropology and culture
метафизика качества/Пирсиг, наука как суши, TaoTeChing, Паркинсон,
измерения культур, антропология и культура
...
|
