Some non technical advice about Development
Tue, 2005-06-28 18:58 — jrearick
So, we have been busy at work with the whole CMS thing, I have been busy with the help ticket thing, thinking about bug/feature request system, and I know Colin continuously works on ATX. Over these projects I have been thinking more and more about effective project management. The following are some things that may make sense, but really isn't done too often. A lot of this can also be applied to non-computer related projects as well.
1. When doing a project for someone (or even setting a goal for a personal project), give an estimate 1.5 to 2 times the amount of time you think it will actually take to get done. When developing there is always going to be something that snags you or causes development to slow down or stop for a while. Thus, if you overestimate your time required, you will find that you made it in just about the right time. Also, if you do happen to be super awesome and get your project done before your given estimate, you or your client will be happy that you finished early.
2. Before starting on a project have a set of goals for the project and don't add anymore goals until the first set of goals have been attained. Agree on a set feature list. Know exactly what a project is going to do and how it is going to do it. Once you have a list of features, have the client sign a contract that says they can not request any more features until the current contract is fulfilled. This is something that is biting us in the butt right now with the CMS. Every day there is a new list of features the client wants and every day adds more time required to finish the system. When the project started, we thought it would be a simple one month project, now it's probably going to take twice as long. And these estimates were thinking about point number 1.
3. Before making a version available, test, test, test and test it again. Try really hard to break things. Delete preferences, insert random quotes in web fields, put letters in a place numbers should go. Check the tab order of fields. What happens to your data when it unexpectedly quits? What if you don't complete the wizard? Don't do this by yourself. Even though you may think you are being objective, you can't be. You're human. Give it to a friend or someone and make them do the same thing. They can give you insight into what doesn't work right, or may think of things you haven't thought of. Fix the problems you find and repeat this process. I know it sucks. Just do it and you will have a reliable application.
These 3 things have been bugging me a lot lately and I thought it would be cool to talk about it here so that other people may take in this advice. I know I probably haven't followed this advice to a T when I have been doing stuff, but the more you adhere to these lessons, the better things will be.
1. When doing a project for someone (or even setting a goal for a personal project), give an estimate 1.5 to 2 times the amount of time you think it will actually take to get done. When developing there is always going to be something that snags you or causes development to slow down or stop for a while. Thus, if you overestimate your time required, you will find that you made it in just about the right time. Also, if you do happen to be super awesome and get your project done before your given estimate, you or your client will be happy that you finished early.
2. Before starting on a project have a set of goals for the project and don't add anymore goals until the first set of goals have been attained. Agree on a set feature list. Know exactly what a project is going to do and how it is going to do it. Once you have a list of features, have the client sign a contract that says they can not request any more features until the current contract is fulfilled. This is something that is biting us in the butt right now with the CMS. Every day there is a new list of features the client wants and every day adds more time required to finish the system. When the project started, we thought it would be a simple one month project, now it's probably going to take twice as long. And these estimates were thinking about point number 1.
3. Before making a version available, test, test, test and test it again. Try really hard to break things. Delete preferences, insert random quotes in web fields, put letters in a place numbers should go. Check the tab order of fields. What happens to your data when it unexpectedly quits? What if you don't complete the wizard? Don't do this by yourself. Even though you may think you are being objective, you can't be. You're human. Give it to a friend or someone and make them do the same thing. They can give you insight into what doesn't work right, or may think of things you haven't thought of. Fix the problems you find and repeat this process. I know it sucks. Just do it and you will have a reliable application.
These 3 things have been bugging me a lot lately and I thought it would be cool to talk about it here so that other people may take in this advice. I know I probably haven't followed this advice to a T when I have been doing stuff, but the more you adhere to these lessons, the better things will be.
Twitter Updates
RSS
Comments
Theres actually a small problem with one of your things
"2. Before starting on a project have a set of goals for the project and don't add anymore goals until the first set of goals have been attained."
This has been discussed many times on OSNews & Slashdot forums. It's good to have a set of goals, but if one is dragging the project down or if your trying to "perfect" (which is technically impossible with software) the application you'll spend forever developing and take forever getting a release out. Ex Debian taking forever to produce simple releases, many people are mad that they can't produce release dates.
I personally try and follow the following standards
(1) For each release (ie 10, 0.4, 0.3) set a group of goals and be aware of things you'll need to work on that enable you to implement some of those goals (ie ATXWebLib to allow the Report Generator to generate XHTML Reports) if something begins to look like it will take a LONG time to develop and effectively put you way off a schedule put it off to another time, this happened with an Class event export to iCal feature when it became apparent that developing an Cocoa/Objective-C wrapper around the C library libical v0.24 I immediately dropped the feature. Other planned features in ATX have been dropped out of consideration for getting a stable release out on time.
(2) You really need external testers more than your own testing - Since you are a programmer developing an application your thinking about it through your perception of how your program works. External testers haven't looked through your code and don't have extensive knowledge of the in's and out's of your program and therefore will be able to find flaws far more easily than you can - this is why I ask for testers to test out builds and why I really need more people to find flaws in ATX.
(3) You forgot one important thing Documentation! One big imporant thing needed for any project is good documentation written out for the user. I've been working on ATX API Documentation bit by bit lately and right now can't afford to spend the time needed for documentation without sacrificing time needed to work on features. Plus with ever radically changing features it doesn't make sense to write documentation for something you know will probably change in a while.
This is the reality of what any project needs, unfortunitely in my case im just one person and don't technically have any dedicated people working on testing, documentation, website, etc.
On item one: if you really, really know how to do something just cold maybe 1.5 to 2 times your time estimate is enough. If it's just your normal job and you are just normally good at it more like 3 times. If you kinda think you know how 5-8 times etc.