[lug] File modification

Jonathan Briggs zlynx at acm.org
Wed Mar 13 16:45:24 MST 2002

I'm working "in the industry" now.  I'm not sure if that lesson works. 
 It seems to be that when the deadline hits, if its pretty close to 
what's wanted and mostly works, out it goes!  

I know we've released code that works well for 5 users, but with 100 it 
was taking 5 minutes per user.  But it worked and was done on deadline!

I contributed some code back to the linux pppd list (RADIUS and 
microsoft mppe encryption for pptp).  It worked, but the list people 
took one look at it and said, "Thanks.  I'll just rewrite that, shall I?"
It was a fast hack and not too pretty.  But it worked, which is all we 
cared about.

 From my experience, working in "the industry" will be just like trying 
to get class assignments done and working the night before they're due. 

There _always_ seems to be some last minute items that wasn't accounted 
for in the schedule.  And it's always hard to schedule the unexpected 
problems that seem to appear.  

For example: The task is to implement RADIUS authentication for a PPTP 
server.  Estimate: Take a wild guess of 9 days.  That goes in the 
schedule.  Then, as the research and programming move along, it's 
discovered that the Microsoft RFC's don't mention certain things. 
 Schedule slip of 1 day.  Or that the Microsoft NT server version if IAS 
doesn't support MSCHAPv2 and you've just spent the last 2 days trying to 
see where your code is broken.  :-)  More schedule slip.  Then when you 
reach the end of the original 9 days there isn't any time left to fix 
the code, since it does work and there's always other stuff to work on.

Maybe other developers here have a different experience though.  It 
would be interesting to hear.

Chris Riddoch wrote:


>It *is* done, though. And I know it works on smaller data sets.  (No,
>you can't look at the code. It's too embarrassing.)
>Eh, better that I learn that lesson *now* than in the industry...

More information about the LUG mailing list