Sell digital downloads with WordPress, for free

For most software developers, working on a project is just taking a predetermined set of requirements, translating them into sudo-code, writing some code, and handing it off to a QA for testing. You’re goals or iterations are well-defined by either a manager or marketing type. The design is constructed by the creative department. The usability team has run it by a user-based test group. You’re on your way to a pretty uneventful iteration.

What? That doesn’t happen for you? Don’t worry, you aren’t alone. One thing I’ve found is that it’s often hard to know where you stopping point is, even with a defined set of iterations. If you find yourself saying “Just one more [something]…” then you need to stop.

The Power of Pause

A while back I picked up “The Pragmatic Programmer: From Journeyman to Master”. If the title doesn’t tell you enough, it’s about taking your software development skills far beyond specifics and into concepts. Anyway, one of the sections is titled “Know When to Stop”.

Know When to Stop

As an art school graduate, this phrase is ingrained into my creative conscious. Much like painting or sculpting, software development can often become a game of knowing when to stop. You may not always stop entirely, but you need to pause, let the current work ‘bake’, and then come back to it. The important part is, you take a break from the project.

Far too often, we get into a downward spiral of features, bells, and whistles that just clutter our projects. The quote from the book you should remember is:

Don’t spoil a perfectly good program by overembellishment and over-refinement. Move on, and let your code stand in its own right for a while.

It may turn out that what you’ve done is a perfectly balanced user experience, or it could be the most confusing experience ever. Either way, once the paint hits the canvas it’s hard to take it back. This stands true in software development as well. Once features are released, removing them can be time-consuming, and in some cases, disruptive.

How long should I stop for?

This depends on the person and/or project. Usually, I’ll let a development project sit in my development environment for a day or two before I get anywhere near pushing it to a QA. As I’ve stated before, developing something you don’t use isn’t easy. By leaving the code there for a day or two, without actively developing, you can use and interact with the project as a whole, instead of a single feature.

Sometimes, it simply takes a lunch break for me to realize that I don’t need to take a project any further. The point is, get your head out of the forest and step back to see what you are up against.

Built in breakpoints
2 pages of notes, only half of it made into the next iteration.

The original list of features for Pushover Notifications for WordPress. Only half of these made the next iteration.

Most software developers should be familiar with the term ‘breakpoints‘. I like to use this pattern in my software development life cycle (SDLC) as well. I typically start with a list of “must haves”. Then I create a list of “nice to haves” and “future release” features or goals.

Once my “must haves” are complete, I reassess my remaining two lists. Since a project can change a bit between concept and the first iteration, stopping at each pass allows you to see if your original list of features are even necessary for this release.

What’s your process

Clearly, this is a very individualized topic…so what’s your secret? Do you just go head down to get a project done? When and how do you define your stopping point? Are you a ‘Kanban board’ type person, or do you work pen and paper? I’d be curious to see what other people do to help to Know When to Stop.

Post Promoter Pro

Posted by Chris Klosowski

Hi, I'm Chris Klosowski. Currently I am a Lead Developer of Easy Digital Downloads, where we build the easiest way to sell digital products with WordPress.

I am also the person behind Post Promoter Pro, the most effective way to promote your WordPress Content.

One Comment

  1. […] There’s a time and place for ad-hoc feature additions, and it’s not very often. Features should come with a list of requirements. This is how you measure weather or not you’ve successfully completed development. Without it, you are stuck in an endless “…just one more thing” phase. You can see more on why this is important in my post “The Power Of Pause”. […]


Leave a reply

Your email address will not be published. Required fields are marked *