In a somewhat related direction, I am absolutely convinced that the neophilia and constant complication of otherwise straightforward projects is a neurotic response similar to parrots plucking feathers and mutilating themselves when given not enough to do.
I’ll write about this at length later, but the short summary of it is that developers realize that they’re given often basic tasks and rather than embrace the fact that those problems are always well-solved and could be embraced with just a little bit of pushback on the people side of things and maybe encouraging just buying a solution off-the-shelf or upgrading to better hardware to run that long ETL, they instead fixate on new “best practices” and ignore the creeping existential horrors (mokitas!) that:
most practical interesting problems in CS are solved well, or can be solved by throwing money/hardware at them
businesses make money by making people feel like their problems are solved–not always by solving those problems or even creating anything interesting
developers are at once both overpaid for the drudgery and simple tasks that they do, and underpaid and cut out of the growth of wealth they enable
increasingly the narrative pushed to others is that devs are the source of their problems and they should be shunned
employers don’t actually give a shit about growing their developers
developers are locked-down from owning the fruits of their intellect
And on and on and on. So, of course, we see this neurotic behavior in our industry, and dress it up as something else instead.
I agree with your points, and I’m looking forward to an in-depth article on this topic, if you’re writing one. I had a slightly different take on this article - the part that stood out to me was the disconnect between the interpretation of the requirements from the perspective of the management and the development team. This is a clear indication of dysfunctional management and a lack of organizational maturity for software development (i.e., a lack of formally specified requirements). This reminds me of consulting gigs where I’ve been called in to solve a technical problem, but really uncovered a management problem. Sometimes the communication paths just need to be reset so everyone is on the same page. But if management is incapable of accepting hard truths, they need a lower-ranking scapegoat. This would be the developers. The only lower-ranking scapegoat for developers is the framework, because blaming the requirements pushes the problem back upstream.
This inertia comes in the form of working on imaginary problems in order to avoid fixing real problems. Real problems which, once pointed out, would threaten the jobs of other people. Which may well lead to you getting fired, or in the case of some particularly nasty “institutions” like Goldman Sachs, getting a few brown envelopes sent to a few FBI officers and ruining your whole life or getting you to commit a strange suicide.
He was arrested for working on an imaginary problem? Also, his suicide must have been very strange; he’s still alive.
Am I the only one who sees irony in the author putting all this thought into a problem that could be summarized as people simply being bad at their job?
No. My insight is this: all of his anecdotal examples are examples of people poorly managing time due to poorly prioritizing their work. This fault has many causes such as poor design goals, miscommunication, avoidant behavior, boredom, et al. This is a fault everyone is aware of. The author has recognized this problem and decides to spend time formalizing it, making anecdotal stories, accompanying graphics, and a blog post, when that time could be spent on some aspect of enriching his life or self improvement (unless he finds writing the post enriching which is entirely fine.)
To the extend of the author’s examples, these workers sound bad enough to warrant labeling them as either incompetent or just lazy. In which case, we should just call a spade a spade and force this worker to make a course correction or replace them with someone better. That would be the simple and most straightforward response to the problem, and I am simply pointing out the irony of the author’s response.
I read the article as an extended meditation on the Upton Sinclair quote, “It is difficult to get a man to understand something, when his salary depends upon his not understanding it.”
A story. Years ago, when I was in college, I did some consulting work at a company. My coworker was also a college student (same college, same department). One project was editing a printed manual to put up on an internal Website. The conversion from Microsoft Word to HTML was trivial (Microsoft word provided that much). But not linking each vocabulary word to its definition in the glossary section. There were perhaps a hundred words (it was a specialized industry) and there were some 100 pages to edit.
My coworker wanted to dive right in and do the editing by hand. That was a lot of work. Days worth of mind-numbing work. I wanted to take some time to think about the task and how best to approach it. An argument ensued. We ended up using lex (since we had access to some Unix workstations with everything preloaded) to add the appropriate HTML links to the glossary page for each web page and were done in maybe two hours or so.
Was I smart in finding a quick way to reliably edit the 100 pages? Or was my coworker smart by trying to get X extra days of work even if it was drudgery? [1]
(Yes, I see the relationship of my story to the article, but I’m having a hard time articulating the connection I see. It’s similar to doing badly at ops—the ops who “save the day” with heroics in getting the system back up get the kudos, while the ops who set things up to run smoothly with almost no down-time get laid off because they appear to be doing nothing. Incentives matter.)
[1] And it wasn’t like lex was an unknown tool—my coworker was a grad student in the CS department and had written a compiler using both lex and yacc.
It depends on the point of view. If you were doing it because you honestly thought it was the best solution to the problem at hand, well then you were right, and hopefully your coworker learned a lesson and this isn’t an imaginary problem. If you were doing it for yourself, for your own knowledge, believing that the the skills learned would pay off at a later date, well then that’s up to you to decide but not an imaginary problem.
The second scenario seems falsely conflated with the first. That is a problem, but a different one of management incorrectly valuing their employees.
I would say the act of spending the effort to connect these dots is an imaginary problem. A lot of these characteristics are human nature, which no amount of writing or philosophizing will fix (if the goal is to “fix” the problem).
I understand the meditation on the topic, perhaps in an attempt to clarify to himself a series of problems that his intuition tells him has some tangible connection, which is beneficial for one’s own peace of mind. And to be clear, I am not criticizing the post. I just thought the meta-connection between the post itself and its content was amusing. Contemplating the “metaness” of things is my personal imaginary problem pit.
Edit: A larger point I want to make is that these ARE very complex problems. Knowing which solution is going to be optimal is something that takes either lots of research or experience and intuition. Of course people will choose wrong occasionally and make the problem even worse. Hopefully they learn and make better choices next time. Trying to paper over this experiential process by making it a “problem” (in the first examples in the article) is foolish and can send a message that any mistakes made are self inflicted instead of being part of the process of self-development.
In your scenario, you saved time and money. Real problem.
If the task had instead been to change one web page’s header from h1 to h2 and you had to go out and buy a new sparcstation and compile Perl from scratch, etc., that’s imaginary problem territory.
Imaginary problems seem to be justified by “but what if?” What do the kids say? YAGNI. Perhaps the question can’t be fully resolved until afterwards, in hindsight, but we can at least keep track of which developers seem to correctly identify what ifs. I’d bet some people are prone to under building and some to over building. (And also never learning from those experiences, always erring in the same direction.)
I stopped reading at “I occasionally do freelance work, in the past I couldn’t afford to pick my clients, which means I saw my fair share of dissociative identity disorder and ADHD cases.”
One way an organization can avoid this kind of behavior is to involve developers in the conceptualization of the product. All products have lots of hard and unsolved problems. But in my experience, they are often conceptual problems. When the developer is one of the people forming and testing hypotheses about what would be good for the user, mundane technical work becomes just the last step in achieving something that is challenging and fulfilling: a product that people find useful.
What a delightful read.
In a somewhat related direction, I am absolutely convinced that the neophilia and constant complication of otherwise straightforward projects is a neurotic response similar to parrots plucking feathers and mutilating themselves when given not enough to do.
I’ll write about this at length later, but the short summary of it is that developers realize that they’re given often basic tasks and rather than embrace the fact that those problems are always well-solved and could be embraced with just a little bit of pushback on the people side of things and maybe encouraging just buying a solution off-the-shelf or upgrading to better hardware to run that long ETL, they instead fixate on new “best practices” and ignore the creeping existential horrors (mokitas!) that:
And on and on and on. So, of course, we see this neurotic behavior in our industry, and dress it up as something else instead.
I agree with your points, and I’m looking forward to an in-depth article on this topic, if you’re writing one. I had a slightly different take on this article - the part that stood out to me was the disconnect between the interpretation of the requirements from the perspective of the management and the development team. This is a clear indication of dysfunctional management and a lack of organizational maturity for software development (i.e., a lack of formally specified requirements). This reminds me of consulting gigs where I’ve been called in to solve a technical problem, but really uncovered a management problem. Sometimes the communication paths just need to be reset so everyone is on the same page. But if management is incapable of accepting hard truths, they need a lower-ranking scapegoat. This would be the developers. The only lower-ranking scapegoat for developers is the framework, because blaming the requirements pushes the problem back upstream.
What is the point of linking to Sergey Aleynikov?
He was arrested for working on an imaginary problem? Also, his suicide must have been very strange; he’s still alive.
Am I the only one who sees irony in the author putting all this thought into a problem that could be summarized as people simply being bad at their job?
What a reductive insight you’ve made: “People writing bad software is the root of bad software”.
No. My insight is this: all of his anecdotal examples are examples of people poorly managing time due to poorly prioritizing their work. This fault has many causes such as poor design goals, miscommunication, avoidant behavior, boredom, et al. This is a fault everyone is aware of. The author has recognized this problem and decides to spend time formalizing it, making anecdotal stories, accompanying graphics, and a blog post, when that time could be spent on some aspect of enriching his life or self improvement (unless he finds writing the post enriching which is entirely fine.)
To the extend of the author’s examples, these workers sound bad enough to warrant labeling them as either incompetent or just lazy. In which case, we should just call a spade a spade and force this worker to make a course correction or replace them with someone better. That would be the simple and most straightforward response to the problem, and I am simply pointing out the irony of the author’s response.
I read the article as an extended meditation on the Upton Sinclair quote, “It is difficult to get a man to understand something, when his salary depends upon his not understanding it.”
A story. Years ago, when I was in college, I did some consulting work at a company. My coworker was also a college student (same college, same department). One project was editing a printed manual to put up on an internal Website. The conversion from Microsoft Word to HTML was trivial (Microsoft word provided that much). But not linking each vocabulary word to its definition in the glossary section. There were perhaps a hundred words (it was a specialized industry) and there were some 100 pages to edit.
My coworker wanted to dive right in and do the editing by hand. That was a lot of work. Days worth of mind-numbing work. I wanted to take some time to think about the task and how best to approach it. An argument ensued. We ended up using
lex(since we had access to some Unix workstations with everything preloaded) to add the appropriate HTML links to the glossary page for each web page and were done in maybe two hours or so.Was I smart in finding a quick way to reliably edit the 100 pages? Or was my coworker smart by trying to get X extra days of work even if it was drudgery? [1]
(Yes, I see the relationship of my story to the article, but I’m having a hard time articulating the connection I see. It’s similar to doing badly at ops—the ops who “save the day” with heroics in getting the system back up get the kudos, while the ops who set things up to run smoothly with almost no down-time get laid off because they appear to be doing nothing. Incentives matter.)
[1] And it wasn’t like
lexwas an unknown tool—my coworker was a grad student in the CS department and had written a compiler using bothlexandyacc.It depends on the point of view. If you were doing it because you honestly thought it was the best solution to the problem at hand, well then you were right, and hopefully your coworker learned a lesson and this isn’t an imaginary problem. If you were doing it for yourself, for your own knowledge, believing that the the skills learned would pay off at a later date, well then that’s up to you to decide but not an imaginary problem.
The second scenario seems falsely conflated with the first. That is a problem, but a different one of management incorrectly valuing their employees.
I would say the act of spending the effort to connect these dots is an imaginary problem. A lot of these characteristics are human nature, which no amount of writing or philosophizing will fix (if the goal is to “fix” the problem).
I understand the meditation on the topic, perhaps in an attempt to clarify to himself a series of problems that his intuition tells him has some tangible connection, which is beneficial for one’s own peace of mind. And to be clear, I am not criticizing the post. I just thought the meta-connection between the post itself and its content was amusing. Contemplating the “metaness” of things is my personal imaginary problem pit.
Edit: A larger point I want to make is that these ARE very complex problems. Knowing which solution is going to be optimal is something that takes either lots of research or experience and intuition. Of course people will choose wrong occasionally and make the problem even worse. Hopefully they learn and make better choices next time. Trying to paper over this experiential process by making it a “problem” (in the first examples in the article) is foolish and can send a message that any mistakes made are self inflicted instead of being part of the process of self-development.
In your scenario, you saved time and money. Real problem.
If the task had instead been to change one web page’s header from h1 to h2 and you had to go out and buy a new sparcstation and compile Perl from scratch, etc., that’s imaginary problem territory.
Imaginary problems seem to be justified by “but what if?” What do the kids say? YAGNI. Perhaps the question can’t be fully resolved until afterwards, in hindsight, but we can at least keep track of which developers seem to correctly identify what ifs. I’d bet some people are prone to under building and some to over building. (And also never learning from those experiences, always erring in the same direction.)
I stopped reading at “I occasionally do freelance work, in the past I couldn’t afford to pick my clients, which means I saw my fair share of dissociative identity disorder and ADHD cases.”
In slightly poor taste, but not entirely unfair descriptions of some client behaviors.
One way an organization can avoid this kind of behavior is to involve developers in the conceptualization of the product. All products have lots of hard and unsolved problems. But in my experience, they are often conceptual problems. When the developer is one of the people forming and testing hypotheses about what would be good for the user, mundane technical work becomes just the last step in achieving something that is challenging and fulfilling: a product that people find useful.