One of the larger problems in software development (likely, in life in general) is that there are too many ignorants unaware of what is possible, what others have already tried or provided, what the standard solutions to certain problems are, and so on. This causes them to make poor choices. As time goes by, the problem seems to grow... (For this there are likely at least two causes: Firstly, software development is becoming ever more complex. Secondly, the number of developers needed has continually increased, which has correspondingly decreased the average competence level.)
Particular attention should be paid to the fact that ignorance is not an absolute: It is true that there are many who tend to be and remain ignorants in more-or-less every area—even when they would be expected to develop further (e.g. where the respective profession is concerned). However, even the best-of-the-best will have areas where they are, at least for some time, ignorant—and there will always be a “bigger fish”, someone who is even further ahead and able to provide a better solution.
This page started as brief lament consisting of an early version of the following section. During writing it expanded to be more general—and led me to see some connections that I had not originally considered. For instance, a part of the motivation behind design patterns is to reduce this general problem.
Revisiting this 2012 text in 2024, I find that the problems have grown worse in the interim, including disputable competence levels, less experience with Unix-verse tools/paradigms, less decision-making from developers in favor of business graduates, etc. Certainly, my experiences as a computer user have grown worse over time. Another complication is that the sheer number of things to know, as a software developer, is ever-increasing, which makes it hard for even the competent to keep up on a reasonable level. (Indeed, one of the reasons that I switched from Java to PL/SQL was a growing frustration with the sheer number of libraries, tools, whatnot that I encountered as a Java developer—and often in the form that I learned library X to perform a certain task in one project and found that the next project used incompatible library Y to perform the same task. That these various libraries, tools, whatnot did not always bring an improvement relative older days made matters worse, but is off topic.)
The problem also, unsurprisingly, seems to be extremely wide-spread outside software development. Notably, my readings on, and other exposure to, various political topics during these years have clearly shown that politicians are astonishingly good at being bad decision-makers. In Germany, my country of residence, they actually seem to get more wrong than right... This includes ever and ever again trying something that has always failed and not trying what has worked, in a manner that shows a depressing ignorance of topics like history and economics. (With reservations for what might be explained by e.g. attempts to gain votes at the cost of good policy.) See the category on politics and many older Wordpress writings for more information.
On two occasions, I have seen (different) inexperienced, mid-twenties developers send similar emails with a nonsensical program of the same character.
In the first case, around 2000-2001, the developer wrote how he had grown tired of adding HTML-tags by hand. His program would “solve” this problem by an input field into which a particular tag-name could be typed (or copied). The output would be a complete <tag-name></tag-name>, which could then be copied into the HTML-code.
In the second, January 2011, the developer wrote how he had grown tired of adding quotes and commas to the various IDs for SQL-queries by hand. His program would “solve” this problem by a similar input field. The output would be the inputs surrounded by the appropriate quotes and with an added comma.
In this project, a recurring task was to investigate tickets from end-users consisting of a list of identifiers for various entities that needed to be checked or altered in the database. Manually preparing these for the query was a waste of time and energy.
The real tasks cannot be revealed here, but consider questions on the lines of “Why are these twenty invoices not closed, despite being paid in full?” and requests like “We accidentally deactivated a dozen accounts. Please reactivate them through the DB.” for the right general idea.)
What is wrong with the above? Does it not sound like a reasonable improvement? Only to those who are ignorant or lack good tools—in particular, a decent editor:
Firstly, there is always the possibility that the tool for which the output was intended already contained a way to convert the input as intended, e.g. through a plug-in, a macro, or a scripting language.
Secondly, where this is not the case, any good editor can do the same task just as well or better, do other similar tasks, do unrelated tasks, and do them without the need for a separate application for each task. (Notably with the editors Vi/Vim and Emacs, but even lesser “real” editors, e.g. JEdit, Notepad++, Kate, and UltraEdit will manage. Notepad and the likes do not deserve the name “editor” and should be avoided—but do provide an excellent example of how grossly the ignorant can go astray when considering the capabilities of a tool-category.)
Thirdly, if a stand-alone application was needed, it is dubious that a mini-GUI was the way to go: In a Unix-like environment or a Windows environment with Cygwin (or a similar tool) installed, the better choice would be to have a small script to be run from the command line or through a suitable keyboard shortcut. (Here, however, some degree of personal taste can play in. Still, any programmer worth his salt has at least one Unix-style shell, e.g. Bash/Ksh/Zsh, running at all times—unless he is both forced to work in a Windows environment and prevented from extending it with beneficial third-party tools, e.g. the aforementioned Cygwin. Even here, a suitable solution might be available over Wsh or PowerShell.)
For the sake of demonstration, commands to do the two above tasks under Linux + X-Windows, by automatically reading from and writing to the clipboard (“primary selection”) without the need for any GUI involvement, manual copy-and-paste involving a second application, whatnot:
TODO/Disclaimer: The HTML generation tool I use maps the quote marks in an (in this particular instance) unfortunate manner, which breaks the below code. Until I have had the time to fix this, you might have to manually correct them.
xsel -o | sed -e ’s/.*/<&><\/&>/’| xsel -i
xsel -o | sed -e "s/.*/’&’,/" -e ’$s/,//’| xsel -i
Both statements were written of the top of my head and required only two cases of minor tweaking after a test—both syntax errors caused by sloppiness.
(The command-line inexperienced should note that these are not commands that would be typed and re-typed on each occasion, but which would be written once and then either be swiftly recalled from the command-line history, put in a script/alias/function/whatnot with a suitably short name, or be tied to a keyboard shortcut.)
The above might seem to be just a funny (or, on the outside, mildly depressing) anecdote of no great import. Indeed, I fear that the number of modern developers who actually realize that something was wrong is smaller than it should be.
However, this is just way in which a more general problem manifests: Those who do not know better suggest solutions for problems that others do not have (due to better tools) or where superior solutions can easily be found.
While it is often the case that the competent are untroubled by what troubles the incompetent, the reverse is also common, e.g. because the more competent work faster and more efficiently—and are therefore more limited by flaws in the tools used. Similarly, the less competent are often unaware that a better way exists than the way enforced by the inferior tool that company policy dictates be used—and do not feel hindered by such restrictions.
By analogy, the better tennis player might have enough understanding of and skill with spin to hit a return within the lines that the worse player cannot control sufficiently—but the better tennis player is also more likely to be hampered should his stringing be defect, because the defect introduces more chance and unpredictability, which cuts into his skill advantage.
Halfway between the general case and the above special cases we find growing prejudice about the command line and text-based tools as user unfriendly, lesser knowledge about the well thought-through concepts and paradigms from the Unix-verse, and a naive belief that any application worth its salt must have a GUI—be it ever so rudimentary. There are, however, plenty of other instances to be found (in particular when inexperienced developers or non-developers, e.g. product managers, are in charge). Consider e.g. an example from a recent project where the developers had next to no influence on the GUI:
There were long lists of items to be worked through—displayed at a fix number per page and with a “page navigation” that allowed steps of 1, 5, and 10 pages ahead or back (as well as first/last page). With dozens of pages to work through (and the order of work being determined by external factors—not the order within the listing), the users would have been very thankful for the ability to go to a specific page by number or to simply increase the number of items displayed per page. None of these obvious-to-the-experienced changes occurred to those responsible for GUI requirements.
Another example from a more technical level of the same project: One developer implemented a “cronjob” system in a JEE application with the job information present in a database table. For those with a knowledge of cronjobs under Unix, a reasonable and obvious suggestion would have been to read this table once and then keep the entries found there in memory until explicitly told to reload the table (or the next re-start). Alternatively, if a dynamic reload was wanted, the table could be automatically reloaded every 5 minutes, with an ensuing update of the scheduling for the jobs present. (Indeed, if the first solution had been chosen, a reload could have been implemented through a special-purpose cronjob, itself present in the table—without changing the core mechanism.) What was done instead? Each cronjob was made responsible for its own rescheduling—and it checked for a change of schedule only at those times when it was scheduled to be executed... The weird behaviors that arose included that if a job was scheduled for midnight every day, but the table altered to reflect a new execution time at 11 p.m., then 11 p.m. of the same day would go unheeded; midnight would be reached, the job rescheduled for the next 11 p.m. (but not executed); and only be executed at the 11 p.m. 24 hours after the intuitively expected time of execution. Similarly, adding an entirely new job was not possible without restarting the servers—there was no-one there to schedule during run-time... In contrast, the second of the proposed alternatives would have automatically detected both cases and caused a transparent (re-)scheduling; the first would have been amenable to a soft reload without unnecessary delays or restart (e.g. through a JMX command).
While there is a very strong correlation between general incompetence and the form of ignorance described here, the problem is by no means limited to those who can be considered ignorant or incompetent in general. We are all guilty from time to time, in particular when faced with new scenarios, domains, technologies, ... (Although a greater intelligence and a greater general knowledge and experience will increase the likelihood of a good solution being chosen despite a “local” ignorance.)
The possibly worst, but not only, example from my own career:
As one of my first tasks as a developer, fresh from four years of using the Unixes of the 1990s, I was told to implement a table view of certain data in a web application, did so, and had my work reviewed. A feedback point was that the table should be sortable through clicking on the header of a column (“This should have been clear from the little arrow in the header of the image in the requirements.”). I duly went back and implemented this—and was met with an irritated complaint from the reviewer when the order of the sort was not reversed upon a second click. That I honestly had never seen this (today ever-present, and even then semi-common under Windows) paradigm before certainly explains my error, but it does not alter the fact that a lack of experience led me to a poor decision—nor does an explainable and understandable lack of experience in the above decision makers alter the fact that they made poor decisions. Here we also see that what is the best solution is not just determined by what is objectively better (all other factors equal, having the ability to sort is better than not having it), but also by what is expected by convention (how a sort is to be made, how optical indications are to interpreted, whatnot).
Arguably, the fact that this (very small and highly amateurish) company developed ad-hoc implementations of each and every view is yet another example: The far better solution is to write a generic view that simply takes a certain data set and a few configuration options as input. That way sorting would have been either a non-issue or just a single option to turn on.
Indeed, today it is not even necessary to develop the component internally: Many frameworks and third-party libraries already come with such standard components provided.
Partial remedies can be found by (on an organizational level) making sure that those most qualified make decisions, that those likely to have appropriate knowledge are consulted before making decisions (including developers when it comes to the user interface and the actual processes—areas that far too many non-developers see as their own exclusive concern), and (on a more personal level) making sure to research the current domain, existing solutions, standard paradigms, whatnot.
At the risk of repeating myself: My experiences between 2012 and 2024 are clear—most product managers (or their equivalents by another name) do not understand software, they do not understand usability, they do not understand what makes a reasonable workflow, etc. While it is true that many software developers have similar weaknesses, the likelihood that a randomly picked developer will be able to make good decisions in these areas is considerably larger than for a randomly picked product manager. Often it might be for the best to let a product manager define, somewhat abstractly, what the user should be able to do and to leave the how of the user experience to the developers; alternatively, to make such decisions together; alternatively, to have a third role, filled by someone with sufficient development/software background, to make such decisions. Unfortunately, the trend is in the opposite direction, which goes a long way to explain the quality of today’s user interfaces.
(My best experiences past 2012 involve a Scrum project with an ex-developer as product owner.)
A related, but off-topic, issue is that too many decisions are made over the heads of the actual users, according to the idea that “we know better than the user what the user should want; if he wants something else, that is his problem”. (To which I repeat my standard reply: If the user asks for a better horse, give him a better horse—chances are that a car will be less helpful or, even, make matters worse.)
The following is an automatically generated list of other pages linking to this one. These may or may not contain further content relevant to this topic.