Tag: development

Overreaction to Negative Reviews

I’ve long since held the belief that our reactions to critical judgement of our work hurts so much because it’s so personal.

This has never been more true than on the Internet. In the world of distributed and isolated development, we often end up writing in a sandbox. We sit down and tune out the world and write code. And then we just deploy it to the masses for real-world testing. Many people are unit testing, which helps a lot, but as we’re such a distributed development world now, we rarely get the sit-down feedback we might with a company.

With that in mind, perhaps the over-reaction of people to their bad reviews (codewise) is a function of this distributed environment.

You’ve seen it, I’m sure. You leave a low-star review on someone’s product, annoyed that it doesn’t do something you think it should, and you’re replied to with vitriol. You’re astounded! You know that a one-star review kinda sucks, but you didn’t expect name-calling or, worse, someone to find your personal contact information and tell you that you deserve to die and you’re an idiot for not understand what code is.

I didn’t make that up. That’s happened. And since it happens, the question is why does it happen?

It comes back to the way we both develop code and the way we share it. The easier we make it to share our code in things like Github or official, public, repositories like the WordPress.org plugin repository, the closer the connection we make between developer and user. If you consider how it ‘used to be,’ the person who wrote the code may never meet any of the people who use the code. I’ve used Safari for years, but I have no idea who wrote it. Conversely, I’ve actually communicated with many of the Chrome developers about issues I’ve see and unexpected results. And goodness knows we all just ‘cope’ with how terrible things can be in Microsoft Word.

We’ve made the world more accessible for people to communicate directly the issues they’re having with software. This is a good thing. It allows us to develop faster and iterate code faster. We make things better faster. At the same time, it opens us up to issues like handling negative reviews.

If you’ve seen the movie Office Space, there’s a character whose job it is to take information from the customers to the developers, because developers are bad with people. We all laughed at that because we all saw the grain of truth. That tiny nugget of truth was that people who can bury their heads in the sand for hours to invent things are kind of weird people, and they don’t always communicate the way the ‘rest of the world’ does. Of course, now it’s 2015 and we know that it’s just not so. We all communicate similarly. Some of us just have more patience than others because we’re used to working with people more often.

Sunday is the 17th anniversary of the term “Open Source” in how we use it today. There was a public call to use ‘open source’ instead of ‘free software’, and we heeded the call. But open source has changed a lot from that day. We’re not just talking about free software that anyone can take and develop but the open lines of communication that allow us to develop it by working with the users in a closer relationship.

While many of us develop in isolation, writing and testing code by ourselves, the moment we release it to the masses we’re terrified. What if it breaks? It will. What if it sucks? It does. What if people hate it? They will. But we do it anyway, and when we, the developers, get that one-star review, it hurts. It punches us in the gut and makes us want to walk away.

Except… it shouldn’t. Certainly some reviews are made by absolute prats who demand the unreasonable. We don’t reply to support tickets for our free software fast enough, or maybe we didn’t refund their money when our store clearly says ‘no refunds.’ Maybe they hated it because we declined to add a feature. Maybe they just wanted to rant at us for 500 to 1000 words.

Yes, those reviews that are clearly full of anger should be ignored. And yes, those will make you feel like total shit. But the other ones, the ones where someone says “I wanted to like this, but the developer pushes an update every week and it really isn’t adding anything useful. This plugin has become bloatware and I’m not using it anymore.” Well hey, that’s actually a very nice one-star review. It’s a sucky one to get, but it’s fair and just.

So why do people often demand we delete those one-star reviews, or reply back that the user has no vision and cannot see how the plugin develops, or that the code is the dev’s and you should thank your stars it’s free? It goes right back to how we develop. We’re not used to the feedback and constant communication with others about our code. We don’t present our code to the masses until it’s at a usable or workable stage. And there are practical reasons why, but it means we just don’t know what it will be like to work with others to develop until it happens, and it seems to always happens in bad way.

