From walter at frii.com Mon Dec 16 20:28:21 2002 From: walter at frii.com (Walter Pienciak) Date: Mon Aug 2 21:25:48 2004 Subject: [Boulder.pm] one piece of advice Message-ID: Hi, I'm involved with a few new software projects at my company, and I'm looking for some sage wisdom from the software developers among us. Here's what I'm *not* asking: What's a good book/site/document to read/study? What software engineering spec/religion to follow? But here's what I *am* asking: Looking back at your own last project, and feeling a little sore where that $ISSUE bit you or the project unexpectedly on the ass, what is the ONE piece of advice you'd give to someone, to help them avoid that specific problem? Walter From nagler at bivio.biz Mon Dec 16 21:11:06 2002 From: nagler at bivio.biz (Rob Nagler) Date: Mon Aug 2 21:25:48 2004 Subject: [Boulder.pm] one piece of advice In-Reply-To: References: Message-ID: <15870.38346.734000.581620@gargle.gargle.HOWL> Walter Pienciak writes: > Looking back at your own last project, and feeling a little > sore where that $ISSUE bit you or the project unexpectedly > on the ass, what is the ONE piece of advice you'd give to someone, > to help them avoid that specific problem? Expect to underrestimate your initial iteration by A LOT. The learning curve on any project is steep, and unless you've done exactly the same thing before, it's likely you've got a lot to learn. Rob From chip at rmpg.org Mon Dec 16 21:52:26 2002 From: chip at rmpg.org (Chip Atkinson) Date: Mon Aug 2 21:25:48 2004 Subject: [Boulder.pm] one piece of advice In-Reply-To: <15870.38346.734000.581620@gargle.gargle.HOWL> Message-ID: That's funny that you should write that. I was just going to write nearly the same thing. The biggest problem that we at work in the IT department face is chronic under-estimation of the time required to complete a task. There are many symptoms/causes, but the end result is nearly always disaster. Specifically, what's been going on is that we think something will take "4 hours" to complete. The problems are that it's only an estimate on how long it takes to get the first iteration on the "core" part of the task. The other iterations are ignored, as are the steps necessary to automate and integrate the finished core into our system, including the billing parts. Chip On Mon, 16 Dec 2002, Rob Nagler wrote: > Walter Pienciak writes: > > Looking back at your own last project, and feeling a little > > sore where that $ISSUE bit you or the project unexpectedly > > on the ass, what is the ONE piece of advice you'd give to someone, > > to help them avoid that specific problem? > > Expect to underrestimate your initial iteration by A LOT. The > learning curve on any project is steep, and unless you've done exactly > the same thing before, it's likely you've got a lot to learn. > > Rob > > > _______________________________________________ > Boulder-pm mailing list > Boulder-pm@mail.pm.org > http://mail.pm.org/mailman/listinfo/boulder-pm > From efm at tummy.com Mon Dec 16 22:09:52 2002 From: efm at tummy.com (Evelyn Mitchell) Date: Mon Aug 2 21:25:48 2004 Subject: [Boulder.pm] one piece of advice In-Reply-To: References: <15870.38346.734000.581620@gargle.gargle.HOWL> Message-ID: <20021217040952.GA29547@tummy.com> * On 2002-12-17 03:53 Chip Atkinson wrote: > The biggest problem that we at work in the IT department face is chronic > under-estimation of the time required to complete a task. There are many > symptoms/causes, but the end result is nearly always disaster. > Specifically, what's been going on is that we think something will take "4 > hours" to complete. The problems are that it's only an estimate on how > long it takes to get the first iteration on the "core" part of the task. > The other iterations are ignored, as are the steps necessary to automate > and integrate the finished core into our system, including the billing > parts. I use a couple of different techniques to reduce this problem: 1) I try an break the task down into the smallest pieces possible, then ask 'What am I forgetting?'. This helps to avoid the scope problem. 2) I track how long it took to do a task, and use that as a baseline for estimating similar things in the future. It's similar to the _Discipline for Software Engineering_ by Watts Humphrey, but not nearly so rigorous. Also, I try to be very clear about the parts of the task I'm comfortable estimating closely, and the parts which I'm not so sure about how long their going to take. -- Regards, tummy.com, ltd Evelyn Mitchell Linux Consulting since 1995 efm@tummy.com Senior System and Network Administrators http://www.tummy.com/ From nagler at bivio.biz Mon Dec 16 22:30:37 2002 From: nagler at bivio.biz (Rob Nagler) Date: Mon Aug 2 21:25:48 2004 Subject: [Boulder.pm] one piece of advice In-Reply-To: <20021217040952.GA29547@tummy.com> References: <15870.38346.734000.581620@gargle.gargle.HOWL> <20021217040952.GA29547@tummy.com> Message-ID: <15870.43117.274000.746943@gargle.gargle.HOWL> Evelyn Mitchell writes: > 1) I try an break the task down into the smallest pieces possible, then > ask 'What am I forgetting?'. This helps to avoid the scope problem. Our story cards usually are no more than 1 day, and usually less. We avoid estimating any story over 1 week. My mistake is estimating for other people, which I have to do often. Ain't no magic bullet for this, I s'pose. > 2) I track how long it took to do a task, and use that as a baseline for > estimating similar things in the future. :) This is tough. We try to do this, too. When pair programming and swapping partners often, it gets all mixed up. > It's similar to the _Discipline for Software Engineering_ by Watts > Humphrey, but not nearly so rigorous. Extreme Programming eXplained by Kent Beck. > Also, I try to be very clear about the parts of the task I'm comfortable > estimating closely, and the parts which I'm not so sure about how long > their going to take. Good advice, too. We try to estimate the exploration phase, e.g. "Let me look at this for two hours, and I'll get back to you." Recent bad experience: We needed to generate a printable version for a complex report (~50 pages). Our initial cut was, "Hey, we can just munge this all in HTML". Nope. It was much longer due to browser ugliness and there is no table of contents. We then tried using pdflib.org. This cost us a lot of time, and yielded poor results. We finally settled on generating LaTeX, and we're much happier. We estimated so badly that we ate half the cost of aborted implementations. That's another point (which I don't think applies to Walter :). Make sure you don't just dump the cost of mistakes on your customer. Often we do fixed bid iterations (2-3 weeks), and guarantee we'll get it done no matter what. Usually, we get the estimate right, but sometimes, we get it wrong and eat the mistake. Nothing like serious financial pain to sharpen your mind/skills for the next time. $-( Rob From efm at tummy.com Mon Dec 16 23:24:56 2002 From: efm at tummy.com (Evelyn Mitchell) Date: Mon Aug 2 21:25:48 2004 Subject: [Boulder.pm] one piece of advice In-Reply-To: <15870.43117.274000.746943@gargle.gargle.HOWL> References: <15870.38346.734000.581620@gargle.gargle.HOWL> <20021217040952.GA29547@tummy.com> <15870.43117.274000.746943@gargle.gargle.HOWL> Message-ID: <20021217052455.GA30120@tummy.com> * On 2002-12-17 04:50 Rob Nagler wrote: > Evelyn Mitchell writes: > > 1) I try an break the task down into the smallest pieces possible, then > > ask 'What am I forgetting?'. This helps to avoid the scope problem. > > Our story cards usually are no more than 1 day, and usually less. We > avoid estimating any story over 1 week. My mistake is estimating for > other people, which I have to do often. Ain't no magic bullet for > this, I s'pose. I tend to go a lot finer than this. I'll estimate down to the hour level. But then, the sorts of things we do frequently tend to be completable in an hour or two. If someone says "This is going to take 2 days", I know they're not clear on what needs to be done for it to be all done. > > > 2) I track how long it took to do a task, and use that as a baseline for > > estimating similar things in the future. > > :) This is tough. We try to do this, too. When pair programming and > swapping partners often, it gets all mixed up. It takes a fair bit of discipline. It's still important to add time to the task record, even if you're switching around. Each of us records our time using a standard format, and I keep a database of that. Just the simple task of doing something when task switching can be very helpful to build awareness of how long things actually take, or how many interruptions you have. > > > It's similar to the _Discipline for Software Engineering_ by Watts > > Humphrey, but not nearly so rigorous. > > Extreme Programming eXplained by Kent Beck. Yup, that's a good one too. > > > Also, I try to be very clear about the parts of the task I'm comfortable > > estimating closely, and the parts which I'm not so sure about how long > > their going to take. > > Good advice, too. We try to estimate the exploration phase, > e.g. "Let me look at this for two hours, and I'll get back to you." I like this because it puts the risk in the right place. If I don't know how long something is going to take, then I have to tell the customer, or they think I know something I don't. If I communicate clearly, then the customer can decide, based on their needs and budget, whether this portion is something they need or want. > > That's another point (which I don't think applies to Walter :). Make > sure you don't just dump the cost of mistakes on your customer. Often > we do fixed bid iterations (2-3 weeks), and guarantee we'll get it > done no matter what. Usually, we get the estimate right, but > sometimes, we get it wrong and eat the mistake. Nothing like serious > financial pain to sharpen your mind/skills for the next time. $-( > Customers can manage the risk they know (their schedules, their budgets, their business goals), and I can manage the risks I know (estimating how long a task will take, knowing my tools, knowing my resources). The thing I like best about XP is that it is so clear about separating these types of risks. It was so arrogant of IT people to think they could know what customers needed without asking them. But for many years, it seemed the only way to build systems was to make it up without asking customers. I hated that type of thing because I knew I didn't know anything about what customers needed, and so I thought I was a bad developer. I'm glad things are changing. -- Regards, tummy.com, ltd Evelyn Mitchell Linux Consulting since 1995 efm@tummy.com Senior System and Network Administrators http://www.tummy.com/ From nagler at bivio.biz Mon Dec 16 23:19:25 2002 From: nagler at bivio.biz (Rob Nagler) Date: Mon Aug 2 21:25:48 2004 Subject: [Boulder.pm] one piece of advice In-Reply-To: <20021217052455.GA30120@tummy.com> References: <15870.38346.734000.581620@gargle.gargle.HOWL> <20021217040952.GA29547@tummy.com> <15870.43117.274000.746943@gargle.gargle.HOWL> <20021217052455.GA30120@tummy.com> Message-ID: <15870.46045.441000.707665@gargle.gargle.HOWL> Evelyn Mitchell writes: > It was so arrogant of IT people to think they could know what customers > needed without asking them. But for many years, it seemed the only way to > build systems was to make it up without asking customers. I hated that type > of thing because I knew I didn't know anything about what customers needed, > and so I thought I was a bad developer. I'm glad things are changing. Well said, and I wholeheartedly agree. Rob From donald.g.lewis at lmco.com Tue Dec 17 09:35:52 2002 From: donald.g.lewis at lmco.com (Lewis, Donald G) Date: Mon Aug 2 21:25:48 2004 Subject: [Boulder.pm] one piece of advice Message-ID: <6D5BFD6B8FB1D31192F90008C74B68170C729E2E@emss02m03.ems.lmco.com> Beware the requirements creep without accompaning funding. On second thought, beware the requirements creep. - DonL | -----Original Message----- | From: Walter Pienciak [mailto:walter@frii.com] | Sent: Monday, December 16, 2002 7:28 PM | To: boulder-pm@mail.pm.org | Subject: [Boulder.pm] one piece of advice | | | Hi, | | I'm involved with a few new software projects at my company, | and I'm looking for some sage wisdom from the software developers | among us. | | Here's what I'm *not* asking: | What's a good book/site/document to read/study? | What software engineering spec/religion to follow? | | But here's what I *am* asking: | | Looking back at your own last project, and feeling a little | sore where that $ISSUE bit you or the project unexpectedly | on the ass, what is the ONE piece of advice you'd give to someone, | to help them avoid that specific problem? | | Walter | | _______________________________________________ | Boulder-pm mailing list | Boulder-pm@mail.pm.org | http://mail.pm.org/mailman/listinfo/boulder-pm | From nagler at bivio.biz Tue Dec 17 09:59:13 2002 From: nagler at bivio.biz (Rob Nagler) Date: Mon Aug 2 21:25:48 2004 Subject: [Boulder.pm] one piece of advice In-Reply-To: <6D5BFD6B8FB1D31192F90008C74B68170C729E2E@emss02m03.ems.lmco.com> References: <6D5BFD6B8FB1D31192F90008C74B68170C729E2E@emss02m03.ems.lmco.com> Message-ID: <15871.18897.285000.153316@gargle.gargle.HOWL> A bit o' humor: In the beginning there was The Plan, And then come the Assumptions, And the Assumptions were without form, And The Plan was completely without Substance, And darkness fell upon the face of the Workers, And the Workers spoke among themselves, saying, "It is a crock of shit and it stinketh..." And the Workers went unto their Supervisors and sayeth, "It is a pail of dung and none can abide the odor thereof" And the Supervisors went unto their Managers and sayeth unto them, "It is a container of excrement and it is very strong, such that none may abide it" And the Managers went unto their Directors and sayeth unto them, "It contains that which aides plant growth, and it is very strong" And the Directors went unto the Vice Presidents and sayeth unto them, "It promotes growth and is very powerful" And the Vice Presidents went unto the President and sayeth unto him, "This new plan will actively promote the growth and efficiency of this Company, and in these areas in particular" And the President looked upon The Plan, And saw that it was good, And the Plan become Policy. And Lo, this is how Shit Happens. From donald.g.lewis at lmco.com Fri Dec 27 10:12:24 2002 From: donald.g.lewis at lmco.com (Lewis, Donald G) Date: Mon Aug 2 21:25:48 2004 Subject: [Boulder.pm] Word Association Tool Message-ID: <6D5BFD6B8FB1D31192F90008C74B68170C729E5B@emss02m03.ems.lmco.com> Does anyone know of a table based word association tool. It would check to see if a list of words is in a file and if so is another word in the same file. Optionally you could say how many words away the association can be detected. Thanks, Donald G. Lewis (303-581-4879) Lockheed Martin M&DS Boulder, CO From walter at frii.com Sat Dec 28 12:44:37 2002 From: walter at frii.com (Walter Pienciak) Date: Mon Aug 2 21:25:48 2004 Subject: [Boulder.pm] Word Association Tool In-Reply-To: <6D5BFD6B8FB1D31192F90008C74B68170C729E5B@emss02m03.ems.lmco.com> Message-ID: On Fri, 27 Dec 2002, Lewis, Donald G wrote: > Does anyone know of a table based word association tool. It would check to > see if a list of words is in a file and if so is another word in the same > file. Optionally you could say how many words away the association can be > detected. > > Thanks, > > Donald G. Lewis (303-581-4879) > Lockheed Martin M&DS > Boulder, CO I don't have the time right now to check out the various packages, but this sounds like something common to many search engines. I'd look at swish, glimpse, and htdig. If any of them return the offset in a file for a particular word, you're in. Walter From walter at frii.com Sat Dec 28 12:53:32 2002 From: walter at frii.com (Walter Pienciak) Date: Mon Aug 2 21:25:48 2004 Subject: [Boulder.pm] Word Association Tool In-Reply-To: Message-ID: On Sat, 28 Dec 2002, Walter Pienciak wrote: > On Fri, 27 Dec 2002, Lewis, Donald G wrote: > > > Does anyone know of a table based word association tool. It would check to > > see if a list of words is in a file and if so is another word in the same > > file. Optionally you could say how many words away the association can be > > detected. > > > > Thanks, > > > > Donald G. Lewis (303-581-4879) > > Lockheed Martin M&DS > > Boulder, CO > > I don't have the time right now to check out the various packages, but > this sounds like something common to many search engines. I'd look > at swish, glimpse, and htdig. If any of them return the offset in a file > for a particular word, you're in. > > Walter Replying to myself again . . . Depending on what you want to do -- how many files, how often they change, etc. -- you might also want to hack a script using GNU grep, which has a --byte-offset switch. I'm going outside now: it's a beautiful day, and it would be a crime to spend it all puttering at the keyboard. Walter From KSmith at netLibrary.com Mon Dec 30 10:41:02 2002 From: KSmith at netLibrary.com (Keanan Smith) Date: Mon Aug 2 21:25:48 2004 Subject: [Boulder.pm] Word Association Tool Message-ID: <8B499C5ACCA965439B3F6712E7ADABBD5BD1F9@mailman.netlibrary.com> This is a relatively simple, and special-use, perl script, I can't imagine anyone has bothered to turn it into a package, something like: open (IN,"<$filename"); undef $/; # make <> operator use the whole file $file = ; %assoctable = ( word => associated, ... ); foreach $word (keys %assoctable) { if ($file =~ /\b$word\b/ && $file =~ /\b$assoctable{$word}\b/) { print "$filename contains both $word and $assoctable{$word}!\n"; } } should do what you've described... -----Original Message----- From: Walter Pienciak [mailto:walter@frii.com] Sent: Saturday, December 28, 2002 11:54 AM To: Lewis, Donald G Cc: boulder-pm@mail.pm.org Subject: Re: [Boulder.pm] Word Association Tool On Sat, 28 Dec 2002, Walter Pienciak wrote: > On Fri, 27 Dec 2002, Lewis, Donald G wrote: > > > Does anyone know of a table based word association tool. It would check to > > see if a list of words is in a file and if so is another word in the same > > file. Optionally you could say how many words away the association can be > > detected. > > > > Thanks, > > > > Donald G. Lewis (303-581-4879) > > Lockheed Martin M&DS > > Boulder, CO > > I don't have the time right now to check out the various packages, but > this sounds like something common to many search engines. I'd look > at swish, glimpse, and htdig. If any of them return the offset in a file > for a particular word, you're in. > > Walter Replying to myself again . . . Depending on what you want to do -- how many files, how often they change, etc. -- you might also want to hack a script using GNU grep, which has a --byte-offset switch. I'm going outside now: it's a beautiful day, and it would be a crime to spend it all puttering at the keyboard. Walter _______________________________________________ Boulder-pm mailing list Boulder-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boulder-pm