<story><title>Web Programming Is Getting Unnecessarily Complicated</title><url>http://en.arguman.org/web-programming-is-getting-unnecessarily-complicated</url></story><parent_chain><item><author>Falkon1313</author><text>In my early days of programming, things began with realizing that I could use this wonderfully powerful system to solve problems (almost any problem you could model!) and create things (almost anything you could want to simulate!).  I just had to figure out how to model the domain problem logically in a useful way, or what aspects of something to simulate, and how to allow the user to interact with it.&lt;p&gt;That soon changed.  In learning about programming, one can&amp;#x27;t help but to come across the writings of those preaching the gospel of the holy virtues of &amp;#x27;reusable code&amp;#x27;.  Modular code, libraries, object-oriented code, design patterns, frameworks, plugins, APIs, services, stacks and toolchains!&lt;p&gt;So programming is now largely about resolving a ton of dependency issues and getting scores of different modules, frameworks, libraries, APIs, etc. to play nicely with each other.  Instead of using our brainpower to understand and model the domain problems that are ostensibly the reason for our software, we&amp;#x27;re using it trying to figure out how the heck to glom together all this generic abstract code and modify the output to vaguely resemble something in the domain, in a way that won&amp;#x27;t perform so horrendously that customers immediately give up on it.&lt;p&gt;We write hooks, overrides, and underrides to throw out the work that the reusable code is doing and get it to do what we want (more-or-less).  We write translation and adaptation and bridge layers to convert the data structures used by one module to those used by another (and vice-versa) and eventually to something roughly approximating the domain data.  We set up elaborate clusters of interdependent modules, submodules, plugins for our plugins, all on top of a generic framework that wasn&amp;#x27;t even designed with the domain in mind.&lt;p&gt;As a profession, we&amp;#x27;ve gone way too overboard trying to do everything with reusable code.  This is why it can take several hours to do something as simple as change a link (and that can completely break something seemingly-unrelated elsewhere in the system).  And it&amp;#x27;s kind of amusing that we&amp;#x27;re now adding layers of complexity to manage the layers of complexity.&lt;p&gt;I want to get back to focusing on building logical models that fit the domain, solving problems, and simulating things.  For that we need a new doctrine of vertical development that doesn&amp;#x27;t just religiously say &amp;quot;Throw another layer of indirection and generic abstraction on it!  Yay reusable code!&amp;quot; as a sacred solution for everything.  Sure, code reuse can be good, but let&amp;#x27;s be sensible about it, not kid-in-a-candy-store crazy.</text></item></parent_chain><comment><author>tboyd47</author><text>You are correct. I&amp;#x27;ve come to see it as one of many psychological responses of developers to work they feel is beneath their skillset. People with advanced computer science backgrounds often end up in web development just that&amp;#x27;s where the jobs are, and most of the work is not in solving difficult problems. Mostly, you are just pulling data out of a database and displaying it in HTML. The thought of doing that for your entire career as a programmer is intolerable to some people, so they concoct any ingenious scheme they can to rise above it. For some people, this results in an obsession with writing modular code they can re-use. Another response is to delve into obscure, hyper-intellectual programming languages. Another is to become obsessed with markers of system robustness like availability and concurrency to the point where all of your decisions as a programmer optimize for those. I&amp;#x27;ve seen all of these (and been guilty of some of them).&lt;p&gt;The interesting bit is that these people are often very eloquent and convincing in making others believe that they have an objectively better way to program, and that this is THE way to advance in the field, and not just some elaborate game created to stave off boredom. Never mind the fact that you&amp;#x27;re still just doing things like validating phone numbers and moving buttons slightly to the right. This is nothing less than the future of computer science!&lt;p&gt;So you end up with a herd effect where greener or less-capable developers follow these &amp;quot;thought leaders&amp;quot; blindly, resulting in the fragmentation we&amp;#x27;re in now. I find it interesting how &amp;quot;Five Whys&amp;quot; has made its way into dev culture as a line of questioning for business requirements, but never for tech requirements. &amp;quot;It&amp;#x27;s getting more and more popular every day,&amp;quot; or, &amp;quot;It&amp;#x27;s going to look great on your resume,&amp;quot; is often the end of the discussion.</text></comment>
<story><title>Web Programming Is Getting Unnecessarily Complicated</title><url>http://en.arguman.org/web-programming-is-getting-unnecessarily-complicated</url></story><parent_chain><item><author>Falkon1313</author><text>In my early days of programming, things began with realizing that I could use this wonderfully powerful system to solve problems (almost any problem you could model!) and create things (almost anything you could want to simulate!).  I just had to figure out how to model the domain problem logically in a useful way, or what aspects of something to simulate, and how to allow the user to interact with it.&lt;p&gt;That soon changed.  In learning about programming, one can&amp;#x27;t help but to come across the writings of those preaching the gospel of the holy virtues of &amp;#x27;reusable code&amp;#x27;.  Modular code, libraries, object-oriented code, design patterns, frameworks, plugins, APIs, services, stacks and toolchains!&lt;p&gt;So programming is now largely about resolving a ton of dependency issues and getting scores of different modules, frameworks, libraries, APIs, etc. to play nicely with each other.  Instead of using our brainpower to understand and model the domain problems that are ostensibly the reason for our software, we&amp;#x27;re using it trying to figure out how the heck to glom together all this generic abstract code and modify the output to vaguely resemble something in the domain, in a way that won&amp;#x27;t perform so horrendously that customers immediately give up on it.&lt;p&gt;We write hooks, overrides, and underrides to throw out the work that the reusable code is doing and get it to do what we want (more-or-less).  We write translation and adaptation and bridge layers to convert the data structures used by one module to those used by another (and vice-versa) and eventually to something roughly approximating the domain data.  We set up elaborate clusters of interdependent modules, submodules, plugins for our plugins, all on top of a generic framework that wasn&amp;#x27;t even designed with the domain in mind.&lt;p&gt;As a profession, we&amp;#x27;ve gone way too overboard trying to do everything with reusable code.  This is why it can take several hours to do something as simple as change a link (and that can completely break something seemingly-unrelated elsewhere in the system).  And it&amp;#x27;s kind of amusing that we&amp;#x27;re now adding layers of complexity to manage the layers of complexity.&lt;p&gt;I want to get back to focusing on building logical models that fit the domain, solving problems, and simulating things.  For that we need a new doctrine of vertical development that doesn&amp;#x27;t just religiously say &amp;quot;Throw another layer of indirection and generic abstraction on it!  Yay reusable code!&amp;quot; as a sacred solution for everything.  Sure, code reuse can be good, but let&amp;#x27;s be sensible about it, not kid-in-a-candy-store crazy.</text></item></parent_chain><comment><author>marklgr</author><text>Reusable code, frameworks or plugins are fine, the problem is their cambrian explosion since now anyone can jump in and publish some JavaScript or Go code, especially with the micro-stuff trend. So we end up with zillions of projects competing for traction, and we move from one new cool and shiny thing to the next, for all (micro-)components of the stack.&lt;p&gt;This is the often-forgotten cost of competition (for all its merits) as opposed to cooperation: it wastes time and energy.</text></comment>