What should you do? Keep in mind that the people who hate your code may have a point. Try to be objective and see it fairly. But don’t be a pushover and don’t let the people who are legitimate mean people get you down. It’s not easy, though. It helps if you have other people to work with on your code projects. Trusted beta testers, or even developers who are willing to take a look. Get yourself out of your isolation and you’ll find it’s a whole lot easier to deal with the crazy, if only to have someone to laugh with.

2 February, 2015
Beta Testers
There’s a weird aspect to open source that can be hard to explain, and that is the ethos and practicality of Beta Testing. Beta Testing is one of the most important aspects of open source, because it’s only with the beta that we’re able to real-world test products. No matter how much planning and testing and automated tests you write, there is nothing quite as powerful as the real-world. We just can’t reproduce it well enough because, among other things, we can’t yet predict humans very well. Sure, cold reading is a thing because humans can be predictable, but that doesn’t mean we know how a tool will be used 100% of the time.

And being a beta tester is hard work. You have to be both a user and a developer, which are really two totally divergent mindsets. Testing as a user versus testing as a developer is as different as how you and a formula one racer drives a car. Input from both the users and the developers is critical to the growth of a project and the end results. But before we get into how one really betas, we have to ask a very important set of questions.

Should I be a Beta Tester?
- Are you brand new to the project?
- Do you use the products daily (or close enough)?
- Do you know how to manually clean up a bad install without losing your data?
- Do you make regular backups?
- Do you know the basic troubleshooting steps for the product like the back of your hand?
- Are you willing to test on your live site?
If you answered ‘no’ or ‘maybe’ to any of those questions, then you’re not yet ready to be an effective beta tester.

That last one may catch people by surprise. Testing on your live site is something we actually tell people not to do, but I’m here to tell you that the best beta testers are either testing on their live site or on a site they use every single day. Since I have multiple site I use daily, I picked the one I can live with if it dies and I use that for my live-beta.

Guess what? You’re on it right now. It’s a hallmark of how much trust I have in WordPress. I can count the issues I’ve had on one hand since I started this a few years ago. I make a backup every day, twice a day, and I have it in three locations. If my site goes down, I lose at most 12 hours of content, and for what I’m doing here, that’s okay. My other sites, I could not deal with that loss and thus I use stable. But I test with live because… well let me explain.

How do I test?

If you’re going to be a beta tester, then the you install the beta and you use the product.

You were expecting rocket science?

Most projects have a lot of automated tests and they’ll test what they know about and what they can. But absolutely nothing replicates real world use. The whole reason I test with a live site, and why I feel it’s important, is that this is as real as it gets. This site is updated regularly with plugins and theme changes. I add new content five times a week on the same Multisite installation. I add new content multiple times a day on another site. One is on trunk, one is not. This lets me constantly compare the experience between the two and makes me immediately aware that something is different. If it gets my attention, that’s important.

What I do with my site is equally important. I’m writing content, constantly, which means I’m using some of the fundamental, day to day features that WordPress absolutely must have. That kind of user testing cannot be scripted. There is no AI yet that can reproduce what machinations a human gets up to.

I like to tell a story about the time my coworker John and I were testing some tax software for the bank. We ran it through it’s paces, putting in data, and every time we tries to save at a certain point, the software crashed. It crashed hard. We called the vendor and talked to them about it, walking them through what we did, and lo, it crashed again. They couldn’t reproduce it, so we screen-recorded it and sent it over. They were astounded and sent out a tech from New York to Chicago to work on this. He couldn’t solve it, but he did see how we crashed it. Then they sent in their big guns, their lead developer, and he sat down and watched us. As soon as it crashed he said he knew what the problem was.

We were doing it wrong. We were entering bad data in a way no tax professional ever would, the system was trying to process the math and, because the logic was bad, it crashed. I pointed out that people would make mistakes and he agreed, saying it should have alerted us to an error in the form, not try to process anyway. A few days later, he sent us a new version which properly trapped the error.

