He then proceeds to list the following fallacies:
- Nirvana (perfect-solution)
- Appeal to authority (argument from authority, argumentum ad verecundiam)
- Historian’s fallacy
- Misleading vividness
- Survivorship bias
Let’s take a look at what I feel is the most common fallacy we as software engineers (or any professional, really) faces constantly: Appeal to authority.
This can be a bit problematic when you have multiple people vying for a shred of authority in their role. I worked at a location once where everybody around me nitpicked every line of code I emitted because it didn’t follow their ideas. When challenged, they would fall back on either “This is the way he [architect] taught us to do it” or “This is a best practice” or the implied “I’m older than you and therefore smarter than you so you should bow down to me.”
I think programmers are now afraid of taking the risk of applying what they know and have experienced and instead are falling back on the results of others. Let’s say that you write a method that causes a memory leak. When you’re called out onto the carpet, you explain that the way in which you constructed the code was based on the directed opinion and approval of the project architect. Even though you noticed the potential for a leak, you ignored it because, hey, why should you doubt the architect? Isn’t s/he supposed to be the smartest person in the room? In turn, you get to be thrown under the bus while the authority that you yielded to denies all accusations.
At least with blogs, talks, and other tangible items, they can’t fight back.
I’ve had a few contracting gigs in my career as a software developer. Really, it is quite common in this industry. Many, if not a good majority, of contractors are not strictly 1099 workers per se (we’ll cover that in a minute); instead, many are employed by staffing agencies such as Robert Half and FGP and farmed out to clients who have an established contract. The employees typically submit hours worked at the client and, if approved, are paid through the agency. There is typically no benefits (or very poor benefits), no paid time off, and, because the you’re not in the “in” crowd of bona fide part-time and full-time employees wholly employed by the client, you may be looked down upon.
From the article Software Developer’s Guide to Contracting Versus Salary Employment by John Sonmez:
As a developer, I can only attest to what my experience was like from the programming perspective. As a contractor developer, it was not uncommon for me to…
- Have what considerable experience I had developing ignored. I’m all for having a uniform code base, but it does not require you talking to me like I’m a complete idiot or am so wet behind the ears that my nickname is “Niagara.” I can respect that as a contractor, my contributions could have a lasting impact–both negative and positive–and that, after my tenure, it would be up to someone else to maintain it. (Read this article for some more anecdotes about being a “highly paid consultant”).
- Be regarded as the lowest rung in the caste system.
- Have items kicked back from QA/other programmers because it didn’t meet whatever imaginary standard they had.
- I should mention that as a trick, if you want to generate some plausibility into why you want to nerf a programmer, have QA keep sending back bugs that have been solved and demonstrated fixed. Do this enough times until you have a good percentage, then you can drop the hammer.
- Be excluded from company events (which was fine; I wouldn’t expect my HVAC guy to join my family picnic).
- Be accosted verbally. This seems to be a running theme in my life…
Contractors make up a large segment of many organizations. For example, Google essentially runs off contractors, the “invisible workforce, off company payrolls” doing grunt work “for the Silicon Valley giants with few rewards.” Indeed, “[p]eople look down on you even though you’re doing the same work” is the sentiment for many contractors not just for FANG but throughout the industry. The federal government lives and breathes contractors (helps avoid public unions).
I coped with these behaviors the best I could, often just riding them out until the next full time endeavor came along. There were times when it was awfully frustrating to be treated with such little regard. I hate being a contractor; it’s simply not my cup of tea. But, my father always told me: “Put up, or shut up.”
So, I shut up, was shown the door after the company merged with another, and landed a full time position in a job I love. If employees are seen as expendable, then contractors are seen as little more than a means to an end.
To employers, please: I know there are a lot of morons that get past the door, but there are plenty of good contractors who are great at what they do. They are a guest in your house, so try to make them at least feel a little bit welcome while they perform their duty.
Being a software engineer isn’t easy by any means and oftentimes we (developers) find ourselves traversing through a Dragon’s Layer-esque of quizzes, tests, and the dreaded whiteboarding sessions. Granted, for a more junior-level position, I can understand a good whiteboarding session or some assessments to gauge whether or not the individual learned anything. But when interviewing someone who has years of industry experience, are these miniature gauntlets really helping anybody?
I think part of the problem is the fear of feeling “stuck” with a bad developer. From the article 7 Reasons Why Software Develoment Is So Hard by Paul Smyth, the author cites that “[t]here is no barrier to entry into the programming world and thus it is awash with many poor programmers who adversely affect projects.” Are we at the point where the industry demands perfection in every aspect of operations?
Or is it just practicality?
Continuing on from Glen McCallum’s blog, we see that while developers hate them, companies love them:
I have bad news for senior developers in the field: many job placement agencies (Robert Half, especially) implement these gates as well. And, as much as I hate them, my workplace utilizes these aptitude tests as we were wasting so much time interviewing poor candidates that couldn’t even tell me what an interface was.
Later we’ll talk about one aspect that exasperated this problem: coding boot camps and the games that they play. Until then, you better know damn well how to use the Strategy pattern in conjunction with a SQL query that can determine the vowel count of every last name in a Japanese customer database and every database has a different collation.
I was reading the article Why data centers fail to bring new jobs to small towns by Alison DeNisco Rayome.
This is a subject that I can relate to as I’m from the area where Facebook plopped down a data center outside the rural town of Forest City, North Carolina. The chatter from elected officials and Facebook themselves was that this would be a boon for the local economy and create numerous new jobs. But, while the temporary outsourcing of local construction laborers was a small uptick, the same problem that was experienced by E. W. Gregory appeared. Data centers are, more or less, gigantic network closets. There is simply no need for that many technical staff. In any case, Facebook continued expansion projects, with the latest being as recent as 2016. An estimated “125 full-time jobs [and] full-time third party (sic) contractor positions” would be created. This is in a county with a population of around 65,000 with a workforce of roughly 26,000 people. Therefore, the presence of Facebook will theoretically have a 0.004% positive impact on a county that is already below the poverty line. Data USA states that the 2017 median household income was $38,573 (USD), which is $19,079 (USD) less than the median income of the country as a whole. The outlier in this instance is the Lake Lure area, which comprises the western half of the county (see below). Forest City (and my subsequent hometown of Ellenboro) is center and right.
What an impact that data center is having, huh? When examining the most common and most specialized jobs, there was no change in the years since the data center’s operation:
I should also mention that Walmart is the biggest employer in the county. So why did Facebook choose Rutherford County and why did the county commissioners (and Duke Energy) bend over backwards to give them so much economic incentive? The answer is always the same: taxes. From the article Study: Facebook Data Center in North Carolina Has Massive Economic Impact, we see that $198,000 were added to local property tax rolls and $336,000 tax was paid on electricity usage (the state managed to get $194,000 in franchise taxes). The article goes on to boast that “[o]ver three years (since the site went live in April 2012) the data center resulted in addition of 4,700 across North Carolina, including direct creation of 2,600 jobs.”
Am I mad that Facebook built a data center in my former back yard? Hardly. I don’t live there and they are free to purchase land and set up shop wherever they want. What does irritate me is when they (in conjunction with the local government) start blowing smoke up the collective asses of the local populace. Of course, this is the same populace who keeps voting in the aforementioned local government, but what do I know? Apparently what’s good for the county’s (and state’s) goose is good for the gander.
So the next time someone suggests to you that a new data center is going to turn the town on its head and make waves, take it with a grain of salt.
Better yet, smack them with a car battery.
In a sense, it really spoke to me. I have spent countless hours in situations where the current environment were “handcuffed” as it were to tech that had, at the surface, seemed like it had lived past its prime.
Or had it?
Many instances–public sector especially–are not by any means cutting edge. The utility sector, for instance, in many instances utilizes a de facto serial standard since 1979 that is (by itself) highly succeptible to man-in-the-middle attacks and is very limited in what data it can hold. Other cases it’s a matter of needing to get something out the door as fast as possible. One of my contracts involved an organization that needed an in-house web-based ERP yesterday. (They already utilized an ERP system from Infor that ran on an AS/400 but it was unable to effectively meet the requirements of the vendors for product listing and RPG IV programmers cost a buttload).
If you are a web developer or programmer, you can already feel the nausea. If you’re not, then understand that this was the equivalent of building Frankenstein’s monster from IKEA using parts you ordered off eBay.
But: it worked. To the best of its ability, it managed to get the job done. Yes, there were a lot of innefficiency in some of the operations that took place, but it got the job done, which to the company was “Good enough.” The skeleton team grew by six people and, from what I hear, is still chugging along with backlog of features that may never be toppled, but that’s a story for another day.
In his article IT’s Famous Last Words: If It Ain’t Broke, Don’t Fix It, Peter Waterhouse states:
Maybe chasing after the “latest in greatest” isn’t the answer to remaining ahead of the curve in information technology, at least all the time. One should always evaluate their toolset and make adaptations as necessary in order to fulfill the needs of their customers. Last I checked there is still a need for C programmers.
In the public sector where availability of service, not competition, is the biggest worry, it is prudent to not disrupt the flow of what is provided to the citizens. We still see a lot of “obsolete” tech that still functions being utilized, especially in terms of the hardware that supports the legacy applications. An example is from the article DoD is migrating to Windows 10 and it will probably stick around forever by Kelsey D. Atherton:
Ensuring compatibility of these legacy apps is critical, so specialy care must be taken to ensure that they can be brought gently into the twenty first century.
So in answer to the question on whether “obsolete” tech is “broken”, the answer is: it depends.