?

Log in

Ничего святого
Совсем ничего
Buzzword treadmill 
26th-Nov-2016 12:45 am
lem
      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.
Comments 
25th-Nov-2016 11:32 pm (UTC)
Очень хорошо. Откуда это?
25th-Nov-2016 11:34 pm (UTC)
Это я написал.
25th-Nov-2016 11:56 pm (UTC)
Самый удачный и успешный софтвер-проект у меня был в универе. Мне с корешом было отведено на него 13 недель. Первые восемь наш научный руководитель мордовал нас дизайном, запрещая вообще приближаться к коду. Каждую неделю из этих восьми он давал нам список каверзных вопросов и разбирал наши ответы. В конце восьмой недели он сказал: ну, все, теперь переводите ваши ответы с английского на С. Проект был завершен к концу 11 недели.
26th-Nov-2016 12:02 am (UTC)
Wow, well said! Thank you!

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".
26th-Nov-2016 12:09 am (UTC)
But using regexes for HTML parsing is a typical application of this level of ignorance.

Wow!
26th-Nov-2016 02:16 pm (UTC)
Its not what sysadmins think, its more like what they asked...

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?
27th-Nov-2016 10:24 pm (UTC)
See, here's the problem. Everyone has a limit of understanding. We have to push it, but it's hard. So Dunning-Krueger helps us think we are perfectly okay, and everything above our level is just irrelevant. It's a big problem, but it's ubiquitous.
28th-Nov-2016 07:00 am (UTC)
Кроме наших (ограниченных) способностей,
еще существует реальный мир, с его фактами, логикой, физикой и химией наконец.

А у вас получается какой-то позорный субъективизм "все зависит от точки зрения".

Не все.
Очень даже небольшая, и хорошо локализируемая, часть.
28th-Nov-2016 05:41 pm (UTC)
Уж не претендуете ли вы на абсолютность ваших знаний о реальном мире?
29th-Nov-2016 07:17 am (UTC)
Я претендую на то,
что если планируешь что-то делать В ЭТОМ РЕАЛЬНОМ МИРЕ,
то необходимо воспринимать его как абсолютно реальный,
сиречь материальный.

"Но можна этого и не делать, если вас не интересует результат..." (С)

А рассуждать про какие-то идеально-субъективные материи...
можно только сохраняя свою жопу в тепле старого продавленого по контура тела дивана...
потому что ИНАЧЕ, как только оттуда вылезешь,
тут же почувствуешь настоящие холод, жару,
или еще какую "бяку" неприятное ощущение... %)))
29th-Nov-2016 07:32 am (UTC)
Ну в смысле если машину куда вести, так лучше воспринимать так, да. А если софтвер, так это, тут как посмотреть.
29th-Nov-2016 11:02 am (UTC) - М-д-я-я
Оно и видно (С)
29th-Nov-2016 08:15 am (UTC)
что если планируешь что-то делать В ЭТОМ РЕАЛЬНОМ МИРЕ,
то необходимо воспринимать его как абсолютно реальный,
сиречь материальный.


Хотелось бы попытаться обратить Ваше внимание что предложенная тема обсуждения касается разработки программного обеспечения, весьма удаленного в силу природы вещей от РЕАЛЬНОГО мира.
29th-Nov-2016 11:02 am (UTC) - М-д-я-я
Оно и видно (С)
26th-Nov-2016 02:23 pm (UTC)
And... that written in this post are merely the same what vit_r like to talk about ;)
27th-Nov-2016 04:18 pm (UTC) - Не только вам приходит в голову...
""Уровни на стройке.

2 уровень. Самый тупой гастарбайтер. Встречается не очень часто. Может исключительно копать, носить, перемешивать и т.п. За ним все время надо смотреть. Потому как вопросов о то можно ли бросать новые биметаллические батареи на бетонный пол у него не возникнет. Также как и то, можно ли размешивать краску прямо на новом паркетном полу.

3 уровень. Обычный работяга. Самый популярный кадр на стройке. В принципе, ему можно поручить любую простую работу. Он ее может делать старательно. Даже сам следить за качеством и позвать старшего, если возникнут проблемы. Но стремления к совершенствованию нету, как класс. Основная мотивация – быстрее сделать и больше получить. Классическая проблема с этим уровнем типа: забыл сказать, что надо перед закапыванием канавы положить трубу- закапали без трубы. Забыл сказать, что кровельный материал надо укладывать цветной стороной наружу – уложили как попалось. И т.п.

4 уровень. Мастер. Человек хорошо понимает категории качества. Ориентируется в том, что для этого качества необходимо. Может организовать закупку качественных материалов и их правильное использование. Идеальный человек для простого домашнего ремонта. Основная проблема – ему очень сложно браться за неопределенные задачи. Требуется все разжевать. Если есть сомнения, старается всячески избежать браться за работу. Часто с такими специалистами проблема в том, что они не готовы браться за всю работу (например, за весь ремонт), если не ориентируются в какой-либо части. Не готовы привлекать коллег спецов в смежных областях.

5 уровень. Прораб. Дизайнер Специалист готов придумывать решение разнообразных проблем. В том числе через привлечение разнообразных сторонних специалистов. Хорошо решает задачу сведения концов с концами. Хороший прораб может из себя и вокруг себя сделать небольшую строительную компанию. Но без него она ничего не стоит. Основная проблема прорабов – непонимание истоков разнообразных технологий и задач. В рамках заказа они могут действовать, но при попытке выйти за рамки начинают совершать многочисленные ошибки.

6 уровень. Инженер. Архитектор. Весьма редкие кадры. Понимают что, где, как надо строить.

7 уровень. Инженер-исследователь Ученый. Изучает законы природы влияющие на строительные технологии. Самые разные, от климата до социальной инженерии.

Уровни в IT.

...""

http://man-with-dogs.livejournal.com/2410133.html

ЗЫ Интересно кк вы себя видите в ЭТОЙ иерархии? ;)
27th-Nov-2016 04:21 pm (UTC) - Re: Не только вам приходит в голову...
Бывает что от излишнего умствования мозг распухает и начинает давить изнутри на черепную коробку, порождая удивительные состояния сознания и тексты. И это один из них.
28th-Nov-2016 06:18 am (UTC) - Re: Не только вам приходит в голову...
"У любого вопроса есть только два ответа: мой... и неправильный", да? %)))
26th-Nov-2016 02:46 pm (UTC)
\\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.

Осталось сущая мелочь -- начать выписывать базворды и как они исчезают... но тогда, упс, нет ничего подобного описаного
26th-Nov-2016 09:06 pm (UTC)
Осталось сущая мелочь -- начать выписывать базворды и как они исчезают... но тогда, упс, нет ничего подобного описаного

Не описано как они исчезают? Прекрасно описано - когда в индустрии начинает формироваться консенсус что и эта методология не работает.
27th-Nov-2016 06:33 am (UTC)
Как вам будет угодно...
This page was loaded Jul 23rd 2017, 2:45 pm GMT.