While a scripted test might have caught that by looking for bad values before mathing, they were doing the obvious check. They checked if it was a number. They neglected to check if it was a permitted number. If you’ve ever heard me nag someone about proper data sanitization and validation, this is why. They made a code change, added it into their scripted tests, and learned and grew. But they couldn’t have done that without a real human thinking in a different, and unexpected way.

We can, and will, improve scripted tests, but they will never improve to perfection because humans are pretty crazy. Which leads us to the next step.

How to I report a bug?

This is generic for a reason.

First, make sure you can reproduce the bug. Get a clean build to test on and go through the steps again. If you’re not sure about the steps, make a note to yourself about generally what you remember and try it again. If you can’t reproduce it, call it a one-off and let it go (and debug for yourself, but that’s different). Once you can reproduce it on a clean build, document those steps.

You’re going to want to answer these questions:
- What were you doing?
- What did you expect to happen?
- What happened?
- What research did you do into the error?
- How do you reproduce it reliably?
Include any error messages. Explain what you did. Don’t say “It didn’t upload.” Instead, say “The upload hung, making no further changes on the page. I waited 15 minutes before hitting refresh. When I checked the media library, I saw the image was uploaded however when I looked at the file server, none of the thumbnails were there.”

This is why you need to know what you’re testing. With a failed image upload on WordPress, you should know that the image uploads and then it makes the resized images. Even if you don’t know that, you should know your images are in wp-content/uploads/2015/02/ and you should look there to see if you can find them. If you have a failed post, you should know to look at the post list page in WP Admin and see if the post is listed there.

You’ll get extra bonus points if you can find your PHP error logs and share pertinent information, but that isn’t always easy. When you reproduce the error, make sure you specify if anything special has to happen. Like if the image upload only fails if you’re uploading a PNG, note that. Or maybe it only fails on pages, but not posts. How weird is that, right? Note it.

Don’t worry about being technical here. Be accurate, be clear spoken, and assume the other person is relatively new at whatever you’ve broken. Don’t assume they know exactly what you mean when you said “Upload an image…” Be specific and say “Create a new post and press the ‘Upload’ button…” If you know there are multiple ways to upload an image, test those other ways. It’s a due diligence thing.

After you’ve reported the issue, keep informed. Make sure you get email alerts for it, make sure you reply to those emails for it. You can’t just report it and walk away, you have to keep tabs and pay attention. People may need you to clarify information and explain problems in different ways. Remember people can’t actually read your mind. What’s clear to you, because you did it, may confuse them.

And finally … be prepared to hear that it’s just not that big of a deal. Sometimes a bug isn’t a bug, but an intended change. You may not like it. Heck, you may despise it, but that doesn’t make it wrong.

What else?

What are your takeaways from beta testing? How do you do it?
28 January, 2015
Whose Responsibility Is It?

When WordPress 4.0.1 came out, a small number of sites broke.

For a while, we’ve been touting that minor releases to WordPress core, the ones we auto-upgrade for you, are very safe, very tested, and very important. While all this is true, it has brought a few people complaining to me that obviously I was wrong.

It’s true that the 4.0.1 release broke people. It was an object lesson in why I tell people not to reinvent the wheel. But this upgrade situation does not mean the upgrades aren’t safe, secure or smart. It does bring thoughts to mind, like what my friend David talks about when he considers WordPress at the enterprise level. I know people who are using this failed upgrade scenario as a reason to tout that WordPress isn’t ready for big business, but I think they’re looking at it from the wrong perspective.

Let’s step back.

I used to work for The Man. I’m well aware of the machinations you go through to upgrade anything at a massive enterprise. One of the things they do is a code review. Every single upgrade is checked and tested and a dry-run of the upgrade is run to ensure everything works the way they think it should. By allowing WordPress auto-upgrades, you remove that ability. For a massive corporation? I would turn off the auto-update.

