"I've always admired the Tom Sawyer attitude of painting a fence." -Elvisjay
A good, albeit simple, example of [extra effort now to save time later] is building and maintaining a simple website. I've done a number of sites for non-profit organizations I'm involved with, which inevitably need to have some new content added. Those responsible for the content are by no means technical - asking them to edit HTML is asking a lot.
Typically, they might just e-mail me content, which I would cut-and-paste. This model isn't scalable, of course. I can take myself out of the critical path for content updates, however, by building some sort of content management tool. I've enabled those who are responsible for the content to be responsible for the content, such that they can do what they need to do without depending on anyone else.
More importantly, I'm no longer a bottleneck. I may have spent a bit more time upfront building this than I would have if just putting up a static HTML page - but in the long run, it makes my life easier. This is what I consider lazy. I work a little harder to make sure I don't have to work so hard.
Most references to Refactoring are limited to three areas, effectively reducing Fowler's broad, thorough treatment to a handful of guidelines. It may not be coincidence that these three areas nicely parallel Codd's Data Normalization, creating a sort of "Code Normalization" hierarchy in the public mind. Roughly like so:
- Clean up the code. Fowler's "Simplifying Conditional Expressions." Codd's Third Normal Form.
- Reassign mish-mashed functionality into more appropriate entities. Fowler's "Moving Features Between Objects, and "Organize Data." Codd's Second Normal Form.
- Coalesce duplicated code. Fowler's first "Bad Smell." Also the "once-and-only once" rule. Codd's First Normal Form.
The Lazy Forms discussed so far apply these principles in terms of short (1LF) through long-term (4LF) efficiency. My real goal with the Lazy Forms is to show that whether applied to the evolving lives of software, databases, or buildings, the common goal of designers is (or should be) long-term efficiency.
And so the Lazy Forms discussed so far are incomplete. The scope of an application does not stop with the computer screen, the programmer, the product manager, even the company. Like other products of design, an application is an entity with relationships to the outside world: to people, communities, and cultures.
Any time you can simplify the outside world you actually achieve the Golden Promise of computers: Menial work is eliminated, freeing someone's time to do something more meaningful. When this is achieved in addition to 4LF, you reach Fifth Lazy Form (5LF). Hola Space Age!
Now we can return to Tim's story, specifically the result that his co-workers "can do what they need to do without depending on anyone else. More importantly, I'm no longer a bottleneck." Real-world results. Make it magic. That is what it's all about.
To sum up: Fifth Lazy Form is the long-term lazy solution for not only the producer of an application, but also for those who use it. Fifth Lazy Form software is successful outside the scope of the producer, it provides selfless benefits to the world-at-large.
And that is how the Lazy Forms apply to software.