My bachelors degree is in Electrical Engineering and when I started looking for my first post-college job, I had to make the decision whether to work in more traditional electrical engineering careers or in computer science-oriented careers. I had been writing code in BASIC since I was a kid, then Borland Turbo Pascal in my middle school and high school years, then more Pascal and C and C++ in my college years. I had a computer science emphasis as part of my EE degree, but the actual degree was in electrical engineering. There were many factors that influenced my decision to take the computer science fork in the road instead of the electrical engineering fork and one of these was an experience I had in an electrical engineering lab in which a tool lied to me. This post is about how our software development tools sometimes deceive us, though I’m really addressing cases where developers may share some culpability versus software that is intentionally deceptive.
Several of my electrical engineering classes had 1 credit hour labs associated with them that actually often required 10-20 hours of my week to complete the labs. I had one circuits-related lab that was giving me particular trouble and I spent hours trying to get my circuit to work as expected so that I could pass off the lab assignment. After hours of frustration and increasing doubt in my own understanding of the project and associated topics, the teaching assistant realized that the oscilloscope I had been using was faulty. We connected a properly working oscilloscope to the circuit and it immediately passed. I left relieved, but also left with a stronger impression than ever before that I would prefer to make my career in software development rather than in working with circuits or hardware.
It turns out, of course, that our tools in software development sometimes fail us just as the oscilloscope failed me in that lab experience that has perhaps forever traumatized me. I generally have more confidence in my own abilities in software development than I did in the circuit topic being discussed in that lab and many years of software development experience have contributed to that confidence that I did not have after only a couple semesters of study in the circuits topic. I am using the remainder of this post to provide some examples of where software development tools have failed me or those around me, though I emphasize that many of these are as much or more developer issues than tools issues. I think it’s better to just blame the tools.
The Case of the Missing Float
I was working on a project in the early days of Oracle’s PL/SQL Server Pages (PSP) product and our the PSP-based pages were not displaying our primary key column in some of our Oracle 8i Database tables. After working with Oracle Support and having Oracle Support put us in touch with a developer of PSP, it was realized that this early stage of the tool did not expect the PL/SQL type FLOAT. Any column of that type was not rendered in the PSP presentation of the table structure. As I recall, no types other than FLOAT were affected in this way. I don’t remember how much time we spent before we realized the specific cause of this issue, but there certainly was some time lost and some questioning of other issues surrounding our DDL statements and database construct before we realized the issued was with the tool.
The Cases of Database Command-line Tools Misrepresenting Their Databases
When using command-line tools such as psql for PostgreSQL or SQL*Plus for Oracle database, one can occasionally be deceived if not careful. There are multiple ways in which this can happen. These “deceptions” tend not to be issues with the tools themselves as much as misconceptions upon the part of the users of these tools.
Based on a particular user’s settings, these command-line tools often don’t differentiate null from empty string. Both command-line tools referenced allow users to have a string or character substituted for null in query results to avoid this potential deception. These command-line tools may also not show full precision of some numeric values, but this is again controlled by user settings.
A really easy deception trap for users to fall into when using command-line tools to connect to a database is that of blaming slowness in the command-line tool or its enclosing terminal on the database. For example, if a table with many large (lots of columns) rows is queried, the scrolling results from that query may take quite a bit of time as the user watches them scroll across the screen. It could be easy to blame the query for being slow and taking however long it took for the results to be queried to the terminal, but in reality it can be shown that the query is much quicker when its results are spooled to a file instead of the terminal or, better yet, when its timing is measured using the database command-line interface’s query performance measuring tools.
One other deception I’ve seen related to database command-line client tools (or really any database client tool) is when a developer thinks his or her software is not working properly because they cannot see the changes being made to the database in their client. In some cases, this is because the software being tested or debugged has not been allowed to commit its transaction yet and so, in their particular isolation level, the developer should not be able to see the not-yet-committed changes being made with a different database session.
The Case of the Java IDE Classpath Deception
Most Java developers prefer doing the bulk of their development in an IDE. These powerful IDEs make many of us much more productive, but these tools have been known to lie to developers. Perhaps the most common deception in a Java IDE occurs when the IDE maintains a separate classpath than the project’s command-line-based build (for example, with Gradle, Maven, or Ant). In this case, it’s easy for the IDE to report successfully building code that doesn’t build from the command-line or vice versa.
The Case of the Java IDE Compiler Version Deception
Another potential deception associated with use of a Java-based IDE occurs when the IDE uses its own version of a compiler that is not the same as the compiler version used by the command-line build. I alluded to this situation in the blog post NetBeans 7.1’s Internal Compiler and JDK 6 Respecting Return Type for Method Overloading.
The Many Cases of Slow-to-Update Tool Presentations
During my software development career, I’ve been burned multiple times by a tool that is slow to update its presentation or report. This has led me down a wrong road as I investigated a certain issue because I thought a tool was telling me something, but it really hadn’t gotten around to telling me that yet. If I’m lucky, I’ll eventually see a case presented by the tool where I know the data being shown me by the tool cannot be correct and then, on looking into it further, I realize that I’m still seeing output data from a previous run. When I run into this issue with a particular tool, I like to make sure that I have some field or indicator in the tool’s report that will have to be updated for each run of that tool so that I know if the data has been refreshed or not.
A very similar issue can occur with tools that cache results. In such cases, a developer may change things without any noticeable effect in the cached presentation and therefore think his or her changes are ineffectual or won’t impact anything. In these case, the developer is best served to ensure that data refreshes occur, even if it means forcibly causing the refresh.
Conclusion
This post has looked at situations in which we might want to blame the tools and suggest that they have led us astray. While this is true when the tool is built to intentionally lie or when the tool is broken or immature (as was the case in my first example), most of my examples are of situations in which the tool was actually doing its advertised job and it was developer misuse or misunderstanding of how to use the tool or the tool’s limitations that was the real issue.
Software development tools have come a long way and make our jobs easier and make us more productive. However, when not used appropriately or used too carelessly, they can sometimes deceive us or at least contribute to our making some erroneous decisions based on what we think the tools are telling us. The best approaches for addressing these potential deceptions by our tools is to understand our tools well, understand how our tools perform their job, and understand our tools’ limitations.
| Reference: | Our Tools (Sometimes) Lie to Us from our JCG partner Dustin Marx at the Inspired by Actual Events blog. |