But at the same time, this mythical major company running WordPress would have at least one person who knew WordPress. They would have someone who’s job it was to review every single bit of code that went into their WordPress site. Each plugin would be checked, tested, evaluated for security, and only installed if that WordPress Checker said it was good. Because that’s exactly what you must do in any and all enterprise situations.

David’s viewpoint is that the vetting of a site should be delegated.

My gut reaction to say that they should know better has to be tempered with the fact that no, they should not have to. It’s the job of every site owner to vet their system, but to make a platform that is truly global, that vetting should be delegated. Web hosts and security analysts should vet code for collisions and bugs. Theme and plugin shops should ensure that their products adhere to best practices. Putting accountability for the full stack on each site owner is not only inefficient, but impractical. Inherent trust should exist that code in the official repository maintains a baseline level of code, trust that is eroded when the problems that occurred with a subset of sites on this update occur.

And here, he and I disagree somewhat.

It’s the job of everyone who uses software to be aware of what they’re doing. Vetting the software before it goes in to your system has to be someone’s job. WordPress core does an amazing job of this for you. WordPress core is safe. The 45k plugins and themes in the world don’t always meet the same level of robust checking. Which means when you introduce WordPress to your environment, you absolutely have to seriously review those third party odds and sods you want to use because they’re so shiny and cool.

Web hosts vet code for collisions, sure. We do at DreamHost. That’s part of my and Mike’s jobs! We know what’s going into WordPress and if it’s going to blow things up at DreamHost for our customers. But like the site owner who found her site down one morning because we’d upgraded her from PHP 5.2 to 5.4 and it broke her WordPress 2.5 site, we cannot account for everything.

I think there’s a need for security specialists to review plugins, in a public forum, and point out who’s not doing things in the best way. I also think that there’s a need for developers to remember there’s a reason why we do things a certain way, and while it’s fine not to, you have to keep in mind that it’s now your responsibility to keep a close eye on anything that changes in core that might cause your code not to work as well.

For example. If I wrote a plugin that worked around the shortcode API for whatever reason, I would have a custom query on trac for any ticket related to Shortcodes and have it as an RSS feed to monitor. Or I might even subscribe to the trac firehose and use a filter to pull out anything that so much as mentioned the word. Because I’ve now made a change that I know might be a problem someday.

Every business owner should know the risks of all the software they use, be it website or desktop. This responsibility is the cost of doing business. The size of the business and the importance of the software will change what resources you can afford to allocate to that part of your business, but you absolutely cannot ignore it.

While I really want to say that because WordPress core does due diligence you don’t have to, I would be a lying liar who lies. Even if we do as David suggests and have everyone in the world making sure things are vetted and checked and stamped, it still requires the owners of a site listen to that information and not use the code that’s less optimal. Enforcing that would be impossible unless you wanted to suggest that WordPress outright deactivate code that doesn’t use the proper APIs. That would put a lot of weight on WordPress and slow it down and be pretty annoying for people who are legitimately using non-standard methods of development and implementation.

No matter what, at the end of the day, the person who is responsible for the code quality is the person who wrote and maintains it. But the person responsible for their site is the person using the code. You have to know what code you’re putting into the site and be aware of the risks you’re introducing to your environment by doing so. If your website is your entire business, you cannot afford to be cavalier about these things.

Disasters happen. Understanding the risks will prepare you for dealing with them when they do.

5 December, 2014
Including Assets

I’ve noticed a trend in plugin reviews that people are including third party assets with their code.

This is great. Heck, I do it on a couple of mine. Why should I reinvent the wheel when I’m including code? If I need to use some existing code like a GPL friendly lightbox file, I’ll just grab Colorbox and be happy. But have you ever really looked at your assets?

