Forem: Joel Bennett

The Really Expensive Whiteboard

Joel Bennett — Wed, 21 Apr 2021 14:51:59 +0000

One place I worked at, we had the opportunity to bid on a project that would have been used in Antarctica.

The client was looking for a way of tracking people, to see if they were off-site, on-site (but not in the building), or on-site and in the building. They were open to proposals on how they wanted this done.

One solution was to give each person a card, and they would swipe in or out, depending on where they were. The idea was to use the same sort of proximity cards that you'd use to get access to an office building. This is the solution that my boss was initially interested in, as it was similar to some other solutions that we had already written.

Another solution that was proposed was to use Bluetooth. This is when Bluetooth was still pretty new, and no one on our team had used it before.

Then there was my solution: a whiteboard.

In hospitals and other offices where employees are frequently off-site, you'll often see a whiteboard with rows of names, and colored magnets - one per person. When someone comes into the office, they move their magnet into the "in" column. When they leave the office, they move the magnet into the "out" column. My proposal was to buy the outfit a whiteboard, some markers, and a bag of magnets. Then bill the client a princely sum, but still less than what a software based solution would have cost.

My boss wasn't amused.

And the client probably wouldn't have been amused to been billed for a really expensive whiteboard, either.

The Dangerous Mr. O'Conner

Joel Bennett — Wed, 21 Apr 2021 14:36:40 +0000

In school, one of the things they tried to drill into us was the separation of the UI (view), models, and controllers, as well as the idea of using stored procedures. Now I know why they tried to ram things like this into our minds.

One app I had the opportunity to work on was written in Visual Basic. The app being written in Visual Basic wasn't the worst. There's been some decent things created using Visual Basic, even if it is the runt of the programming language litter. This app, in particular, though, had some nasty surprises. One of these surprises was discovered by a "Mr. O'Conner".

At one point in the app, it had a text box that took in an individuals name. When I first started digging into the code, I was horrified to see an SQL statement directly behind the button click event for the button that was next to the text box. It was literally taking the contents of the text box, at face value, and inserting them directly into an insert query. This worked fine until someone had a single quote in their name. Like Mr. O'Conner.

For those not familiar with an SQL injection attack, the idea goes something like this: if inputs aren't properly sanitized, it is possible to enter a piece of text that terminates the existing SQL query, and starts another - whatever other sort of query (or update/delete statement) you want. So Mr. O'Conner, with a single quote in his name, was suddenly breaking the app. The previous developer put in the "fix" of converting the single quote to a backtick.

This is not the proper way to fix something like that. The proper fix would be to use a stored procedure, and sanitize any inputs going into the app. But, like I said, in this case "Mr. O'Conner" was switched over to be "Mr. O`Conner".

The moral of the story:

