The collapse of complex software
I appreciated this essay.<p>Among other things, it suggests that there are some incentives for complexity: That engineers just <i>enjoy</i> complexity, and that making simple designs might not be good for the respect of your peers&#x2F;bosses&#x2F;career: &quot;A simple design might make it seem like you’re not really doing your job.&quot;<p>While that&#x27;s true, I think the essay isn&#x27;t clear enough about the fact that <i>simplicity is just plain hard</i>.  Complexity is sort of the &quot;natural&quot; outcome of &quot;adding things&quot;.  It takes time, effort, and <i>skill</i> to create software that can do what is asked for it while maintaining an internal simplicity. Even <i>if</i> everyone involved <i>really wants</i> it.  I do not think software complexity comes only, or mainlly, from people <i>not wanting it enough</i> (explicitly or implicity), from incentives to complexity. It&#x27;s just plain hard. It&#x27;s a mistake to think just <i>wanting it harder</i> (or having the right incentives) is sufficient.<p>It may be the key challenge in software engineering -- how do we make software that does everything that&#x27;s asked for it (powerful, complex things), while maintaining an internal simplicity? You can not accomplish it by cargo-culting any &quot;design patterns&quot; or other approaches. It&#x27;s still a skilled craft. That comes from years of experience with the <i>intent</i> of developing this skill (years of experience alone aren&#x27;t enough), looking at other people&#x27;s code who are also trying to do it, and just some aptitude. And <i>domain knowledge</i>, if you understand the nature of the problems you are working on better, you can design simple solutions for them better--contrary to some current practices treating developers as interchangeable.<p>Yes, you need your organization to <i>allow</i> you to do it (including taking the <i>more time</i> it <i>will</i> take), but that&#x27;s necessary but not sufficient for the outcome.