The above image shows you all the files and folders included in Colorbox. If I was including the entire git repository in my plugin, it would take up about a meg of space. The unminified js file is only 29 KB. For me, it’s a no-brainer again. Grab just the js file (making sure the header has the license info and the URL) and toss that in my code. Why would I include a meg of data I’m not using just for the ‘ease’ of a git clone?

And really I think that’s what’s happening. We’re all so excited to use a git pull or a submodule for the ease of inclusion, we stop thinking about exactly what we’re including in our code and how much weight we’re accidentally adding to it by dumping the whole library in there. Some libraries, like Complexify are really small. Then you have Twemoji, which weighs in at 135 MB, give or take.

Do you really need the whole thing in your plugin, or can you just call their JS remotely from their CDN? That’s one of those things I’d certainly recommend for most people. Sure, I’m the biggest complainer about people off-loading code, but I also am reasonable and logical. Having everyone load a 130+ meg plugin isn’t sustainable, when Twitter’s made a nice way to do it remotely. That’s a service like a font that’s okay and understandable. After all, I hate that WordPress has to call the new fonts on the dashboard from Google, but at the same time including all the fonts for all the languages would make WordPress 11 megs more. That’s just crazy.

Mind you, I had the shower idea that we could make WordPress download the fontpack when it downloaded the language packs, but we’re not anywhere near that yet. Still, that would kill two birds with one stone in my mind. It’s also illustrating the point of being thoughtful and reasonable about the assets we include in our plugins. You don’t need all the documentation files for a js plugin or most php ones either. It’s certainly easier to just drop the whole package into place, but it’s not always best. If one of those example files has a vulnerability, great, you just shot your user base in the foot.

Limit what you put in your plugins. It’ll be easier that way.

21 November, 2014
“Oh yeah. That’s a bug.”

“You’ve been saying you’re working on it for two years! How hard could it be?”

The post made my blood pressure rise a little. I was uncharitable, in my own mind, thinking Well if you know how to do it, why don’t you get off your whingy ass and do it? I was snippy, I was snide, I was … let’s face it, I was mean.

But I didn’t say it out loud. I stood up from the laptop and played a round of ping pong with a coworker who is a bazillion times my better (seriously, he’s great) and tried to learn to return spin-serves. I still can’t, but I understand them now. Then, refreshed, I went back and replied.

“I know it sounds really dismissive, but there are more things at play then just slapping a new coat of paint on the system. We have to take into account the following things [list]. On top of that, we have to do it all in a way that won’t crash the system and that’s backwards compatible!”

I looked at that for a moment and I sighed. No matter how I explained it, no matter which language I used to demonstrate the complications, the reply was still going to be ‘Don’t make an excuse, just fix it.’

There’s a weird truth about software and development that is the people writing or fixing the code generally don’t get fired up about it in a reactionary way. That’s not to say they’re not passionate, or that I never see them angry or excited, but that they’re sort of a Cool Hand Luke about a lot of things, including their job.

From 1997 to 2012, I worked at a bank. I tapped out just shy of 15 years, and through that time I went from desktop applications to operating systems to server based desktop applications (remote apps) to server deployment. I did a lot. I worked on everything, but I was never what you’d call ‘tech support.’ I did support for developers for about 5 years. At one point, when I was working on the OS side of things, my manager asked if I could help one of the senior VPs with an email issue. I agreed, went to his computer, looked at it, calmly minimized the app, fixed the resolution (yes), and was about to go when they screamed.

“You closed my email!”

I blinked a few times, clicked on maximize, and pointed out I had only minimized it.

My manager apologized for over-reacting, but suggested next time I maximize before I leave the desk. I did not point out that what I was doing was not in my job description at all, but I did agree he had a point and said that I would be sure to leave the PC the way I found it, except fixed. This lesson stayed with me. When I fix your site, I try to leave it the way YOU wanted it.

