The 5 Promises of User-Led Software Development

It’s easy for WordPress plugin developers to be endlessly chasing “modern best practices” and building features they love, but actual users don’t care about. Over the past few months, I’ve been experimenting with a development methodology that avoids waste and stays focused on users’ priorities. I call it “User-Led Software Development” (actually I first called it “Lazy Software Development”) and this is how it works…
As a plugin developer, I promise to:

1. Seek user feedback
2. Only work on users’ top-requested issues
3. Fix every problem in the easiest way possible…
4. then spend no more than equal time tidying up (code, design, automation)…
5. and spend equal time again communicating the change (documenting it, blogging about it, or announcing it).

I originally called it “Lazy Software Development” because it waits until there is a clear need from the users before beginning work (I realized nobody searches for “lazy” so renamed it). It’s just doing the minimum possible, then be attentive to user feedback.

User-Led Development Is Missing…

Notice this does not include any of the following:

• Working in isolation from real users
• Being dismissive of real users’ requests
• Working on whatever the product owner or developer thinks is important (ignoring user input)
• Inventing complicated solutions for simple problems
• Taking ten times longer to build a feature hoping to plan for every possible use-case
• Limitless time for refactoring code to meet elusive “modern best practices” (although it does allot some time for it, equal to however long it took to fix the problem in the first place)
• Skipping documentation (because often in documenting it, you also realize the weaknesses in your product)
• Keeping everything you learned in the process to yourself (because you’re blogging it)
• Keeping secretive about what’s being worked on (so users can give feedback)
• Keeping secretive about what you’re going to work on next or what big ideas you have (instead you should be blogging about it and getting user feedback)
• Sitting back and waiting for user feedback to come (instead, the one thing you need to proactively do is get feedback from users)

The Results

This seems to be working pretty well for my small plugin, Print My Blog (small both in terms of users, 200, and codebase, just a few dozen files). There’s plenty of areas for improvement, but I put links everywhere telling users to ask for support. And when they do, I see what really matters, not what I just thought would matter.
And far from being upset, users who report the issues are usually really happy. That’s because I’m free to be really responsive to their feedback (instead of being focused on what I thought mattered).

User-Led Development in Practice

I began my plugin with promise 1: “seek user feedback”. I wrote a blog post describing how our blogs will probably inaccessible in 50 years, and described what I thought would be a good solution. It got reblogged by a friend, and her readers almost unanimously wanted a different, simpler. solution. So had I built what I thought people would want, I highly doubt it would even have 200 active installs today.
So then I began promise 2 “Only work on users’ top-requested tasks”. They wanted a really simple way to print their entire blog. Even though I had a hundred features in mind, I just focused on that top priority.
So I built it “in the easiest way possible” by throwing some JavaScript together that used the WP API to fetch all the site’s posts and dump them onto the page, and then users could print that page from their browsers. (I didn’t try to screen scrape their content, or create multiple file formats server-side etc. Those might have been better, but certainly would have slowed down the initial release). It had no options, and a really basic interface, but it did what they wanted: made printing their entire blog easy.
Then, once I had it built and uploaded to WordPress.org’s plugin repository, I blogged about it and why I think every blogger on WordPress should use it to backup their blog to a low-tech format. In the process of doing that, it got noticed. And it started to get downloaded.
So that was my first pass through the 5 promises of lazy development.
Pretty soon I was getting bug reports and folks wanting new features. And rather than ignore them (and get a bad review in the process), I used their feedback to guide development. I added support for pages (I had erroneously thought no one would want to print pages), categories and tags, and comments. None of those was added in a really pretty manner, but that was ok because it served those users needs. I’m pretty sure I’ll need to beef up that code in the future (actually, some of it I have already), but for now it made people happy and got the plugin some positive reviews. And if no one ever notices those features were slapped together, then they’re fine as-is, and there is no need to waste any more time on them.

Objections, Anyone?

What problems could there be with user-led development?

Security

Is it ok to be lazy when it comes to security? Eg would I advocate for “I’ll only add a nonce check if there is a reported security breach”? This is subjective and up to personal preferences. But I’d say you should be much less lazy when it comes to security.

Big Ticket Tasks

Now what about big ticket jobs, like introducing automated testing, or reducing file sizes, or updating code to use latest coding standards? Perhaps an exception could be made, but generally I would include that in the “tidying up” time. What if you’re unable to finish those in that time? Do another top-priority item, and use that tidy-up time for it again. But the point is: unless they are deemed necessary to get the job done, they have a limit on how long they can take.

You Never Get to Work on What You Want

Yes, it could appear you’d never get to work on the features you think are exciting… but there’s a loophole: you can be a user of your own plugin. If you’re actually using it as intended (not just on a test site, but on a live site) then you’re a user too, and I think you get to request features. Actually, far from being a loophole, I think using your own software is essential. Without it, you end wasting a lot of time on unused features and don’t realize users pain points.

This Won’t Work for Large Projects

That may be correct. To my mind, I’ve verified this works for a small project, but no, I’m not certain it will work for bigger ones. But the idea of release early is hardly new.

If you want to know the truth about what you’ve built, you have to ship it. 

We do the best job we know how to do and then we launch it into the market. The market will tell us the truth.

“It Doesn’t Have To be Crazy at Work” by Fried, Jason; Hansson and David Heinemeier

What’s your feedback?

Gotcha! In the process of reading this, you’ve become my “users” who will give me feedback on “user-led software development”! (Ie, please share your thoughts in the comments.) But even if you don’t, that’s also a form of feedback: what I’m saying is either out-to-lunch or not that noteworthy. So either way, I’ve received feedback.
But it would be nice to chat about it. Thanks!
(FYI the cover image is by my 5-year-old. It’s totally unrelated to the topic, but has a fabulous attitude about it, and I thought the world needed to see it.)

Similar Stuff I've Written

To Fund WordPress Plugin Development Through Sponsorship, or More Traditional Models? My WordPress and PHP development Setup The Spiritual Creation of Software How to Make Horrible Software Comparisons Most WordPress Users Don’t Care about Free Software or Community Five Unspoken Rules of Contributing to Open Source Software Introduction to the WordPress World Gratitude Journal February 2019 7 Reasons my WordPress Plugin Grew to 1,000 Active Installs in a Year

Powered by YARPP.