| Write the simplest possible application first. Leave out all but the absolutely necessary features.
Leave out the UI (User Interface). Fake the UI with hard coded data initialisation. |
If you implement a bare minimum to start, you find out about any show-stoppers early
on. |
| Make and maintain a to do list of the most irritating things about your program. Weight flaws easy to
fix slightly higher than they would normally place. Missing features go in the list as well, based on how
irritating it is not to have them. |
The process of improvement is endless. Whenever you have time to spend improving the
program, you continue the same process. You can maintain that to do list any time you think of an
improvement. Conceptually, the program is never finished. |
| Fix one problem at a time, working your way down the list. |
- If you add features one at a time, you are more likely to implement them in a well-encapsulated
way.
- If you add features one at a time, you avoid brain overload. You focus on just a small aspect of
the program at time.
- Poor encapsulation becames immediately apparent when you go to add a new feature. You refactor
before the mess has had a chance to metatastisise. You get in the habit of constant refactoring to make
life easier to add the next new feature or change.
- If you add features one at a time, you are more likely to test them thoroughly.
|
| Write Javadoc before you write the code. |
Before you write the code and as you write the code is the time you are most aware of
the alternative ways a method might be implemented. Now is the time to document that and disabuse the
reader of the other possibilities. |
| Refactor as you go. |
- When you discover a bug, often you can prevent future such bugs by clever refactoring. You find
this out at the earliest possible time, when the refactoring job is still fairly easy.
- If you refactor early, there is less work to do than if you let the problem fester.
- If you refactor early, you get the benefits early, making it easier to add the new features.
|
| If you have users, show them your protypes and alpha versions, not just the finished product. |
Early experience with the prototype will make you and your users smarter. The
experience will inspire you to think of new features and discard or modify ones you planned to implement.
It is better to find out about changes early before you waste time implementing. |
punctuation 0-9 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z (all)
©1996-2012 2008-01-26 Roedy Green, Canadian Mind Products
Please email your feedback for publication, letters to the editor, errors, omissions, typos, formatting errors, ambiguities, unclear wording, broken/redirected link reports, suggestions to improve this page or comments to
Roedy Green :
If you want your message kept confidential, not considered for posting, please explicitly specify that.