The next day I had a complaint land in my lap, from the Sr.VP, that I didn’t take the issue serious enough. This was tacked on to the heels of another incident that, at the time, I’d forgotten about, where a server went down, people flipped out and called me, and I said “Uh huh, I see what’s wrong. *type* There we go. All better, I’ll fill in the ticket. Sorry about that.”

What was this complaint? I was too cavalier.

I did argue that complaint, and ‘won’ as much as anyone can, because I noted you don’t want the panicking person to run around and scream when they fix your broken stuff, you want them to be calm and collected. At the same time, I did learn something important, and that is people need to feel that you do empathize with them and feel their pain. I’m much better at that now than I was in 2001, but in the last thirteen years, I’ve blown my site up enough to know that level of terror in a visceral way.

But for the person who is having the horrible, no good, very bad, day, there’s a lesson for you too! Sometimes when someone says “Yes, we know.” or “Yes, we’re fixing that.” they can sound far more calm and casual than you are, to the point where they seem dismissive, not because they are dismissive, but because of their experiences. It’s the same logic behind anyone who handles high-stress situations regularly: we get used to it, and we have managed to overcome our panic.

What does all this have to do with the time you asked for a change and we said “We’re working on it?” We’re calm because we are working on it. We sound dismissive because we’ve said many times we’re working on it. We know we don’t have an answer and how much that sucks, but we know (and you know in your heart) that yelling at people to fix it now has never, in the history of ever, actually made someone come to that genius moment faster. Even critical bugs, like Heartbleed, are things everyone tries to fix as soon as possible, but not in a rush or a panic. And if they’re not critical, then we’re generally not going to rush and fix it unless we’re certain we can do it in a way that is safe for everyone, sustainable, and we agree with it.

That sounds like a lot, and it also sounds like an excuse. It’s not. If someone replies “Yes, we’re working on it.” it’s okay for you to ask “Is there anything I can do to help?” It also means you may have to accept that some annoyances are going to stick around for a long time, because they’re complicated, or maybe they require a total rewrite. But as long as they’re communicating with you, they’re not ignore you.

2 July, 2014
When the Fork Breaks

One morning I awoke to see that one of the lead developers on an open source product was leaving because of ‘creative differences.’ Those are my words. His were a little more angry and frustrated, because it was clear these differences were in the direction of the product. He felt stifled and restrained, saying that the grip the original developer had on the product was at odds with allowing the community to develop it going forward, and he was tired of the fight.

So he forked it and moved on.

Regardless of what product this is (and really it doesn’t matter), the decision on my end is whom should I follow?

On the one hand, this is the lead dev who has applied most (if not all) of the patches I’ve submitted. On the other, the original dev has been working on this for over a decade. Then again, the jump to making this a product I wanted to use happened when the new devs, including the forker, came on board. And the original dev is clearly facing a case of founderitis, where there’s his way or the highway, and not accepting the fact that open source products develop in their own life.

Taking a deep breath, I do not mean to trivialize the issues here. When angry-making things happen, they happen for more reasons than we can see, and we know that there are always, always, two sides to the issues. At the same time I am not a part of the angry and it’s not my business to delve deep into it, save to come to a place where I can make my educated, thoughtful decision.

I do have to worry about the stability of both products. How much was this one dev (or these few devs) the cornerstone of the product? Of the features added, whose do I use and like more? Of the ongoing philosophies, which do I more align with? How easy will it be to support the separate version? Do I think this guy is up for it?

None of this is easy! It’s a jump of who do I trust more, and much of it is a gut feeling. I review the code, I match the changes, and I base my choices on what makes me feel better. But … what about when I’m not a coder? It’s even harder. I have to wait and see which is better, which devs jump with, which users I respect join forks, and even then I know if I wait too long, it’ll be hard to move.

I moved my photo gallery from a home grown site to Gallery2 to ZenPhoto. I know the pain of hating the changes in a product. I know the pain of forking. But even so, I still can’t tell you how to make that call because even I don’t know.

All of it depends.

11 June, 2014