Never put SQL statements directly behind button clicks.
Use stored procedures.
Sanitize your inputs properly (and don't trust them in the first place!).
If your name is Mr. O'Conner, you may want to consider a career in software testing.

Tales from the Scrum Dungeon: Cars and Deer

Joel Bennett — Tue, 06 Apr 2021 14:34:45 +0000

One office I worked at was on the edge of a city. Being so close to the countryside meant it was often possible to see some wildlife. Sometimes the wildlife would get a little too close.

One morning, while driving in, there was an unusual amount of traffic, and it was all merging into the left-hand lane. As we passed the scene, a police vehicle had its lights on, and was blocking the right hand lane. Just past the police vehicle was a semi-incapacitated deer, which had been struck by a vehicle. The officer was waiting for a break in the traffic before he could dispatch the poor animal, and put it out of its misery.

Our office was right next to the road, and had a perfect view of the scene.

Eventually the officer was able to catch a break in the traffic, and with his shotgun, do the poor animal in. The dead deer sat there for several days afterward. It was eventually picked up, but not before it had started to bloat.

Sometimes software development is like that. Sometimes you are the car, and sometimes you are the deer. And sometimes your TODO comments take a while to get cleaned up.

Tales from the Scrum Dungeon: High Precision Rock Throwing

Joel Bennett — Tue, 06 Apr 2021 14:24:51 +0000

This story is more of a second-hand story, but still entertaining.

I once worked with a coworker who worked on an app that tracked fluid levels in above ground oil tanks. Given the potential environmental concerns about leaking oil, the tank level had to be tracked precisely. Very precisely. Rather than accepting the rounding errors that would come from using a 32 bit floating point number, the client requested that a 64 bit floating point number to be used. They couldn't afford to be leaking oil, and not notice it. So, when the app was built, a 64 bit floating point number was used. This would tracking the tank level easily to the nearest millimeter.

So how was the tank level actually measured so accurately? An employee would take a rock, and throw it against the side of the tank. Based on the noise the tank would make, the employee would guess the approximate level of the tank.

Doooonggg!
"Eh, that's got to be about half full, I'd say."

In software development, there's often a disconnect between what the user wants, what the user asks for, what is designed, and what is actually built.

Sometimes the disconnect isn't so obvious. Sometimes it's precisely obvious.

Tales from the Scrum Dungeon: Reset your @*@&ing password

Joel Bennett — Tue, 06 Apr 2021 14:13:17 +0000

One web app I had the pleasure of working on was accessible to external customers. As with almost any other online system, customers would occasionally forget their passwords. This required a call to customer support, along with some account verification, to get a password reset. This wasn't the best use of customer support's time, and was a bit of a security hole. Most online systems allow a user to request a password reset, with an email sent to the customer's email address containing a password reset link. The particular web framework we were using didn't have this functionality built in, so it had
to be added.

The developers in question designed a system that would generate a randomized token associated with a specific account. Anyone in possesion of the token could use it to reset the account's password within a given timeframe of the token being created (e.g.: 5 minutes). A URL link was generated that contained the token, and inserted into an email that was sent to the client.

Only the tokens weren't sanitized.

That's right. Just like the certification with a swear in it.

Because the URL was inserted into an email that was sent to customers, customers were potentially being sent URLs containing swear words. Luckily this was discovered fairly quickly, and fixed before we heard of any cases where customers actually received any @*@&^ing password resets.

Remember: sanitize both your inputs, and your outputs!

Tales from the Scrum Dungeon: Leprosy As A Service

Joel Bennett — Thu, 18 Feb 2021 16:16:12 +0000

Once upon a time, there was a small proof of concept web service that was written, likely in weekend. It was probably written under the influence of alcohol, late on weekend. I don't know all the circumstances surrounding its creation, but at one point, I did have to help support it. It was originally written as a proof of concept. It gathered data from a 3rd party source, performed some basic mathematical operations on it, and returned an output.

It was stood up on a server, shown off as a proof of concept, then promptly forgotten about.

Some time later, it was discovered that the service was still running, and racking up some small hosting costs, so was turned off. Almost immediately, a call came from another part of the company - the part that had been shown it as a proof of concept. It turns out they were using it - in production, and that their production service relied on it. It had to be turned back on immediately.

Not only was it turned back on immediately, but that service was then left running for years afterward. The worst part of it: it didn't make use of standard HTTP status codes. If the app failed with any sort of internal error, it wouldn't return an HTTP 500, it would still return an HTTP 200 (OK), but with a value of -1. It didn't matter what happened to it - it would always return a -1 if it ran into an issue. Pass it a bad parameter? Get back a -1. Server running out of disk space? Return a -1. Unable to legitimately calculate a value because of missing data from the 3rd party? Return a -1. Why was it done this way? The original proof of concept had to integrate with another piece of software. Because the developer of the service didn't have access (or resources) to modify the original software to accept HTTP error codes, it was built to fit the existing software.

The service lasted for several years. No one wanted to touch it, as the code was... unpleasant to work with. It was unpleasant to debug. It was unpleasant to maintain.

Moral of the story? Don't write leprosy as a service. If something is a proof of concept, be 100% clear with that to whoever is seeing it, and make sure that they understand that it is only a proof of concept. Otherwise you might catch leprosy.

Tales from the Scrum Dungeon: Max Lines

Joel Bennett — Thu, 18 Feb 2021 16:01:12 +0000

The original Visual Basic (not Visual Basic .Net), at the time, had a maximum number of allowed lines of code in a single file.

Since you are reading this, you might be curious enough to know.

I once worked on a series of Windows apps. One of them contained a number of files that were basically SQL statements, but embedded in code. The particularly files in question were automatically generated, for better or worse. I'm not sure how the original app got written, and it's been long enough that I can't entirely remember what circumstances it was used, but when I started with it, I was warned. Apparently the generated code got large enough that it actually was too large to fit entirely in a single Visual Basic file.

Rather than rethink the entire tool chain, they did what they thought was best for the situation. They split it into two files.

There comes a point in time for every project where you need to take a step back and look at the big picture. Maybe there's a better way of performing the series of actions that you are trying to accomplish. Hopefully you take that step back before you hit the maximum number of lines of code in a single file.

Tales from the Scrum Dungeon: Coyotes

Joel Bennett — Thu, 11 Feb 2021 23:47:40 +0000

I once worked at a small software shop that was on the edge of a large city, in an industrial park. One day I needed some work on my car done, and there happened to be a mechanic a few blocks away from the office. Rather than having to worry about the hassle of finding a ride, I figured I'd drop my car off in the morning, walk to work, then walk back after work to pick it up. It was summer, and it was maybe a less than 10 minute walk from the mechanic's shop to the office.

Everything was going well until I walked past an industrial lot full of trees and tall grass. Some distance away, I noticed a coyote. For those not familiar with them, a coyote is similar to a wolf or a wild dog. Most of the time they leave people alone, but there are the odd cases where coyotes have attacked people.

Not wanting to become one of these cases, I kept my eyes on it, and hurried along. Thankfully I made it safely to the office. After work, I walked back to the mechanic's shop and didn't spot it. It was the middle of the summer, and was likely too hot and too early in the day for the coyote to be out again.

Sometimes it's the monsters in the code that get you, and sometimes it's the monsters on the way to the office that get you.

Tales from the Scrum Dungeon: The Safety Dialog

Joel Bennett — Thu, 11 Feb 2021 23:25:20 +0000

Once upon a time, there was a tool that was written that allowed a client to alter their own database in a fairly serious way. The tool wasn't written on a whim, but was actually needed in some select cases. Because of the seriousness of the operations being performed, there had to be some mechanism to ensure that the user running it was really sure that they wanted to run it.

Enter the "safety dialog".

It wasn't so much as a single dialog, as a series of message boxes with "yes" and "no" options. The user running the tool would have to select "yes", then "no", then "yes". Each message box explained the correct option to select to proceed. There had been more than one support call where some user had complained along the lines of "Well, I selected 'yes, yes, yes', and it's not working!".

In theory, the idea behind the safety dialog was good - wanting to prevent users from doing irreversible damage to a database, but the implementation could have used some improvement.

These days, a better alternative I've seen is to get the user to type in a specific series of words or a phrase when deleting things like API keys. It's maybe still not the best option (designing a system where such tools aren't necessary), but at least the "safety dialog" prevented a few accidents from happening along the way.

Tales from the Scrum Dungeon: #@$% - the Certification With a Swear In It

Joel Bennett — Tue, 09 Feb 2021 17:16:36 +0000

Somewhere, someone out there may get a professional certification record with a swear on it. And not a "nice" swear. One of the bad ones.

I can assure you this wasn't intentional. It's more a consequence of the system, than an attempt at humour, for the sake of making something funny to share with coworkers, or post on the internet for imaginary internet points.

The system in question was used to generate printed certificates. The requirements to the system weren't entirely clear, but I was trying to do the best I could with what I had. What I had was an integer number that needed to be converted to something that looked loosely like one of the supporting documents we had. And the certification id wasn't an integer - it was a mix of alphanumeric characters. Because the requirements weren't particularly clear, I ended up doing something stupid: converting that integer into a base-36 number. In the English alphabet, there's 26 letters, and there's 10 digits (0 through 9). So imagine counting like so: 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F, G, H... and so on. Like hexadecimal on steroids.

Technically, there's nothing wrong with this approach. It's able to turn any positive integer number into a string of alphanumeric characters. And it did work. It just didn't occur to me until after - well after - that eventually it'd start spelling words. First, a simple words - like "AM" or "AT". But eventually it would spell longer words. Four letter words. Including swear words.

There's two important lessons here:

If you are unsure about something, get clarification, get it in writing, and get it as part of the specs for the project. As a developer, I failed on my responsibility to get clarification on that aspect of the project.
Sanitize your outputs. Any time you are generating a series of alphanumeric codes - especially product codes and serial numbers, ensure there's no room for ambiguity, or for crude output. The easiest way to do this is eliminate any vowels and ambiguous letters from your output. For example, depending on the font being used, it may be very difficult to see a difference between a capital O and a zero. Or between a number 1 and a lower-case letter L.

Take it from me: you don't want dirty output.

Tales from the Scrum Dungeon: The User Who Could Consistently Break the App

Joel Bennett — Tue, 09 Feb 2021 17:16:32 +0000

"She just did it again!"
"What?! How'd she do it?"
"I have no idea!"

This is roughly how a conversation went between a team lead and one of the other developers. They were on a screen share/call with a client who was somehow breaking their software. Not a bad break, but broken nonetheless. When things don't behave the way that the developer or the client expects, it's broken.

The application in question was an older Windows Form application, written in .Net. The user was entering data on one of the main forms, and one of the drop down list boxes wasn't getting populated as it should have.

"Let me try that!" said the team lead. He took control of the client's machine, and was able click on the drop down list box, and it populated properly, as everyone would have expected. The client then took the controls and broke it again. It failed to populate its drop down options.

There had to be some explanation. At least in .Net, drop down list boxes don't have vindictive behaviour depending on what user is using them. Or clicking on them. Or alt-tabbing into them.

That was the key.

The user wasn't clicking into the drop down list box. She was hitting the tab key to switch between various inputs on the form. It took a few minutes to sort it out, but was eventually discovered. The drop down list box control was listening to the on_click event. It would only respond when it was clicked on. If the control was activated in any other way, like being entered into via tabbing from another control, the on_click event handler
wouldn't fire.

Moral of the story:

It's broken if it doesn't behave like the people using it think it should behave.
Listen to the right event.

Tales from the Scrum Dungeon

Joel Bennett — Tue, 09 Feb 2021 17:16:25 +0000

What is the scrum dungeon, dare you ask? It's a dark place. A place without windows, where sunlight never shines, where laughter is never heard, and where everything is a shade of gray. Literally.

At a previous job, the building layout was a bit... odd. After some renovations, a room that was tucked back into one of corners had no windows, grey carpet, and a heavy steel door. It had no ethernet jack in the wall, and poor Wi-Fi coverage. Because of its odd location and limited utility, no one wanted to use it as an office. It remained mostly unused, except for the rare scrum meeting when no other rooms were available. Because of this, it got nicknamed the "scrum dungeon".

In my youth, there was a Saturday morning cartoon called "Tales from the Crypt Keeper". A haggardly looking character who was the maintainer of a crypt would tell a story of woe or danger to serve as a warning to children. I may not be that ancient, but I've seen my fair share of software development woes that perhaps it is time for me to share them. Not to ridicule those involved, but to serve as warning to others. Perhaps my tales can help prevent someone else avoid such dangers and suffer a kinder fate.

These are my tails from the Scrum Dungeon.

The Certification With a Swear In It

The User Who Could Consistently Break the App

Reset your @*@&ing password

High Precision Rock Throwing

Cars and Deer

The Dangerous Mr. O'Conner

The Really Expensive Whiteboard

(More to come soon...)