4 ms·

That's funny because I have become, and observe the exact opposite. The notion of trying to make things more complex than they need to be I find deeply problem

That's funny because I have become, and observe the exact opposite. The notion of trying to make things more complex than they need to be I find deeply problematic. Junior engineers often end up devising solutions which are in fact too complex as they try to over engineer everything. The more experience I have, the more I accept that code is complexity and cost and that it should be avoided. Always take the easy path unless there are very good reasons not to ... because you'll never know where you need to actually pivot when you get there. To your point (not more complex than they actually are) - yes, there is sometimes inherent complexity in the problem space that can't be avoided - but that doesn't mean the solution actually needs to be complicated. Domain complexity might possibly be well encapsulated, leaving the rest of the system fairly straight forward.

stevenjohns 8y ago
> Junior engineers often end up devising solutions which are in fact too complex as they try to over engineer everything. > The more experience I have, the more I accept that code is complexity and cost and that it should be avoided. At a previous company I worked for I proposed a solution which was considered to be too "complex" by the VP R&D. So he and another "Senior" turned around and rewrote it into something more "simple." This "simplicity" slowly turned into a constantly patched clusterfuck of a mess and it stripped off a dozen different ways of customization. The "simplicity" was produced as a consequence of both of the Senior engineer's ignorance towards to the tools (language, frameworks) we were using and they just went with their gut experience on it. I'm somewhat different to you I guess. As things go on, I realise that simplicity is usually a hallmark of developers who don't really understand the tools they're working with and can't really foresee where the business would be going with that feature in 12 to 24 months. It's a symptom of "Jira culture," where people develop things exclusively to satisfy their ticket and ignore the bigger picture of what they're actually trying to achieve. This is not to discount people over-engineering things, but over-engineering is very different from complexity.
- genericone 8y ago
  Looks like the two of you have a different worldview about what 'simplicity' means.
  - 0xdeadbeefbabe 8y ago
    It really nice of you to notice. Some crusaders still think it's about complex vs simple.
  - BigJono 8y ago
    This is because people don't realise that there are two axes on the simplicity/complexity graph, not one. So they're operating on different definitions of 'simple'. You can make the development experience simpler, and/or you can make the software simpler. Usually a change to one will have an inverse affect on the other. Bringing in a library will almost always make dev simpler (unless the API is more complex than whatever it's abstracting, which only seems to happen in JS land), but it's also guaranteed to make your software more complex (unless it does exactly what you need with no config, and nothing more).
013a 8y ago
I tend to observe that junior engineers simply misplace the level of complexity that a system needs in order to be as simple as possible. Meaning, I've seen errors to the side of being too simple, and errors to the side of being too complex; the unifying theory here is that its a mis-estimation of "necessary complexity". Two examples: In designing an email templating system, I've seen junior engineers devise really complex class hierarchies, with super classes that take in type generics for their super() constructor, three levels deep, resulting in hundreds of lines of code. When pressed, the reasoning was "there are parts of the email body we want to be the same and parts that are different, so the class hierarchies map to those parts that are similar vs different." It turns out, this service was only sending 3 different email "types" for the foreseeable future, and the only similarity between them was a copyright notice at the bottom, a banner at the top, and a body. But, a counterpoint: For a long while, on some node.js backend API we were writing, much of the core business logic was implemented as simple functions across hundreds of files. Worked great when we had four API routes. Now, with hundreds, its impossible to find anything, because there's no structure, patterns, or organization. So, we needed someone to step in and introduce rules and structure in order to make the system more simple, and our job would have been easier if we'd had the foresight to see that necessary complexity coming.
- sonnyblarney 8y ago
  Surely good examples, but the later may have been the right path: start simple with what is necessary. When there is a need for a framework or some layer of complexity - add it then. But maybe not before. And #1 is funny because we've all done something like that!
- mbrameld 8y ago
  > In designing an email templating system, I've seen junior engineers devise really complex class hierarchies, with super classes that take in type generics for their super() constructor, three levels deep, resulting in hundreds of lines of code. When pressed, the reasoning was "there are parts of the email body we want to be the same and parts that are different, so the class hierarchies map to those parts that are similar vs different." It turns out, this service was only sending 3 different email "types" for the foreseeable future, and the only similarity between them was a copyright notice at the bottom, a banner at the top, and a body. Was there a discussion about high-level design of the templating system at all before the junior started banging out code? This feels more like a failure of the senior/lead. > But, a counterpoint: For a long while, on some node.js backend API we were writing, much of the core business logic was implemented as simple functions across hundreds of files. Worked great when we had four API routes. Now, with hundreds, its impossible to find anything, because there's no structure, patterns, or organization. So, we needed someone to step in and introduce rules and structure in order to make the system more simple, and our job would have been easier if we'd had the foresight to see that necessary complexity coming. This feels like a false dichotomy to me. Your system existed in a state somewhere between between 4 routes and hundreds, didn't it? At the point something starts being painful is when it should be addressed, imo. That was probably somewhere in the teens of routes would be my guess. At that point the system is still small and understandable enough to make a large architectural change, but it's big enough that you can be reasonably certain you're making the correct large architectural change.
diminoten 8y ago
This logic is a great justification to commit many unnecessary tragedies, because it gives you an escape valve to not put effort into anything you don't want to do. "It's more complex to write unit tests/write this so it's easy to unit test, so I won't bother". "It's more complex to spend a few days thinking through the design of this system, so I won't bother." "It's more complex to write this in a way that can be subclassed later, so I won't bother." Perfect may be the enemy of good, but "easy" can also be a foe.
austincheney 8y ago
I think that is a misunderstanding between the problem and the solution. The ideal scenario is to take a complex problem and devise a simple solution. Problems are not made more complex. They are literally the requirements provided. From an economic perspective, the problem is. The complexity is in how a person receives those requirements (perception of approach). This is lost on someone when a problem is more fully exposed according to potential second and third consequences (risks). When everything is ad hoc the risks are never exposed until a mountain of code is written that ends up being not simple and excessively fragile. To avoid the unforeseen stupidity I prefer to expose the complexity up front and try to prevent people from hiding from it. That doesn't change the problem statement, the environment, the end user, or anything else. It only changes the investment of effort and the person providing that effort. Burying your code in layers of unnecessary abstraction and mountains of dependencies is not exercise in simplicity because somebody has successfully avoided writing original code. This is the difference between simple and easy.

stevenjohns 8y ago

> Junior engineers often end up devising solutions which are in fact too complex as they try to over engineer everything. > The more experience I have, the more I accept that code is complexity and cost and that it should be avoided. At a previous company I worked for I proposed a solution which was considered to be too "complex" by the VP R&D. So he and another "Senior" turned around and rewrote it into something more "simple." This "simplicity" slowly turned into a constantly patched clusterfuck of a mess and it stripped off a dozen different ways of customization. The "simplicity" was produced as a consequence of both of the Senior engineer's ignorance towards to the tools (language, frameworks) we were using and they just went with their gut experience on it. I'm somewhat different to you I guess. As things go on, I realise that simplicity is usually a hallmark of developers who don't really understand the tools they're working with and can't really foresee where the business would be going with that feature in 12 to 24 months. It's a symptom of "Jira culture," where people develop things exclusively to satisfy their ticket and ignore the bigger picture of what they're actually trying to achieve. This is not to discount people over-engineering things, but over-engineering is very different from complexity.

genericone 8y ago
Looks like the two of you have a different worldview about what 'simplicity' means.
- 0xdeadbeefbabe 8y ago
  It really nice of you to notice. Some crusaders still think it's about complex vs simple.
- BigJono 8y ago
  This is because people don't realise that there are two axes on the simplicity/complexity graph, not one. So they're operating on different definitions of 'simple'. You can make the development experience simpler, and/or you can make the software simpler. Usually a change to one will have an inverse affect on the other. Bringing in a library will almost always make dev simpler (unless the API is more complex than whatever it's abstracting, which only seems to happen in JS land), but it's also guaranteed to make your software more complex (unless it does exactly what you need with no config, and nothing more).

013a 8y ago

I tend to observe that junior engineers simply misplace the level of complexity that a system needs in order to be as simple as possible. Meaning, I've seen errors to the side of being too simple, and errors to the side of being too complex; the unifying theory here is that its a mis-estimation of "necessary complexity". Two examples: In designing an email templating system, I've seen junior engineers devise really complex class hierarchies, with super classes that take in type generics for their super() constructor, three levels deep, resulting in hundreds of lines of code. When pressed, the reasoning was "there are parts of the email body we want to be the same and parts that are different, so the class hierarchies map to those parts that are similar vs different." It turns out, this service was only sending 3 different email "types" for the foreseeable future, and the only similarity between them was a copyright notice at the bottom, a banner at the top, and a body. But, a counterpoint: For a long while, on some node.js backend API we were writing, much of the core business logic was implemented as simple functions across hundreds of files. Worked great when we had four API routes. Now, with hundreds, its impossible to find anything, because there's no structure, patterns, or organization. So, we needed someone to step in and introduce rules and structure in order to make the system more simple, and our job would have been easier if we'd had the foresight to see that necessary complexity coming.

sonnyblarney 8y ago
Surely good examples, but the later may have been the right path: start simple with what is necessary. When there is a need for a framework or some layer of complexity - add it then. But maybe not before. And #1 is funny because we've all done something like that!
mbrameld 8y ago
> In designing an email templating system, I've seen junior engineers devise really complex class hierarchies, with super classes that take in type generics for their super() constructor, three levels deep, resulting in hundreds of lines of code. When pressed, the reasoning was "there are parts of the email body we want to be the same and parts that are different, so the class hierarchies map to those parts that are similar vs different." It turns out, this service was only sending 3 different email "types" for the foreseeable future, and the only similarity between them was a copyright notice at the bottom, a banner at the top, and a body. Was there a discussion about high-level design of the templating system at all before the junior started banging out code? This feels more like a failure of the senior/lead. > But, a counterpoint: For a long while, on some node.js backend API we were writing, much of the core business logic was implemented as simple functions across hundreds of files. Worked great when we had four API routes. Now, with hundreds, its impossible to find anything, because there's no structure, patterns, or organization. So, we needed someone to step in and introduce rules and structure in order to make the system more simple, and our job would have been easier if we'd had the foresight to see that necessary complexity coming. This feels like a false dichotomy to me. Your system existed in a state somewhere between between 4 routes and hundreds, didn't it? At the point something starts being painful is when it should be addressed, imo. That was probably somewhere in the teens of routes would be my guess. At that point the system is still small and understandable enough to make a large architectural change, but it's big enough that you can be reasonably certain you're making the correct large architectural change.

diminoten 8y ago

This logic is a great justification to commit many unnecessary tragedies, because it gives you an escape valve to not put effort into anything you don't want to do. "It's more complex to write unit tests/write this so it's easy to unit test, so I won't bother". "It's more complex to spend a few days thinking through the design of this system, so I won't bother." "It's more complex to write this in a way that can be subclassed later, so I won't bother." Perfect may be the enemy of good, but "easy" can also be a foe.

austincheney 8y ago

I think that is a misunderstanding between the problem and the solution. The ideal scenario is to take a complex problem and devise a simple solution. Problems are not made more complex. They are literally the requirements provided. From an economic perspective, the problem is. The complexity is in how a person receives those requirements (perception of approach). This is lost on someone when a problem is more fully exposed according to potential second and third consequences (risks). When everything is ad hoc the risks are never exposed until a mountain of code is written that ends up being not simple and excessively fragile. To avoid the unforeseen stupidity I prefer to expose the complexity up front and try to prevent people from hiding from it. That doesn't change the problem statement, the environment, the end user, or anything else. It only changes the investment of effort and the person providing that effort. Burying your code in layers of unnecessary abstraction and mountains of dependencies is not exercise in simplicity because somebody has successfully avoided writing original code. This is the difference between simple and easy.