Можно ли написать программу, не имея никакой документации и техзадания?
=========================================================================

 Весь август потратил на написание программы так, как мне нравится. До этого был опыт в других областях(печальный), есть подозрение, что нужна документация, соответствующая по размерам и сложности написанному софту. Вот есть статьи на Хабре, в Википедии, рассчитаны на проектирование командой специалистов(бездельников от разработки?), для меня бесполезны. У меня сейчас 11000 строк кода. Раньше рассчитывал взять UML-редактор и спроектировать всё, что нужно, сейчас терзают сомнения. Вопросы:  

1. Нужна документация сразу в UML или сначала требования на уровне страницы текста в Word?  

2. Если я сейчас не напишу требований вовсе, чем это грозит?  

3. А вот я возьму и напишу всё так, как вижу. А спустя полгода выяснится, что нужно было по-другому, а написано неэффективно, и коду это помогло на уровне статистической погрешности. Это уважительная причина, чтобы дальше писать без требований? 

 Спрашиваешь... так делают процентов 90. Другое дело - правильно ли они поступают при этом? Часто документацию путают с проектированием. Это разные вещи и у них разные цели.   
  

Проектировать нужно обязательно, это существенно удешевляет разработку. При этом можно использовать UML или банальные блок-схемы, не имеет значение. Иногда это может поместиться в голове, но чаще это лучше где-то записать. И тут мы плавно приходим к документации.  
  

Плюсы документации в том, что проектное решение можно подготовить сейчас, а реализацию перенести на потом (и ничего важного не забудится по дороге), либо можно обсудить решение с кем-то, выявить риски, передать на реализацию кому-то.  
  

Минусы документации в том, что она быстро устаревает и ее поддерживать довольно дорого и затратно по времени.  

Таким образом, ключевым является вопрос о целях документации. Из этого будут ответы и по указанным пунктам.  
  

1. Зависит от сложности/объема задачи. Если все помещается в голове, то для чего тогда документация? Любая, UML или текст, не важно. Если что-то нужно продумать, то можно записать на доске/бумаге, сфоткать, потом выбросить.  
  

2. Без требований мы не знаем что должно было получиться. Для начальной стадии продукта это вполне приемлемо. Основной риск - в регрессе функциональности. Смотрим код и не понимаем для чего он тут нужен и как оно должно работать, меняем как-то и в итоге ломаем ранее реализованную функциональность. Такие риски необязательно решаются документированием требований в форме ТЗ, можно обходиться и автоматизированным тестированием.  
  

3. Уважительной причиной чего-то не делать будет четкое понимание того, как связанные с этим риски минимизируются. Долой догмы. Если в среднесрочной перспективе мы четко осознаем, что фиксация/документирование требований не принесет пользы, то зачем тратить на это время/ресурсы? 

 Если все что вы знаете о программе, вы и дальше собираетесь держать у себя в голове, и никогда и ни с кем этим знанием не делиться, то можно не писать никаких документов. 

 Наверное, сначала вам надо задать себе главный вопрос: "А зачем мне документация"?  
  

"Есть подозрение" - это не причина. Документация создается для того, чтобы подойти к главной цели - зарабатыванию денег (посредством снижения косвенных затрат и/или повышения косвенной прибыли). Под затратами и прибылью понимаются не только непосредственно деньги, но и время (которое, как известно, тоже деньги), нервы и т.п.  
  

Если у вас нет подобных мыслей на текущий момент - вам не нужна документация.  

Если есть - составьте список текущих проблем.