Hi, i think i'd recommend 'code complete', 'the mythical manmonth', 'software project survival guide', but that's just based on personal preference, picking up some books about agile development methodologies could be a good idea too. To be honest, I know the ideas in there, and read papers about it, but havent got to reading a lot of book on agile methods perse.
The thing you describe with the employee sounds familiar, but I think there are two separate issues: * wrong estimates (the subject of your first email) * different programming approaches (the subject of the last email) An employee who hacks everything together might give off very accurate estimates:), the main thing probably is trying to tell your manager WHY that is not the way to go. If you are a perfectionist you might wanna plan for all those one in a million cases that happen 9 times out of 10, but if your boss asked you to develop a quick prototype, you are indeed wasting a lot of time with that formal approach (not saying you are, but just if). The reason we still do it that way is probably that we know 99,9999% sure that the quick prototype will end up in production before you blink your eyes, and one way or another you've been manouvered in such a position that your biting dust either way. However, i tend to keep all communication and assumptions on email, if someone wants a quick prototype, i give them a quick prototype, "ok here is the quick prototype you asked for. Note it has been hacked together, meaning it will probably crash, its unmaintainable, has to be rewritten from scratch if etc etc etc.". You might go on to tell them the nitty gritty details, tell them to read a book on software project management, or tell m to just trust you, depending on the kind of work relationship/environment you are in. (note that i am leaving out the option that you have a solid simple framework, allowing you to put together prototypes more quickly with less disadvantages such as the ones described above). The books mentioned will give you a lot of information on how to educate your boss why it takes you a factor 5 or 10 or 20 compared to your collegue, if he wants a maintainable production ready system. If your boss still doesnt wanna listen, find another boss, more and more managers are seeing the light of solid software development these days :). I had the kind of collegue you mentioned and he was fired because he just couldnt get his stuff bugfree. And for yourself you need to decide what kind of project you are working on, and what kind of measures and overhead it demands. After all a nuclear power system control unit will require different methods than a bouncing flash animation. The estimate for the project I am currently working on, was originally a year. We had to do it in 3 months. So we said ok, we'll do it in 3, BUT documentation will be lacking, functionality will be lacking, it wont be as adaptable, etc, etc, but what we do create will be okay and bugfree. However if you ever want to incorporate more changes, we will have to refactor as we go along (which we are currently doing). Of course it didn't go quite as smoothly as it sounds, but in the end we are getting there. Sorry for the chaotic piece of text, but to conclude: * go with the flow, but communicate about your assumptions so they dont backfire * i try to keep a 'we see possibilities' attitude with a note of warning, instead of a 'we see only problems' attitude * read up on books and try to educate your managers, and dont worry some managers wont understand what you are trying to explain no matter how good you do it:) * if you have established that you are on the right track (based on what you read) and are still not valued and cant change it within your current organisation, leave. Shame to let good talent rot to waste:) just my 2 cnts and really the books explain these phenomena we all encounter way better than i just tried greetz JC On 6/19/07, James Deakin <[EMAIL PROTECTED]> wrote:
Thanks for taking the time to respond Hans. I actually record how long things take already. I think you are right though perhaps the hard part is having the arguments to hand to support why it will take a while. Which books would you recommend? Where I work there is another employee who is willing to hack things together any old way. I like to do things properly and plan for the cases where the application might fail and try to deal with those gracefully. But whenever I give estimates the project manager says "well the other guy can do it in 5 days". its driving me nuts. Thanks once again for the advice. James On 6/16/07, Hans Wichman <[EMAIL PROTECTED]> wrote: > > Hi, > > well one advice is to start recording your current measures and check > afterwards how close you were. > Record things you forget that made your estimates go wrong, records the > factor realhours vs estimate. > Assume that when you think you know everything, you only know about 40% of > whats going to happen. > Adjust your estimate as you go along. Put your estimate on paper, and > include your assumptions. > If the assumptions change, check if you estimates need to be adjusted too. > > Read up on software management lifecycle or books that describe software > processes such as code complete or mythical manmonth, to understand WHY > estimating a software project is hard, and how you can make your manager > understand. > > It's pretty easy to become better at estimating theoretically, say you > have > a project and its estimate is 10 hours. Now it turns out to be 40 hours. > Next time you estimate 20 hours, and you go 'hey but wait, i was wrong by > 400% last time', so you say 80. The hard part of doing it this way is not > having rock solid arguments to present to your boss. > > Other things that come with understanding the software process is the > difference between the time it takes to hack something together, or create > a > software product, or a software system of combined working products. A > proof > of concept for a memory game might take 45 minutes, but a full flegded off > the shelf sellable memory game might take a month. It's still just a > memory > game. > > etc etc > > To conclude my best advice is probably to: > * start measuring, and try to understand why your estimate was wrong (or > right) > * read up on software development material > > greetz > JC > > > > > > On 6/16/07, James Deakin <[EMAIL PROTECTED]> wrote: > > > > I'm looking to improve the accuracy of the estimations of time required > > which I give to my project managers. Does anyone have any good advice? > > > > Please note that I am far from a newbie as I have been programming > > actionScript ever since it first came out (with that nasty slash > syntax). > > This is one area of the job which we never seem to talk about but its is > > one > > of the most important. > > > > James Deakin > > _______________________________________________ > > Flashcoders@chattyfig.figleaf.com > > To change your subscription options or search the archive: > > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > > > > Brought to you by Fig Leaf Software > > Premier Authorized Adobe Consulting and Training > > http://www.figleaf.com > > http://training.figleaf.com > > > _______________________________________________ > Flashcoders@chattyfig.figleaf.com > To change your subscription options or search the archive: > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > > Brought to you by Fig Leaf Software > Premier Authorized Adobe Consulting and Training > http://www.figleaf.com > http://training.figleaf.com > _______________________________________________ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
_______________________________________________ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
