<story><title>Theory-building and why employee churn is lethal to software companies</title><url>https://www.baldurbjarnason.com/2022/theory-building/</url></story><parent_chain><item><author>twawaaay</author><text>I specialise in joining teams with problems (inability to ship, reliability issues, performance issues, etc.)&lt;p&gt;At least thrice I joined teams where all original developers and the manager was long gone. The situation for some reason looked very similar in all cases. The team is complaining about supposedly bad design that is preventing them from getting work done. But the system is also large and complex and they are unable to fix&amp;#x2F;rewrite it.&lt;p&gt;Lo and behold, in two out of three cases I found that the original developers actually did pretty good job designing the system but in all cases any one of new developers understands only small part of the design and is unable to contribute changes across the entire system, there is a core of the system that nobody understands even though everybody uses and the team has made changes that are against original ideas of the system quickly creating more problems and exploding complexity.&lt;p&gt;In all cases developers are only able to comfortably do some kinds of changes to the system that are routinely done (like adding new fields to forms, messages, etc.) that do not change how the system functions. Changing the basic structure of the system is a taboo.&lt;p&gt;In essence, developers treat &amp;quot;legacy&amp;quot; code as if it was some kind of framework or language runtime -- to be used but never to be studied to have its internals understood. (I will never understand this approach to development)&lt;p&gt;Making &amp;quot;non-standard&amp;quot; changes (yes, one team used this exact term!) pretty much always ends up with something resembling long archeological expedition with ancient traps, diseases and wild animals.</text></item></parent_chain><comment><author>belfalas</author><text>&lt;i&gt;&amp;gt; In essence, developers treat &amp;quot;legacy&amp;quot; code as if it was some kind of framework or language runtime -- to be used but never to be studied to have its internals understood. (I will never understand this approach to development)&lt;/i&gt;&lt;p&gt;I was baffled by this as well for 15+ years until just last year I had a key insight: most developers don’t like to read. In fact, most people don’t like to read. Most people are intrinsically lazy and since growing your skills involves hard work, they don’t do it unless pushed to do so, either by life circumstance or necessity.&lt;p&gt;Time and time again people have asked me: “how do I get really good at $tech or software engineering?” I recommend a few books or send them my standard list of must-reads. In 999&amp;#x2F;1000 cases the person approaching me gives me that defeated look that I know means: “Oh. I was hoping you’d say something not involving working hard.” Most people are polite enough not to say it to my face.&lt;p&gt;When folks have problems with HTTP I ask them if they’ve read RFC 2616, and if not, I offer to bring them a nicely printed and bound copy. It typically goes unread though some use it as a reference. Only once did someone follow my recommendation and read it cover to cover.&lt;p&gt;Folks seems to lack a kind of basic economic perspective. Spend a week, month, something along those lines growing your skills (or even just 30 minutes reading the docs on that thing you just spent 2 hours declaring idiotic). Yes, this means probably giving up your favorite Netflix binge, video game, or drinking on weeknights in favor of study. But once these skills are internalized they pay back for a lifetime with good returns. Yet for some strange reason people prefer to keep thinking short term and so they never learn what they’re doing. It used to make me sad but I’m making peace with it.</text></comment>
<story><title>Theory-building and why employee churn is lethal to software companies</title><url>https://www.baldurbjarnason.com/2022/theory-building/</url></story><parent_chain><item><author>twawaaay</author><text>I specialise in joining teams with problems (inability to ship, reliability issues, performance issues, etc.)&lt;p&gt;At least thrice I joined teams where all original developers and the manager was long gone. The situation for some reason looked very similar in all cases. The team is complaining about supposedly bad design that is preventing them from getting work done. But the system is also large and complex and they are unable to fix&amp;#x2F;rewrite it.&lt;p&gt;Lo and behold, in two out of three cases I found that the original developers actually did pretty good job designing the system but in all cases any one of new developers understands only small part of the design and is unable to contribute changes across the entire system, there is a core of the system that nobody understands even though everybody uses and the team has made changes that are against original ideas of the system quickly creating more problems and exploding complexity.&lt;p&gt;In all cases developers are only able to comfortably do some kinds of changes to the system that are routinely done (like adding new fields to forms, messages, etc.) that do not change how the system functions. Changing the basic structure of the system is a taboo.&lt;p&gt;In essence, developers treat &amp;quot;legacy&amp;quot; code as if it was some kind of framework or language runtime -- to be used but never to be studied to have its internals understood. (I will never understand this approach to development)&lt;p&gt;Making &amp;quot;non-standard&amp;quot; changes (yes, one team used this exact term!) pretty much always ends up with something resembling long archeological expedition with ancient traps, diseases and wild animals.</text></item></parent_chain><comment><author>jacobsenscott</author><text>&amp;gt; as much as possible, do not allow custom patterns&amp;#x2F;structures&lt;p&gt;This is key. Most engineers want to build frameworks instead of applications. But leave the frameworks to the framework builders unless you were hired to build a framework.&lt;p&gt;I can jump into a 10 year old rails code base and be productive right away if they stuck to the framework defaults. But invariably someone read some blog posts about how &amp;quot;rails doesn&amp;#x27;t scale&amp;quot; and built some rats nest of service objects&amp;#x2F;decorators&amp;#x2F;portsAndAdapters wtfs and it takes some serious code spelunking to figure out what&amp;#x27;s going on (hint - the end result is always creating or updating a database record, or making a single api call).&lt;p&gt;I would argue microservices also encourage bitrot. You can leave some service running on some ancient libraries for years it doesn&amp;#x27;t need changes. But if you have a monolith where you constantly keep the dependencies up to date - everything stays up to date.</text></comment>