- What is the solution to prevent losing focus?
- When am I most productive?
- How can I finish a project?
The idea: 5-Hour AppsI will dedicate 5 hours of free time in a week to publish the next release of an app. This will be done 1 hour a day over 5 days. By the end of the fifth hour the results must be published.
These 5 hours each represent a single unit of work. It will be highly productive by following this pattern:
- Setup a timer for the hour with these increments:
- 5 minutes
- 50 minutes
- 5 minutes
- Decide (5 min): “What is the most productive task I can accomplish in this hour?”
- Code (50 min): Accomplish the task.
- Document (5 min): Document app description, developer notes, update the todo list, and check in the source control.
- What can I possibly accomplish in 5 hours?
- Is this even possible at all?
- Why such an extreme limit?
Advantages of the 5-Hour App:
- Single Focus: No fat apps here. I can only produce the sleekest most awesomest apps. I must know exactly what it is supposed to do in order to produce it in this short time.
- Realistic: This is all the time I can give to a side project. It is better to accomplish a small thing than to fail a great thing.
- No Overhead: Everything from testing to publishing must be highly automated in the development process. This process can be improved and reused for each new app.
- Limited Library Coding: Production is focused on the usable app rather than an invisible code library. No longer will I write an “awesome” library that has no real world use.
- No Startup: Because the app is small and singularly focused, the complexity of the project will not require time for me to become orientated with the code. The one hour unit of work will maintain good organization, source control, and planning.
- Extreme Focus: Each hour, the 5 minutes of planning for the next task will give me a focus on the big picture. I will constantly decide what is the most productive route to accomplish that picture to produce a publish-worthy app.
- Publish or Die: The deadline is a true deadline. If an app cannot fulfill its purpose in the time required, it will no longer waste my time. I will move on to another project instead of being swallowed up by the black hole of an infinitely growing project.
- Good Enough But Awesome Software: By focusing on the published result, only the best features will be included. Also, each feature should be well polished. This polish is what separates the mediocre apps from the greats. The short time limit removes the tendency to add features that are unusable by the end user. Because the publish deadline is always near, every feature must be awesome to use.
- A Real Product: No longer will I talk about an app that I am in the process of making. Instead, I can hand my phone to anyone and show them something impressive.
What will be published at the end?
- The app must be published online (most likely as a web-app on my website).
- A blog entry must be made that includes the app link and all details mentioned below.
- Open source apps must have their code uploaded to the open source server.
- A full description of the app must accompany the app which would be suitable for an app store:
- Summary of the app
- New features of this release
- Updated screenshots of the new features
- Developer notes must also accompany the description
- A summary of the technology and libraries used in the project
- Any interesting solutions to difficult problems
- Links to any important research for the project
Continuous Integration of the Publishable ResultsPublishing should be nothing more that uploading files and publishing the blog entry for the release. Any tasks to prepare these files should be completely automated.
In order to accomplish this, all the above is essentially source code. App Description, Developer Notes, and Screen shots will be formatted so that build tools automatically produce the app files and the blog entry.
This will all be done as part of the 5-hour app system.
The 5-Hour App SystemThe system will be an open source set of build tools and a template project. This system will allow focus to remain on producing value rather than on wasting time with repetitive tasks.
During the first projects, the system will not exist. Everything will be done manually. As the need for automation is identified, they will be noted in the system task list.
When sufficient needs are identified, the initial system tools can be produced. This set of tools and the template project will be a 5 hour app itself.
During a 5 hour project, necessary changes to the system should be noted in the system task list. Then these can be implemented in additional 1-hour increments between 5-hour projects. They should not interfere with the timeline of the current project. If a failure occurs in the system, that part should be corrected manually if at all possible.