When junior programmers come to me on team projects and asked for priorities on a difficult area of the application, I always say, "Just write it however you can, because we are going to rewrite it anyway." The moral here is that it is more important to get it done fast than for it to be right. You can always re-write code and turn your ugly duckling into a swan, but you can never get lost time back. As a guideline I generally plan on rewriting at least some areas of an application five times before a stable release appears. That's right, FIVE times.

There are many little secrets to cutting down on time-wasting distractions and doing things in a way that gets your product out the door as fast as possible. Here are a few examples,

Example: Tracking Bugs

When I notice a bug I write it down on a scrap of paper, envelope or sometimes a paper towel. When I am told a bug by a tester or manager I write it down (under the date) on a pad. When my stack of paper towels gets unwieldy I go through them and all the bugs that still exist get promoted to the pad. When I think I have fixed a bug I write a circle next to it. When I test the app and the bug indeed seems to be gone I check the circle. If I decide to never fix the bug or that it is not really a bug I put an "X" through the circle. We have a bugzilla online error tracker. I think there is maybe one bug in there. Noone uses it.

Sound impossible? Believe or it not, this is the best way to do things. It is fast and the developer only spends time on absolute essentials. With the exception of public projects, bug tracking systems are only useful for Testing because it lets them know when a bug has been fixed so they don't have to test for it unnecessarily. This is still wasteful. What Testing should do instead is report the bug to the developer (in a list on a piece of paper or an email, not a database), estimate how long the developer will take to fix the bug (say two weeks), then test for it again at the end of that period. If it's still there report it again and lengthen the estimate. In this system the only thing the developer has to do is check off "X" for "not a bug/pilot error" and return the sheet to the Testing. Fast and simple.

Example: Design Planning

Most programs have difficult areas or algorithms that require design planning. If you try to bureaucratize this process it will be deadly to productivity. Design problems should be assigned to one person and one person only, usually the company guru. The guru then uses secret black magic to come up with an answer/approach. The guru meets with the lead developer (unless they are the same person) to communicate the solution. Problem solved.

You get into trouble here if you attempt to make problems like this into "team efforts" and group meetings. Involve more than your two best people or start to generate paperwork and you are just blowing money and time out the door. If you can't solve the problem you need a better guru not more process.

Example: Feature Set and UI

Unquestionably the biggest productivity killer in enterprise software development is amateurism in the feature set and UI decisions. Since this is the area the untrained individual is most likely to understand it is where they tend to aim their process weapons. Productivity shoots the tubes while developers attempt to code up superficially appealing UI "requirements" that reduce program reliability and take ten times the effort of a standardized solution. In big projects ex-English majors spend precious months working up "use cases" and otherwise delaying logic production.

Is there any escape from this trap? Yes. First of all the lead developer should be in charge of the UI design, just like the rest of the program. Only the feature set should be amateur-negotiable and even then it should clear to everyone the lead developer has the final say. The lead should have access to one or more prototype users that they can sit with periodically and build a product vision. This process should only be post-documented, never pre-documented. In other words after a release is out (alpha, beta or otherwise) the use team should sit down and write up suggestions and areas for improvement based on the release. Letting the lead control and set the pace of the entire project, feature set and UI included, will enable faster development, more releases and ultimately a better product.

How Can You Tell If You Have Lost Focus?