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
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.
