One of the problems with memory is the tendancy to remember what it is you meant, and that what you meant might not actually be what you said. A lot of bugs in code come from this because as long as you remember what it is your code is meant to do, you won’t really read it to see what it says it really does.
The same thing happens when we type, we read what we meant to type, not what the letters say. My favorite typo of all time was when on a postcard instead of writing Postage, I wrote Postange. Nobody noticed, not me or anyone that proofed it, for months.
One of the reasons that writing tests works for coding is that it forces you to say the same thing twice in different ways and validate that what you said both times is logically the same.
Likewise, peer code review works because it requires that someone else can read your code and agrees that it means what they think it should.
Not looking at code for months can also help with the same thing. “What the hell was this supposed to do?” - “Oh, I get it, but this isn’t correct.”
So don’t worry about forgetting what your code means, if you can’t come back to it 6 or 12 months later and read it, you wrote shitty code to begin with.
By default in my dev environment Google App Engine stored my datastore and blobstore in the /tmp/ directory which had the unfortunate effect (in my case) of wiping out the blob store every time I rebooted, which was frequently. For whatever reason, Google doesn’t seem to have listed how to resolve this in a single place, so this how to resolve it.
My start command now looks like this:
~/google_appengine/dev_appserver.py -a 0.0.0.0 . —use_sqlite —datastore_path=/mnt/project/aeds/appengine.datastore —blobstore_path=/mnt/project/aeds/blobstore
The bolded part above needs to exist before you run the command, but the appengine.datastore file (or whatever you name it) and the blobstore directory (or whatever you name it, it shows up as a directory, not a file) will be made if they don’t exist when you first run.
The italicized switches —datastore_path and —blobstore_path are both required.
You may not need to include that —use_sqlite switch or that particular IP address in your environment.
Richard Cook has a talk on IT Conversations, you should listed to it.
He makes a point that the operator of a system cannot interact meaningfully unless they have an understanding of what the system is doing. “We have to support mental simulation… you need to be able to have operators and the people who are working in your operations world be able to mentally simulate what is going to happen if they take some action.”
He is largely referring to operating systems that can and do fail from the scale of a generator to the power grid as a whole. But I think its equally important in software and something that is often missed in UX design.
Interfaces that do not properly expose their purpose are the MOST prone to being used improperly and initiating failure situations. One of the worst offenders in my experience is the settings screens Outlook, Apple Mail, and other email clients have for settings. Terms like Server Name, POP, IMAP, SMTP, Port 25, 487, SSL, etc. mean nothing to average computer users.
We are expecting people to copy settings from somewhere, like their ISPs settings FAQ, into their email client’s setting screens. But when there is a failure, they are completely unable to diagnose it because they do not understand the purpose of any of the information that they have. And they are also extremely unlikely to understand any error message, because they don’t understand the requirements to begin with.
The more prone a system is to failing, the more work UX designers need to do to provide active assistance to users to resolve failures. Email host inaccessible? why doesn’t the screen suggest some fixes? Just opening the settings page does not count as a fix.
Other less than effective but common solutions include:
Some other strategies worth looking at:
Definitely something worth thinking about when considering users and UX.
As a web developer, I think about security frequently. Smarter developers than myself call security a state of mind and not a feature. My experience today with UPS shows the absolute worst in treating security like it is just a specific feature and not a frame of mind.
I missed a package delivery on Thursday that was addressed for my wife, Lana, and her gallery OhNo!Doom. One of the owners at the gallery, Max, managed to have the sender of the package request a hold at the UPS shipping facility so it could be picked up on Friday.
Requesting the hold was in itself a hassle because the package was shipped by the printer instead of the artist, but I won’t get into that much because it didn’t involve me. Let’s just say its easy with FedEx and UPS makes it near impossible.
Friday morning Max went to pick up the package and brought among other pieces of proof the State of Illinois form stating he was a partner at OhNo!Doom which was addressed on the box. UPS refused to release the package to him because his name was not Lana.
Max asked me if I could help after he’d left UPS. I called UPS customer service and the service representative told me, incorrectly, that they would release the package to me because my ID has an address that matches the address on the package.
It makes sense that a package would be released based on the address on an ID because UPS does not ask for identification when they deliver a package to an address. In fact, they don’t even care if my neighbor signs for a package that is for me. They don’t even require any proof that someone standing outside my house when they approach the house is even a neighbor and will gladly sign the package over to them. I have been across the street when UPS came and walked over and signed for a package before; I could have just been parking my car and decided to steal someone else’s package.
My point isn’t that UPS should ask for ID all the time, its that when they make deliveries, all they require is that you are there when they are. And that is in fact good enough security for millions of packages.
The UPS facility at 1500 South Jefferson in Chicago is one of the worst retail experiences possible. The fact that UPS doesn’t realize it reflects poorly on their entire organization. The place is small, dirty, overcrowded and general makes any US Post Office look like a resort. Everyone basically agrees about the place, check Foursquare for some comically bad reviews.
I arrived at the UPS facility with the door tag they left on Thursday when they missed delivery as well as my photo ID which lists my address including apartment number the same as was on the package. This was not adequate though because my name did not match the name on the package. This is a bizarre restriction because as I mentioned, UPS has never cared if my name matched during an actual delivery. I had the door tag and matching ID, which is two pieces of very very good evidence that it was my package, but not good enough.
When the person picking up the package does not have an ID with a matching name, they require either an email or fax be sent to them that includes a scan/photo of the recipient’s ID along with an “authorization” that includes the tracking number.
Lana was out of town and had a bad cell signal but managed to send me an MMS with a photo of her drivers license. First I tried just showing the ID to the UPS rep on my phone, but they didn’t care at all that I had a photo of a drivers license with a matching name on my phone.
I then forwarded that MMS to UPS’s email address, and also had to send them a second SMS with an authorization that read “please release package 00000 (my tracking number) to jarrett widman” because the initial MMS didn’t include any of that text, which was maybe a problem with my phone.
So UPS got an email with an ID with Lana’s name and a separate email with the authorization letter I forged. Both emails came from a anonymous looking cell phone number. That was enough to get the package released.
Think about what an email with a scan of any ID where the name just matches establishes though:
Often, bad security practices will exist or persist because it makes things easier for customers or employees. Kevin Mitnick details many social engineering attacks in his biography, but the easiest is often getting the private service number for a company along with the authorization information they use on the phone, which is usually ONLY their employee number, and assuming some knowledge of phone dialect, you can get free reign to do things like turn on and off cable TV service or Internet at a residence. Even username/password style authentication is settling for something that most people can handle but is shown by millions of cases a year to not ultimately be very secure.
I understand the trade-offs that are made in relying on security practices that are not completely reliable but that are manageable.
What is not acceptable is security practices that are rigidly set to be less secure and make the experience for customers worse while burdening employees with pointless enforcement. Everyone’s time is being wasted at UPS because their security is weak AND difficult to work with. Its the worst of both worlds.
Ultimately, if someone really wants to steal a package they can. But the security in place to prevent that should keep the burden of enforcement inline with the realities of risk.
What does it mean when someone asks you if it was hard to build an application? You could judge that in hours or lines of code, but in most cases you will judge that by assessing how much time you spent struggling to make features work.
That struggling comes from managing complexity and lacking the knowledge to implement ideas efficiently in code. Newbies struggle with both problems, but as you learn your languages and frameworks, those issues go away. Then you are left to struggle with complexity on its own.
Complexity is solved by modularization and design patterns. Entire languages and frameworks are built specifically to make it easier to solve the problems of complexity. Learn those tools and complexity goes away.
So next time someone asks if it was hard to create an application, you can hopefully say it took a long time, but it was a pleasure to work on.
