Buzzword treadmill
Nov. 26th, 2016 12:45 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
trurle Software development process is unpredictable: for trivial application, the unpredictability is low, the lower the triviality, the higher is unpredictability. Even with more or less trivial applications, there is a chance the project would not be completed on time and under budget or fail completely. There is only one way to reduce the risk of failure - intensive design and code reviews, coupled with bottom-up testing and readiness for discarding the erroneous code. Unfortunately, it implies the understanding of the software on the part of low- and middle- level management and make time estimation almost impossible, but in the software development industry people are not promoted by their development competence and missed understanding of software is frequently replaced with out of limb time estimations
This unfortunate result is situation where the software development process reminds driving by the blinds. Under these circumstances, the managers are in dire need for excuses for failures that appear to them as completely random and unpredictable: the demand for excuses fuel the industry of "software development methodologies". From the point of upper management, as long as middle management employs fashionable "software development methodology", the budget overruns and utter failures have nothing to do with management incompetence, but appear to be an acts of god or any other force majeure.
There is also a related stupid dream, shared by management: turning the software development into industrial process. Almost any willing person can be trained into machine-building floor worker; substantial majority of people can be trained for clerical jobs, so it looks reasonable for ignorant people to imagine the software developers being separated into "software architects" and "coders" - where "software architects" imitate engineers in traditional industries and "coders" expected to behave like workers. The "software development methodologies" then are expected to be applicable to the "coders" in a way similar to a project management in traditional industries, with exact time estimation.
The problem with this stupid dream is that separation software developers into "architects" and "coders" ignores fundamental nature of software - first, if we look at software as an hierarchy of abstractions, there is no level where design become irrelevant and implementation is trivially deduced from higher-level designs. Second, it is almost impossible to come up with correct high-level design before implementation become available and unforeseen issues arise.
For the medium and big corporations responsibility evasion maneuver is executed best when outsourced to the external consultant: the auxiliary consultancy industry creates the environment where new "software development methodologies" spread like plague in medieval cities - as only "methodologies" in current fashion deliver proper and reliable shield from responsibility.
Unfortunately, as "software development methodologies" are manufactured for the dual purposes of evading the responsibility and imaginary control, the methodologies don't materially reduce risk of failures. Therefore, the "software development methodology" fads usually wear out within several years, only to be replaced by even more outrageous and stressful system.
Buzzword treadmill describes the process of replacing worn-out harmful "software development methodology" with new one.
This unfortunate result is situation where the software development process reminds driving by the blinds. Under these circumstances, the managers are in dire need for excuses for failures that appear to them as completely random and unpredictable: the demand for excuses fuel the industry of "software development methodologies". From the point of upper management, as long as middle management employs fashionable "software development methodology", the budget overruns and utter failures have nothing to do with management incompetence, but appear to be an acts of god or any other force majeure.
There is also a related stupid dream, shared by management: turning the software development into industrial process. Almost any willing person can be trained into machine-building floor worker; substantial majority of people can be trained for clerical jobs, so it looks reasonable for ignorant people to imagine the software developers being separated into "software architects" and "coders" - where "software architects" imitate engineers in traditional industries and "coders" expected to behave like workers. The "software development methodologies" then are expected to be applicable to the "coders" in a way similar to a project management in traditional industries, with exact time estimation.
The problem with this stupid dream is that separation software developers into "architects" and "coders" ignores fundamental nature of software - first, if we look at software as an hierarchy of abstractions, there is no level where design become irrelevant and implementation is trivially deduced from higher-level designs. Second, it is almost impossible to come up with correct high-level design before implementation become available and unforeseen issues arise.
For the medium and big corporations responsibility evasion maneuver is executed best when outsourced to the external consultant: the auxiliary consultancy industry creates the environment where new "software development methodologies" spread like plague in medieval cities - as only "methodologies" in current fashion deliver proper and reliable shield from responsibility.
Unfortunately, as "software development methodologies" are manufactured for the dual purposes of evading the responsibility and imaginary control, the methodologies don't materially reduce risk of failures. Therefore, the "software development methodology" fads usually wear out within several years, only to be replaced by even more outrageous and stressful system.
Buzzword treadmill describes the process of replacing worn-out harmful "software development methodology" with new one.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2016-11-25 11:32 pm (UTC)no subject
Date: 2016-11-25 11:34 pm (UTC)no subject
Date: 2016-11-25 11:56 pm (UTC)no subject
Date: 2016-11-26 12:02 am (UTC)I've noticed recently that the levels of perception of software complexity are similar to languages complexity levels. Finite, regular, context free, general.
Sys admins, and many managers, believe that you can just put together individual pieces, and caboom, you have a system. Well, no, there are loops.
So the next level of ignorance is assuming that you can write everything by just using loops. That's c/java/php/python style. Write a loop, and process your data. Map/reduce is almost here, except that the notion of monoid is too abstract for these people. But using regexes for HTML parsing is a typical application of this level of ignorance.
Then comes context-free approach. We slap things together using mutual recursion; it works if the language of the system is context free. It rarely is, but Haskell people believe it's okay to assume. At this level people look down at those below: they can write a parser, and those below can't. The extreme case is understanding that some fixpoint may be a solution.
I can't go higher, my level ends here. What Kiselyov writes, what Kmett writes, I don't feel it. I don't feel this: http://thedeemon.livejournal.com/67223.html - although kind of moving there.
But regular managers don't get even the first level. They believe in magic. They have a magic whip. And they say the words, and it just happens. They don't have to move blocks, deploy anything. All they should know is the right spell. The right buzzword. Every time they hear something they don't understand, they call it "unprofessional".
no subject
Date: 2016-11-26 12:09 am (UTC)Wow!
no subject
Date: 2016-11-26 02:16 pm (UTC)What and more general HOW do think managers (and does they think at all) I dunno. %)
About loops... I dunno from where you took such a notion??? %)
About "can write a parser" is more like "know that task can be done by writing a parser (or any other pattern)" POW. ;)
About last one... did you ever tryed your own project?
To build something not so simpe... for example something that need instalation and as that installation suite?
no subject
Date: 2016-11-27 10:24 pm (UTC)no subject
Date: 2016-11-28 07:00 am (UTC)еще существует реальный мир, с его фактами, логикой, физикой и химией наконец.
А у вас получается какой-то позорный субъективизм "все зависит от точки зрения".
Не все.
Очень даже небольшая, и хорошо локализируемая, часть.
no subject
Date: 2016-11-28 05:41 pm (UTC)no subject
Date: 2016-11-29 07:17 am (UTC)что если планируешь что-то делать В ЭТОМ РЕАЛЬНОМ МИРЕ,
то необходимо воспринимать его как абсолютно реальный,
сиречь материальный.
"Но можна этого и не делать, если вас не интересует результат..." (С)
А рассуждать про какие-то идеально-субъективные материи...
можно только сохраняя свою жопу в тепле старого продавленого по контура тела дивана...
потому что ИНАЧЕ, как только оттуда вылезешь,
тут же почувствуешь настоящие холод, жару,
или еще какую "бяку" неприятное ощущение... %)))
no subject
Date: 2016-11-29 07:32 am (UTC)М-д-я-я
Date: 2016-11-29 11:02 am (UTC)no subject
Date: 2016-11-29 08:15 am (UTC)то необходимо воспринимать его как абсолютно реальный,
сиречь материальный.
Хотелось бы попытаться обратить Ваше внимание что предложенная тема обсуждения касается разработки программного обеспечения, весьма удаленного в силу природы вещей от РЕАЛЬНОГО мира.
М-д-я-я
Date: 2016-11-29 11:02 am (UTC)no subject
Date: 2016-11-26 02:23 pm (UTC)Да и вообще... автора стоит почитать
Date: 2016-11-27 08:41 am (UTC)И что же? Они быстро осознали некую свою «кастовость» и стали диктовать условия руководителям работ. Чтобы поднять цену своего труда, они старались как можно меньше документировать процесс программирования, держать его в собственной памяти, что вскоре стало узким местом при работе над МиГ-31. Наш коллектив быстро раскусил такую тактику, и мы предприняли ряд попыток создать автоматизированные системы программирования, проверки программ, выпустить ГОСТы…
Это не вызвало большого энтузиазма в рядах разработчиков программ, они не очень охотно нас поддерживали в подобных начинаниях. Только в 90-е годы нам удалось создать систему нужных стандартов, когда мы перешли на языки высокого уровня, получили быстродействующие машины, и программирование из искусства превратилось в ремесло. Американцам было проще — они опережали нас в создании электронной базы, а мы, с худшим оборудованием, вынуждены были действовать по принципу «голь на выдумку хитра». И в математике мы поэтому вышли на уровень искусства. Так что МиГ-31 как бы подстегнул процесс создания сложных программных комплексов. ""
http://jlm-taurus.livejournal.com/93413.html
Не только вам приходит в голову...
Date: 2016-11-27 04:18 pm (UTC)2 уровень. Самый тупой гастарбайтер. Встречается не очень часто. Может исключительно копать, носить, перемешивать и т.п. За ним все время надо смотреть. Потому как вопросов о то можно ли бросать новые биметаллические батареи на бетонный пол у него не возникнет. Также как и то, можно ли размешивать краску прямо на новом паркетном полу.
3 уровень. Обычный работяга. Самый популярный кадр на стройке. В принципе, ему можно поручить любую простую работу. Он ее может делать старательно. Даже сам следить за качеством и позвать старшего, если возникнут проблемы. Но стремления к совершенствованию нету, как класс. Основная мотивация – быстрее сделать и больше получить. Классическая проблема с этим уровнем типа: забыл сказать, что надо перед закапыванием канавы положить трубу- закапали без трубы. Забыл сказать, что кровельный материал надо укладывать цветной стороной наружу – уложили как попалось. И т.п.
4 уровень. Мастер. Человек хорошо понимает категории качества. Ориентируется в том, что для этого качества необходимо. Может организовать закупку качественных материалов и их правильное использование. Идеальный человек для простого домашнего ремонта. Основная проблема – ему очень сложно браться за неопределенные задачи. Требуется все разжевать. Если есть сомнения, старается всячески избежать браться за работу. Часто с такими специалистами проблема в том, что они не готовы браться за всю работу (например, за весь ремонт), если не ориентируются в какой-либо части. Не готовы привлекать коллег спецов в смежных областях.
5 уровень. Прораб. Дизайнер Специалист готов придумывать решение разнообразных проблем. В том числе через привлечение разнообразных сторонних специалистов. Хорошо решает задачу сведения концов с концами. Хороший прораб может из себя и вокруг себя сделать небольшую строительную компанию. Но без него она ничего не стоит. Основная проблема прорабов – непонимание истоков разнообразных технологий и задач. В рамках заказа они могут действовать, но при попытке выйти за рамки начинают совершать многочисленные ошибки.
6 уровень. Инженер. Архитектор. Весьма редкие кадры. Понимают что, где, как надо строить.
7 уровень. Инженер-исследователь Ученый. Изучает законы природы влияющие на строительные технологии. Самые разные, от климата до социальной инженерии.
Уровни в IT.
...""
http://man-with-dogs.livejournal.com/2410133.html
ЗЫ Интересно кк вы себя видите в ЭТОЙ иерархии? ;)
Re: Не только вам приходит в голову...
Date: 2016-11-27 04:21 pm (UTC)Re: Не только вам приходит в голову...
Date: 2016-11-28 06:18 am (UTC)no subject
Date: 2016-11-26 02:46 pm (UTC)Осталось сущая мелочь -- начать выписывать базворды и как они исчезают... но тогда, упс, нет ничего подобного описаного
no subject
Date: 2016-11-26 09:06 pm (UTC)Не описано как они исчезают? Прекрасно описано - когда в индустрии начинает формироваться консенсус что и эта методология не работает.
no subject
Date: 2016-11-27 06:33 am (UTC)